I see you don't understand the technological advantage AST has in comparison with Starlink Direct-To-Cell connection. They are some years ahead in this game.
AST is already testing full broadband 5G technology fully integrated into the terrestrial networks without interference with Vodafone and AT&T and will get Verizon beta testing approval very soon.
What Starlink D2C currently has is a spotty text service with such a low signal strength that is useless for anything more. That is what they got approval for from FCC because any stronger signal is causing unacceptable interference with the current terrestrial networks and the terrestrial providers didn't agree to allow them more than that. It will take a year or two at least for Starlink to get to provide more than text and that is actually stated as well in the T-Mobile press release about this.
Other thing is difference in AST and Starlink architecture which makes Starlink not easy to properly integrate in the terrestrial networks since they have gNodeB modules on the satellite, where AST is integrating with the gNodeB modules on the ground.
There are many details that make AST leading in the game of direct-to-cell communication in comparison to other solutions. They just got 1B in cash from investors to expand and speed up deployment of their network, so calling them vaporware might not age well when in couple weeks they start releasing the testing results.
> any stronger signal is causing unacceptable interference with the current terrestrial networks
I actually never understood that argument. Why would it be harder to tolerate interference from an adjacent frequency base station hundreds of kilometers away than that of one one roof over?
Are Starlink's band pass filters really bad, or do terrestrial networks depend on geometric isolation (via topography or the horizon) to a larger extent than space-based transmission protocols?
> technological advantage AST has in comparison with Starlink Direct-To-Cell
Unverified and unverifiable to date. Unacceptable for an ex-SPAC which nearly got delisted from the exchanges when it dropped to $2 a share a few months back.
>Other thing is difference in AST and Starlink architecture which makes Starlink not easy to properly integrate in the terrestrial networks since they have gNodeB modules on the satellite, where AST is integrating with the gNodeB modules on the ground.
Their bent-pipe architecture is going to have to do a LOT of heavy-lifting to mitigate the impacts of their anti-doppler mechanisms on top of the latency, SNR and jitter. Whole thing hinges on Bluebirds phased-array performance and their ability to handover cells at scale - presuming they've achieved a fraction of what they claim to have achieved using unmodified commercial handsets in real-world environments.
Schadenfreude at SpaceXs very understandable FCC interference issues is a bad look considering ASTS are wholly dependent on SpaceX to put their constellation into LEO!
>There are many details that make AST leading in the game of direct-to-cell communication in comparison to other solutions.
A deSPAC with no major R&D heads of note, headed by an Auteur (Abel Avellan) whose only credence is partnerships with Rakuten/Vodafone leading to board seats.
ASTS have missed every single self-imposed roadmap delivery milestone, have had to hit up their ATM, previously lost 80% of their value from NAV, and are propped up pricewise by a small float and a rabid reddit-style fanbase as a holdover from the SPAC days. They've proven absolutely nothing so far, despite many lofty claims to the contrary, and Rakuten has already hit them up with a multi-million dollar fine for what was effectively non-delivery.
Fact that AST is deSPAC has nothing to do with this. AST has gone out of that phase stellarly.
Second, technological advantages are very verified, by AST doing 20 Mbps download and 5G calls and extremely good spectral efficiency.
Definitely both architectures have pros and cons, but for the fixed-earth cells the bent-pipe is way more optimal then constant switching of the cell position which Starlink has.
ASTS has missed some deadlines, but they are not centering divs, they really do innovation from the first principles and that takes some time. Check TSLA which is 10 years into "we are getting FSD next year out"
Rakuten didn't hit them with the fine, but they exercised a contractual right to get 10 million dollar back if they don't deliver something, but same Rakuten is officially promoting the 2026 as start of the commercial coverage for Japan, if we are taking them as authority.
SpaceX is definitely not the only one on whom they depend for delivery since they use ISRO from India for the first satellite, Falcon9 for the next 8 and New Glen for the rest. And given that they have enough money, they can as well go back to more SpaceX if needed since they have agreement with them.
It is interesting that company without research team has so many patents on this technology and partners with Google, AT&T, Verizon, Vodafone, Rakuten, American Tower and that none of them is seeing how hoax they are. Maybe they will come here and get actually enlightened.
Several things you disagree with or would like to reinterpret. All are perfectly accurate and factual.
> Fact that AST is deSPAC has nothing to do with this. AST has gone out of that phase stellarly.
Look at the work of fiction that is their original DA deck. Every. Single. Milestone. delayed. They went from $40 ATH during SPACmania to $2 last year. Also they've diluted with ATM offerings, which is of huge consequence to those buying in at NAV or higher.
> Definitely both architectures have pros and cons, but for the fixed-earth cells the bent-pipe is way more optimal then constant switching of the cell position which Starlink has.
Yes. One will be supported in NTN 3GPP and one supposedly circumvents the limitation of current 3GPP through undisclosed technological means. Guess which one is the incumbent with a track-record of delivering constellations into LEO, and which one is the startup claiming everything and delivering nothing commercially available or independently verifiable to date?
> Rakuten didn't hit them with the fine, but they exercised a contractual right to get 10 million dollar back if they don't deliver something.
Yes. In common parlance that's referred to as a fine for non-delivery.
>It is interesting that company without research team has so many patents on this technology and partners with Google, AT&T, Verizon, Vodafone, Rakuten, American Tower and that none of them is seeing how hoax they are. Maybe they will come here and get actually enlightened.
Wouldn't be the first time any and all of the above have thrown millions at snake-oil and pipe-dreams. Given what they've actually committed to in terms of cash you can draw your own conclusions.
Abel has had to absolutely tank the share price on multiple occasions - the at-the-market sale in Q4'24 of $400m was particularly telling given not a single one of their strategic partners were willing to step up and bridge them over the bare $440m runway they had to get them through 2025. After the CFO was interpreted as promising no dilution in 2024.
Stock price is a heavy swallow here, especially if someone had a bad timing and not much patience, but stock price is a tool to get funding which AST has successfully done, a year ago with very bad conditions, a week ago with excellent conditions. Not sure what that tells, but to me it tells that at least someone has trusted them with a 1B in cash, and some others with billions in spectrum to achieve their idea which would be transformational.
What is fact is that where Starlink has gotten approval from FCC to test only text messages, AST has gotten approval to test full 5G broadband in Europe, Turkey and USA for now. Not sure how can I interpret it differently then that they have technical advantage and that they might be first to really provide useful commercial service, which they will start providing very soon.
One reasonable way to deal with that would be to subscribe to several sources which lean in different directions and then explore the situation from various angles.
I would though not agree fully about where you assume value is created. Usually, developers / middle managers do not create value. Mostly they are implementing ideas of others and in these ideas is most of value concentrated. I would say they deliver value but don't create most of it.
Doesn't that depend on your definition of creating value? Im biased because I'm a developer perhaps, but I think that these ideas would all be theoretical concepts if these developers weren't actively building them.
Perhaps I have a pessimistic view of the industry, but I've worked at 4-5 startups now (4-5 because one I'm on the fence about calling a startup) and I've come to find that the most value was always "created" when the devs and middle management (product) worked closely together to deliver and hustled/bustled without being blocked by some upper management bullshit. As soon as these companies grew, and these 250k-300k a year "executives" joined, everything slowly went up in flames. This is anecdotal, but it's an issue I've come to notice through personal experience in our industry.
This. Seen the same thing in 3 startups. Add me to the anecdata.
It would be awesome if we could get statistically significant numbers of people to report on this effect, although how to avoid selection bias etc. is beyond me atm.
Happened at a company I worked for after we were bought by a larger corporation. And we were a company of 500+ employees.
Although we had a CTO that grew up with the company (used to be a programmer there) that reported direct to the CEO at the smaller, now we have no CTO and at least 5 layers in between us and the new CEO.
It sure depends. The way I think is that it starts with an idea, ability to preserve the idea, develop it and maintain its essence through iterations with others. Still it is the idea that is making the difference at the start and working around that idea that makes difference at the end.
I was developer, and I was middle manager and I understand the sentiment fully. There are many aspects of reality that higher level management has to deal with which are not usually what they want reality to be but in practice you can not change it.
> There are many aspects of reality that higher level management has to deal with which are not usually what they want reality to be but in practice you can not change it.
The issue I see here is that there are plenty of companies that are very successful and have a small hierarchy and very little hoops to jump through.
It's a good philosophical question: A company creates a great product. What person actually created the value? The product visionary who thought of the idea? The developer who implemented it? The manager who approved the budget allowing the work to happen in the first place?
You're implicitly making a common mistake confusing value creation and value capture.
Yes, it is true that developers writing the software for Google's search engine and Gmail and other products, particularly the early developers who were writing core functionality before it even existed yet, are creating value. But are/were they capturing the full value created? In general, no. To the extent they "captured value" only came in the form of salary/benefits/etc. So they captured some, to be sure.
In highly successful companies who create hugely successful products that create tons of value, the actual capture of that value is absolutely not shared equally. This is in part because the risk was not shared equally.
Just as in successful companies, unsuccessful companies that ship a product that does not do well or fails completely, the developers who created it still captured a salary along the way. The investors and others who put in money or time and energy for little or not pay (in exchange for equity) were the ones with the most risk.
Bottom line... everyone involved in company-building and product-building create value along the way but value capture is generally concentrated for very good reasons.
They're concentrated for reasons. It's highly debatable whether those reasons are "good".
We all take risk. I could find myself working for a company that doesn't make it, or just decides to fire me at a moment's notice. Losing my job and not being able to find another one means I might not be able to feed and house my family. That's real risk. On the other hand, most investors are pretty well off, and can weather a few startups failing. They're likely not going to get to the point where they don't know if they can continue to house their family for the next few months.
"they have more so its ok for them to lose some" - is a flawed logic. The reasons are "good" because they incentivize behaviour. An investor is willing to put a chunk of his money into the startup because he can expect a good return, why else would he take risk on people? An employee is not inherently risking to "lose" anything by taking a job, they risk not gaining something for a while if the job goes, but that's different from proactively putting skin in the game.
I'm not saying it's ok for them to lose some, I'm saying that they're not taking on the risk that everyone claims they are. And yes, an employee very much is risking to lose something. If they get fired or the startup goes under, now they face a very real situation where they might not be able to feed or house their family. I highly doubt that these investors are even close to that point.
"If they get fired or the startup goes under, now they face a very real situation where they might not be able to feed or house their family." this is true for all jobs, my point is, unless you are working for free, you arent giving up something that you will lose. Time yes, but thats why you need to make sure you get paid what you think your time is worth.
> This is in part because the risk was not shared equally.
Developer joining a startup risks almost as much as a founder. He leaves his existing job for a promise of a salary, and if this startup fails - is left without a job, and possibly, without a salary either. This happened to me, and I was paid for first 2 months out of 6 I worked there.
> The investors and others who put in money or time and energy for little or not pay
Investors still have most of their money, I am left without a job, unable to pay my mortgage and possibly buy food.
Imagine this: I put $X, you put $Y into an investment. If investment is successful, I get a 100$, you get $Y+$X-$100. If it is not, we both get nothing. Would you consider this investment fair? No sane person would put a money into an investment fund, expecting a fixed value in return, but employer-employee relations are exactly that.
This is a foolish question, but that's the point. There is simply no objective way to analyze this.
It all comes down to which group the people signing the checks value. I often say "pay is a social construct" and this is what I mean -- there's no objective basis for any of it. I think devs are paid better in the Bay Area than elsewhere just because we're assumed to be more important here relative to other parts of the US/world.
There is no objective reality here, just a bunch of beliefs.
I've not worked anywhere where product development was the only group to come up with an idea that made it into the final product.
My last gig was terribly silo'd as far as responsibilities go. But people go to lunch and happy hour together. Product dev would call out anyone that contributed, even though their team got the kudos because of process (despite the teams being cool, I left because management was shite).
I am curious if sickness increase is caused by mental aspects of sharing the office or the transmittable diseases factor. Authors didn't get into these details the from what I see by briefly looking at the whole paper.
Thanks for the comment! This really reflects the way I started thinking about it lately. Sorry for the investigative tone of the following question: Was there anything in particular that enlightened you towards changing your attitude or was it just through reflection and incremental adjustment of the behaviour?
I guess it is "Write Yourself a Scheme in 48 Hours". I went through it and can tell that it is really a nice introduction to basic and some of the more advanced Haskell concepts.
I would explain this concept as two kinds of life philosophy and ways to approach the future.
1) "exponential" - which gets everybody happy at the beginning and then crushing them with hard reality after things start getting more and more complex. There are a lot of real life examples of doing this and I can rarely find the one which has brought the value at the end. In software development experience I have found this very wrong.
2) "logarithmic" - when you do a lot of investments into solving the hard structural/strategic problems at beginning and then riding much more far on the benefits they provide. This approach works pretty good in real life as well like investment into fundamental understanding, saving early so accumulated benefits get higher.
1. TypeScript is an answer to the poor state of JavaScript development today and an attempt to get more structure into it. There are other answers as well, and it can be discussed on properties of each of them, but they are competing in the same domain.
2. Since state of JavaScript is as it is, it is obvious that there is a lot of potential benefit in being a leader of the technology in that domain. Regarding that, it is kind of answer to forces that are trying to ensure domination in that domain for the future.
To me, TypeScript is the answer to 1) the perceived quirkiness of JavaScript to those who are unfamiliar with it and 2) an increasing number of developers coming out of college with heavy Java backgrounds. I see TypeScript taking off mainly because of the latter point--strict typing and well-defined OO practices will act as a decent safety net for new developers.
Actually just about every popular library out there for JS creates some sort of fake OO layer on top of JS (e.g. Backbone, jQuery, Prototype, YUI, etc..). If you are just throwing a couple of scripts together then JS is fine but if you are trying to make an actual application, you need libraries to make it more OO.
I've worked on large code bases in several languages and JS has to got to be one of the worst when it comes to code quality due to the flexibility. It's always an awful experience trying to refactor a large portion of JS since it's difficult to even find where objects are being used. I'd take AS3 over JS anytime of the day since it allows me to specify types (though optional) and if I do the tooling is able to do a lot of the static analysis that is important in large projects. TypeScript still gives you plain old JS while allowing you to specify some extra information in order to facilitate development. It's actually new developers that aren't aware of these things and love JS from what I've seen. They haven't worked on large code bases and love the flexibility of JS. When you actually are trying to create proper abstractions in order to architect your code, you need visibility modifiers, you need interfaces, and you need types.
Javascript is quirky. It's a great language, but c'mon...please. That horse has been beaten to death and the long discussion on this topic alone is proof of it's quirkiness and it's numerous pitfalls.
The idea that (optional) strict typing and (optional) well-defined OO practices would only work to act as a "safety net" for new developers is, quite frankly, ludicrous. Static typing is the bedrock of static analysis and if you can't see the value in static analysis, take a read here - http://www.altdevblogaday.com/2011/12/24/static-code-analysi...
You're welcome to keep doing things the hard way. You will certainly be enabled to do so since Javascript is not going anywhere. But easy-to-use Javascript-compatible languages with powerful, precise and accessible features are the future, IMO. I don't think I'm alone in that sentiment given the recently budding interest in this arena.
Poor state of JavaScript development? By what measure?
I've been doing "application-scale" development using JavaScript for 5 years... Not once did I think "gee my development process would be better if I had rigid typing." The notion is laughable.
The lack of rigid typing and classes is by design. This is a feature not a bug. I honestly wonder about a programmer's understanding of JavaScript if they say things like "JS lacks classes!" - I'm not sure they understand JavaScript.
Types are not classes! Why do people feel the need to constantly drag out this scarecrow? Having tools to perform static analysis is nothing but a good thing, and you need type data to do a great deal of this. Perhaps your project requirements are such that you never require type checking for your JS, but I can say that it's saved my ass a number of times when working on very large code-bases, and definitely has sped up my development cycle when working on hairy code.
This is a type, not a class, taken from a Closure Compiler docs annotation example:
Now I can require this type in my code with standard JSDoc, which is what the compiler uses anyway for type-checking. It makes my code self-documenting (the Closure Linter, should you use it, will complain if you omit descriptions and the like too, if you find yourself getting lazy):
/**
* Do something...
*
* @param state {project.TriState} The state ...
*/
function doSomething(state) {
If you are documenting your code, you already do this. And now you have static analysis out-of-the-box ... not bad!
Actually that's not quite accurate. The Closure Compiler doesn't need you to tell it that `thing` is a myType, it knows that, asuming myType is defined in your compiled code, or you provide an extern specifying what myType means. And I might be wrong about that last bit even; the compiler may always know that `new Foo` returns a {Foo} regardless of context ... I would have to check the compiler source to be certain.
Also, I think that the first example is more likely to be written as follows (in the case where type data cannot be inferred):
/**
* Description of the variable.
*
* @type {my.UnionType}
*/
var foo = { ... };
Whatever "..." may be. It's common to document the meaning of variables where explicit typing like this is important, just like in well-documented Java and PHP code.
The benefit of typing javascript is for the developer and not the compiler, therefore telling closure compiler that a variable is a type is to decrease the chance of mistakes. Closure compiler also is buggy and isn't as smart as we would like to think it is, sometimes you have to prod it into the right direction. It was a simplified example, something better would be:
/** @type {myType} */ var thing = function_that_returns_a_myType( );
The point is using comments for typing a language is messy and takes up far more space than required.
The type system in TypeScript isn't 'rigid'. It's both optional and structural. These combine to make it a heck of a lot more lightweight than something like C++ or Java.
The classes in TypeScript are a formalisation of a very common design pattern in Javascript, so obviously people do think it's useful. TypeScript takes the common practice and makes it more succinct. (Other than inheritance, which does seem a little un-JSy)
Perhaps you understand TypeScript better than I do. My rough understanding is that TypeScript is JavaScript with what's essentially inline JSDoc. The compiler is just there to give hints and warnings. Is this right?
You are entitled to your opinion but many developers disagree and want some more structure in the programming model. The very fact that many people are trying so hard to come up with some solution to JS means that there are significant problems worth fixing. If you don't see these problems or have them then that's great for you.
To preface, let's say that "application-scale" means something like the following: your server outputs a single html file that only contains references to js files and css (i.e., the minimum to get the app to work right), from then on all data operations are ajax calls to a server side API, while the entire state of the app, all UI/markup components included, is maintained via JS.
I've worked on a couple of these applications, they almost always end up having some fake-class system that provides mechanisms for encapsulation, code sharing, and namespacing. There's often almost a hundred of these fake classes defined with thousands of instances living in memory. I grant you that you can use things like the module pattern to accomplish those requirements -- in fact, if you couldn't, then I wouldn't be here talking about it because I'd be writing Java applets instead. But the lack of having static typing to catch simple errors and enabling basic refactoring tools (like renaming something without having to use a regular expression which took 2 hours to "perfect", or simply switching argument orders, etc) was the absolute worst. I've spent countless hours debugging problems that occurred because something like a string was accidentally passed when an array was expected, and only having the actual runtime error occur 50 function calls later because something like "cat"[0] was working fine up to that point. Static typing would have caught that before I even ran the app.
Anyway, these types of apps perhaps aren't as common as websites, but they exist and therefore there is a need for statically typed languages for the browser.
I don't think of lack of strong typing or OO features as a bug either. I think Typescript's approach of optional features added to javascript provides even more flexibility. You can choose specifically if you want strong typing or not, or you can choose to use classes if you think it's the best approach for the current project. I don't think typescript is trying to remove the options that javascript already has, otherwise they would have gone the way of coffeescript or dart. Typescript, to use the common metaphor, simply extends your toolbelt to let you pick what you want for what you need.
I was thinking about this a lot of times. There are many companies that still have more traditional approach to software development where software development process is considered as "second order citizen" in the process of bringing value to the users. Business oriented people in such companies are completely not aware how abilities of software enable or disable some value to be brought to the users and especially not aware how to optimize environment for better production of software in order to bring this value most efficiently.
Deciding deliberately not to learn to code (or at least to develop good understanding of software development process) in environment where software is expected to be the crucial part of the business is deciding to stay blind for the (most) important part of your business. From my point of view that is doomed to fail unless you are aware of that and deliberately take measures to prevent failure.
Someone would say that the most important is to bring the value to the users, which is not false at the end. What I saw is that business people too often underestimate how much software that brings value is part of the value itself and how it as well puts constraints on how value is brought to users.
AST is already testing full broadband 5G technology fully integrated into the terrestrial networks without interference with Vodafone and AT&T and will get Verizon beta testing approval very soon.
What Starlink D2C currently has is a spotty text service with such a low signal strength that is useless for anything more. That is what they got approval for from FCC because any stronger signal is causing unacceptable interference with the current terrestrial networks and the terrestrial providers didn't agree to allow them more than that. It will take a year or two at least for Starlink to get to provide more than text and that is actually stated as well in the T-Mobile press release about this.
Other thing is difference in AST and Starlink architecture which makes Starlink not easy to properly integrate in the terrestrial networks since they have gNodeB modules on the satellite, where AST is integrating with the gNodeB modules on the ground.
There are many details that make AST leading in the game of direct-to-cell communication in comparison to other solutions. They just got 1B in cash from investors to expand and speed up deployment of their network, so calling them vaporware might not age well when in couple weeks they start releasing the testing results.