Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs

github.com

Post reply on HN
Print view View original

71–80 of 80 posts

Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs

#71

Post by Timon3 »

yencabulator wrote: post #70
Timon3 wrote: post #69

Earlier quoted context omitted.

Many, if not most, of these occurrences can be made safe. It's very rare that I need `as`, and even more rare that I can't actually check the relevant properties at runtime to ensure the code path is valid. It's on you to ensure that you don't misuse `as`. If I could choose between current TS, and a "safer" one that's less expressive in complex cases, I'd choose the current one any day of the week.

"Typescript can be made safe" is the "C++ has a subset that is good" argument. Meh.

Almost every language has some way to do stupid things. Say you're working in C# - you can forcefully cast almost anything to almost anything else, just like in TS. So according to you, C# is just as bad as TS in this respect, right?

Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs

#72

Post by yencabulator »

Timon3 wrote: post #71
yencabulator wrote: post #70

Earlier quoted context omitted.

"Typescript can be made safe" is the "C++ has a subset that is good" argument. Meh.

Almost every language has some way to do stupid things. Say you're working in C# - you can forcefully cast almost anything to almost anything else, just like in TS. So according to you, C# is just as bad as TS in this respect, right?

If that's a thing commonly needed for basic operations like letting your event handler actually access the event details, then very much yes.

Sane languages have a downcast mechanism that doesn't pretend it succeeds every time.

Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs

#73

Post by Timon3 »

yencabulator wrote: post #72
Timon3 wrote: post #71

Earlier quoted context omitted.

Almost every language has some way to do stupid things. Say you're working in C# - you can forcefully cast almost anything to almost anything else, just like in TS. So according to you, C# is just as bad as TS in this respect, right?

If that's a thing commonly needed for basic operations like letting your event handler actually access the event details, then very much yes. Sane languages have a downcast mechanism that doesn't pretend it succeeds every time.

Weird, I don't need to do that.

Also weird that Typescript has exactly the mechanism you're talking about. Why are you acting like it doesn't?

Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs

#74

Post by neonsunset »

Timon3 wrote: post #71
yencabulator wrote: post #70

Earlier quoted context omitted.

"Typescript can be made safe" is the "C++ has a subset that is good" argument. Meh.

Almost every language has some way to do stupid things. Say you're working in C# - you can forcefully cast almost anything to almost anything else, just like in TS. So according to you, C# is just as bad as TS in this respect, right?

You can only do this with `unsafe { }` or `Unsafe.As/.BitCast`. Casts from/to `object` are type-safe even though may not be very user-friendly or good use of the type system in general.

Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs

#75

Post by bastawhiz »

phpnode wrote: post #68
bastawhiz wrote: post #60

Earlier quoted context omitted.

No, I'm talking about compile time. A loader at compile time (e.g., for webpack) takes whatever your import path is and translates it into something that can be used by the JavaScript application. It would be awfully silly to do this at runtime because typescript doesn't exist at runtime, which is sort of the whole point of the library.

I think you’re misunderstanding how this project works. The contents of that ?raw file are opaque to the typescript type system, it will see it as a `string`, not as the literal content of the file, therefore it cannot be parsed using template literal types as this project does and cannot be used to derive typescript types from protobuf files.

The loader proposal linked by the top level comment does not create strings, it imports them as the string literally type of their contents. That would absolutely 100% work with this project since the content of the imported file is available to the type system.

The reply with the typescript definition for ?raw is unrelated to this project and would neither solve the issue presently nor address it in the future. But if you implemented it in your bundler, it absolutely solves this problem exactly as described, because the imported file can have whatever boilerplate you want around it (like `as const`). This is something that exists and is usable today.

Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs

#76

Post by phpnode »

bastawhiz wrote: post #75
phpnode wrote: post #68

Earlier quoted context omitted.

I think you’re misunderstanding how this project works. The contents of that ?raw file are opaque to the typescript type system, it will see it as a `string`, not as the literal content of the file, therefore it cannot be parsed using template literal types as this project does and cannot be used to derive typescript types from protobuf files.

The loader proposal linked by the top level comment does not create strings, it imports them as the string literally type of their contents. That would absolutely 100% work with this project since the content of the imported file is available to the type system. The reply with the typescript definition for ?raw is unrelated to this project and would neither solve the issue presently nor address it in the future. But…

1. This whole subthread has been about the ?raw approach, not about a hypothetical feature that has not been agreed to yet.

2. Typescript runs before your bundler and has no idea what the bundler is doing, so any transformations you do there are invisible to it.

You keep telling me this is possible today, at this point I'd ask you to please prove it, because if it's true then that's very exciting and I have a bunch of use cases for it.

Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs

#77

Post by antonvs »

throwanem wrote: post #56
antonvs wrote: post #53

Earlier quoted context omitted.

X and sendmail are not really very relevant today.

The mistakes embodied in both thus far look not just still relevant but positively timeless. Certainly, to judge by how often young people with no sense of their field's history recapitulate those mistakes.

Without specifics it's difficult to evaluate what you're saying.

What are some examples of the timeless mistakes in those programs? I think X was a pretty good effort, it's just that it essentially ossified and has been left behind compared to some more modern systems (although I'm using it right now.) Sendmail approach to dynamic configuration was sub-optimal. But these aren't examples of mistakes that I see recapitulated often.

Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs

#78

Post by throwanem »

antonvs wrote: post #77
throwanem wrote: post #56

Earlier quoted context omitted.

