Unions, generics, required fields, default values, enums that don't pollute the global namespace are things that immediately caught my eye. I assume it also doesn't repeat Protobuf's the mistake of not being able to distinguish between a missing string value and an empty string value.
Protobuf is old, and has some really strange warts that are only explainable historically (for example, by reference to the behavior of C++, which used to be Protobuf's primary target).
I have long used protobuf as the source of truth for API's, but it does have some weird idiosyncrasies since its primarily a binary spec, and doesn't always transfer to json well (e.g optionals, maps, etc).
As someone who works on TypeSpec, my feeling is that they are mostly different things. TypeSpec is a general purpose DSL which supports "emitting" to protobuf and other things, but in and of itself doesn't prescribe any particular protocol or serialization format.
Gotcha. I think this might be where Protobuf falls short because you have to "source" the tooling for all its different outputs, but support for OpenAPI 3.0 spec generation has existed for over a year.
Superior in performance and easy-of-use, which for most people is all that matters. Atom still won in general "hackability", which was one of its main selling points. Unfortunately that didn't stick, and the kind of people that want a hackable-to-the-core editor are probably using Emacs. I know I am.
TypeScript wasn't better than Flow when it gained dominance. It happened because Microsoft created an out-of-the-box experience with VS Code that worked great with TypeScript but made Flow types look broken.
More generally Microsoft treated Typescript as a product - they built it based on feedback from outside users and worked hard to make it easily adoptable and to grow a community around it. They are also "pragmatic" - willing to have weird, unsound semantics if it's needed to help people adopt Typescript and model existing JS ecosystem patterns.
Flow has always been an inwardly-focused project that is for Facebook's needs first. The Flow team at FB made an explicit decision to focus more on compiler performance improvements (what Facebook's usage needed) over outside users & community.
The way I remember, when flow was introduced, you had to do small changes to 3rd party dependencies your code might have had to make them flow-compatible.
With typescript you could just write a type definition file for any 3rd party library, so you could essentially make any 3rd party dependency "typescript compatible" without needing to change its code.
This small difference made a huge impact for adoption. Eventually flow also got that feature but by then the adoption difference was already too big.
From what I remember TypeScript was a superset of Javascript, so you could just rename your files and enable TypeScript and it all worked, and then gradually move stuff over. That probably helped a lot.
It was released. It was on a growing number of webpages and an important part of the Dev Tools of IE9+ (also giving them a massive install base from before Atom existed). If Atom didn't build Electron what became the VS Code team might have built something similar on their own eventually (though it probably would have been IE-based and Windows-only in that alternate history). It truly seemed convergent evolution at work.
Amazon is great at a lot of things, but AI and Machine Learning aren't it. From what I saw when I worked there, they don't have the talent to produce their own models (which is, I think, what we all expected to see), but the surprising thing is that they haven't partnered yet.
> From what I saw when I worked there, they don't have the talent to produce their own models (which is, I think, what we all expected to see)
The talent is repeatedly run off by managers and executives who don't know how to manage talent. At this point, I'm convinced it's actually part of the Amazon culture to not excel at AI/ML. Mediocre, or else. It's so weird (and abusive) to be around. 10/10 not a rewarding place to work.
Personally I have always felt that AWS has too much of "manager culture" or something. But them missing AI train was crazy though.
I am personally more surprised that Microsoft did not miss that train with AI and now are pretty aggressive with integration of AI everywhere. Though I wonder if Microsoft would not have missed mobile and search if Nadella was CEO after Gates. Satya is ruthless. Even despite not being first in cloud, they still are able to compete with AWS.
It is happening all over industry. Those that can't adapt will be eaten by AI.
And AI is moving way too fast and the execs who took a wait and see approach are now in panic mode. AI tooling should be a straight forward investment regardless of outcome.
> the surprising thing is that they haven't partnered yet.
Amazon has a partnership with and investment in Anthropic, but I don't consider Anthropic to much good for various technical reasons not having to do with their model. Essentially, Anthropic is user-hostile in many ways. Also, Anthropic keeps spamming me daily with pointless legal changes, sneakingly adding marketing materials into their legal emails.
There's an HN post that takes first place on my bookmarks bar, which is an Ask HN about the best paper people read in 2020 [^1]. Every once in a while I'll open it and browse through a ton of amazing papers and research and try to learn something new. Hasn't let me down yet.
Normal and acceptable are two very different things. Another post from earlier mentioned other shady practices from them, so I wanted to bring this up too.
I got tired of getting pings from Netflix, so I finally opened the app and tried looking for the setting to disable them. Apparently they opt you in to these by default, and the only way to disable them, according to the help article, is through the OS’ settings directly.
All the comments in this thread are right. This specific scenario was about providing a consistent experience. All the work that this backend does could be done using iOS’ background updates, but:
1. Those aren’t consistently scheduled
2. They have an extremely tight deadline (and sometimes Reddit can be a bit slow)
Making it server side means we controlled that experience better.
Theoretically it could do it all from the app, but it would have to resort to background updates, which are scheduled at iOS’ discretion. Christian was aiming for consistency, which is why this exists.
reply