Hacker News Reader

Comment by andremedeiros | Hacker News Reader

What does this do that Protobuf doesn't?

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).

That's totally fair feedback. Particularly optionality having been removed from proto2 to proto3 is confusing.

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.

> TypeSpec's standard library includes support for OpenAPI 3.0, JSON Schema 2020-12 and Protobuf.

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.

Protobuf is a binary spec isn’t it?

The default transport (gRPC) certainly is, but HTTP RPC translation/gateways are easily generated.

Microsoft NIHS (not-invented-here-syndrome)

yeah like when they uselessly reinvented flow with typescript

also reinventing atom with vscode.

To Microsoft's credit, both are better alternatives, with VS Code being _significantly_ superior to Atom.

I think that was the grandposter's sarcastic point.

yes sorry, i should be more explicit going forward

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.

Not just to ruin a fun joke with silly facts, but key parts of VS Code predated Atom.

not the part where they actually released it and not electron aka atom shell

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.

Reply on news.ycombinator.com