The mistakes embodied in both thus far look not just still relevant but positively timeless. Certainly, to judge by how often young people with no sense of their field's history recapitulate those mistakes.

Without specifics it's difficult to evaluate what you're saying. What are some examples of the timeless mistakes in those programs? I think X was a pretty good effort, it's just that it essentially ossified and has been left behind compared to some more modern systems (although I'm using it right now.) Sendmail approach to dynamic configuration was sub-optimal. But these aren't examples of mistakes that I see recapit…

I referred to the relevant chapters of a book which I named. This is the book: https://web.mit.edu/~simsong/www/ugh.pdf

Not every configuration system is as bad as the m4 nightmare that sendmail used, and I understand nothing really better was feasible in the prelapsarian or Stone Age days of its implementation. But I worked - fought - with sendmail for years and, as in the book, I also remain mildly surprised that Allman continues to perambulate. Most such things in my later professional experience differ by degree, not kind. YAML is not as bad as what was typically perpetrated in Perl days, but it does too much and too little and all its fiddly rules give me headaches. JSON is awful and what we're basically stuck with, because even though it's so simple it's almost useless, at least it's simple. XML is much better than it gets credit for, but nobody likes it because most programmers seem to regard the need to use a keyboard as an imposition, and I assume also have frequent nightmares featuring lots of pointy angle brackets. (I use Emacs because I don't hate myself, and I wish more people had the sense to keep things as simple as Emacs Lisp typically is.)

I don't want to talk about X. Wayland has been about 60% mistakes by volume, and I like too many of the people who made it too well to be anything other than sad about that.

Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs

#79

Post by antonvs »

throwanem wrote: post #78
antonvs wrote: post #77

Earlier quoted context omitted.

Without specifics it's difficult to evaluate what you're saying. What are some examples of the timeless mistakes in those programs? I think X was a pretty good effort, it's just that it essentially ossified and has been left behind compared to some more modern systems (although I'm using it right now.) Sendmail approach to dynamic configuration was sub-optimal. But these aren't examples of mistakes that I see recapit…

I referred to the relevant chapters of a book which I named. This is the book: https://web.mit.edu/~simsong/www/ugh.pdf Not every configuration system is as bad as the m4 nightmare that sendmail used, and I understand nothing really better was feasible in the prelapsarian or Stone Age days of its implementation. But I worked - fought - with sendmail for years and, as in the book, I also remain mildly surprised that A…

I read that book in the last millenium, I wasn't inclined to go and refresh my memory just to understand your comment.

Re sendmail, when were you working with that? My reaction was just to look at it, say "nope", and used Exim instead. Perhaps the most instructive lesson here is the importance of good choices when it comes to selecting systems to depend on.

Other than that, I'm not sure what the lesson is in "people collectively decided to depend on one of the worst alternatives available." We still see that today with programming languages.

There's nothing really wrong with YAML, except perhaps the way some people use it. I classify that as "skill issue". I work with Kubernetes regularly, and its YAML usage is fine.

Something similar applies to JSON. If it's so terrible, what's better? With JSON Schema and OpenAPI, it's feature-comparable to XML now.

The problem with XML is its completely unnecessary verbosity outweighs its usefulness. I can only assume it was designed by ex-mainframe people who, unlike me, actually yearned for a return to the overengineered environments they were used to. It's no surprise that JSON and YAML edged out XML.

Emacs Lisp is an abomination. Sure, Lisp has its place historically - I had a spirited discussion with John McCarthy about that at a Lisp conference in the 2000s. I'll just mention two words: dynamic scoping. They took decades to even figure out a solution to the funarg problem, and that still didn't really fix the language. Luckily Guy Steele came along and noticed that Church had solved that problem before computers were even invented.

Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs

#80

Post by throwanem »

antonvs wrote: post #79
throwanem wrote: post #78

Earlier quoted context omitted.

I referred to the relevant chapters of a book which I named. This is the book: https://web.mit.edu/~simsong/www/ugh.pdf Not every configuration system is as bad as the m4 nightmare that sendmail used, and I understand nothing really better was feasible in the prelapsarian or Stone Age days of its implementation. But I worked - fought - with sendmail for years and, as in the book, I also remain mildly surprised that A…

I read that book in the last millenium, I wasn't inclined to go and refresh my memory just to understand your comment. Re sendmail, when were you working with that? My reaction was just to look at it, say "nope", and used Exim instead. Perhaps the most instructive lesson here is the importance of good choices when it comes to selecting systems to depend on. Other than that, I'm not sure what the lesson is in "people…

> Re sendmail, when were you working with that?

Oh, only until about 2005. Other options on the table included Postfix and qmail; when I reached a point where burgeoning trust in my engineering judgment coincided with time to replace the oldest production boxes, we commenced to switch to Postfix, primarily because administering that yielded me the lowest Excedrin bill.

Anything with genuine numerical precision would be better than JSON, is what. I appreciate this is an open-ended suggestion with no implementation offered, but if I have to spend one more mortal minute bikeshedding bignum representations in strings, I won't be held responsible for my actions. Indeed just the thought reminds me part of my purpose in this time apart from labor is to decide whether indeed I will train as a lawyer, where I understand time similarly spent is billable in six-minute increments.

I wish I'd been a fly on the wall for your discussion with McCarthy, as perhaps I also wish you could have been for a very spirited chat I had with Stallman around 2016 on the merits and externalities of his and FSF's philosophical approach. I appreciate you taking the time of such a detailed and thoughtful reply, which I confide I'll later revisit and find benefit beyond that already apparent. Enjoy your day!

Post reply on HN