Looks like TypeScript envies Swift's compile times.
Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs
21–30 of 80 posts
Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs
#22The fact that the source is so small is wild. I would have expected a huge convoluted parsing library implemented in types. On the other hand, the fact that this is even possible is more wild. Instead of replacing JS with a proper statically-typed language, we're spending all this effort turning a preprocessor's type system into a turing-complete metalanguage. Pretty soon we'll be able to compile TypeScript entirely…
I wish javascript had gone in the same direction as php with types.
Which is?
Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs
#23Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs
#24Earlier quoted context omitted.
Which is?
[flagged]
I was hoping to hear how are php types better than TS instead of another rant about how Rust is the greatest. Anyone?
By the way, having lived in Scala 2 for a few years, Rust is half-assed. Type system leaks through the fingers when working with async collections. Future.sequence from Scala makes great cli apps. Scala collections are a work horse. The only thing from Rust I like is the shorthand question mark return (compiler magic for Result type).
Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs
#25The fact that the source is so small is wild. I would have expected a huge convoluted parsing library implemented in types. On the other hand, the fact that this is even possible is more wild. Instead of replacing JS with a proper statically-typed language, we're spending all this effort turning a preprocessor's type system into a turing-complete metalanguage. Pretty soon we'll be able to compile TypeScript entirely…
People have fussed the same of the C preprocessor, around the same time I and maybe you were born. (There's a pretty good chance I'm your parents' age, and nearly no chance you're the age of mine.)
The criticisms were valid then, too. C (including the preprocessor of course) is still not fully parseable if you include things like token concatenation.
Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs
#26Earlier quoted context omitted.
People have fussed the same of the C preprocessor, around the same time I and maybe you were born. (There's a pretty good chance I'm your parents' age, and nearly no chance you're the age of mine.)
The criticisms were valid then, too. C (including the preprocessor of course) is still not fully parseable if you include things like token concatenation.
I make no representation as to soundness, then or now. Not till I figure out where my copy of the UNIX-HATERS Handbook has got to, at any rate. I've had cause reasonably recently to reread the X and sendmail chapters, not so much this one.
Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs
#27This requires the whole `.proto` declaration inline in source a string constant. I'm not holding my breath on "Import non-js content"[1] getting approved, so that means you still have to use another build dependency, or manually keep the .proto files synchronized across multiple sources truth. In that light, it's not clear when this would be a benefit over straight-forward code gen. Cool POC hack though. [1]: https:/…
That can be done with a `sed` call so it’s not a new dependency.
Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs
#28The fact that the source is so small is wild. I would have expected a huge convoluted parsing library implemented in types. On the other hand, the fact that this is even possible is more wild. Instead of replacing JS with a proper statically-typed language, we're spending all this effort turning a preprocessor's type system into a turing-complete metalanguage. Pretty soon we'll be able to compile TypeScript entirely…
TypeScript does an amazing job at describing the types of real-world JavaScript. It's incredibly good, and very useful, even in the face of extremely dynamic programs. The fact that it can describe transforms of types, like "this is a utility that adds an `xxx` prefix to every property name" is frankly unparalleled in mainstream languages, but more importantly lets us describe patterns that come up in real-world JS programs - it's not fluff!
And luckily, the most complex of types are usually limited to and contained within library type definitions. They add a lot of value for the library users, who usually don't have to deal that that level of complexity.
Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs
#29This requires the whole `.proto` declaration inline in source a string constant. I'm not holding my breath on "Import non-js content"[1] getting approved, so that means you still have to use another build dependency, or manually keep the .proto files synchronized across multiple sources truth. In that light, it's not clear when this would be a benefit over straight-forward code gen. Cool POC hack though. [1]: https:/…
The problem is that TypeScript is terrible at codegen, there are no standard extension points like we have with javac and others. So we are forced to do these crazy hacks at the type level rather than just generating types as you would in other languages.
Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs
#30What's kind of amazing is that Typescript's matching of strings through the type system converges on a first-class PEG in a few places (see string.ts). The rest of the library is really damn succinct for how much lifting it's doing.
My hat's off to the author - I attempted something like this for a toy regex engine and got nowhere fast. This is a much better illustration of what I thought _should_ be possible, but I couldn't quite wrap my head around the use of the ternary operator to resolve types.