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

Type-Safe Printf() in TypeScript

typescriptlang.org

Post reply on HN
Print view View original

41–50 of 82 posts

Re: Type-Safe Printf() in TypeScript

#41

Post by lolinder »

taeric wrote: post #30

I've been kind of curious why tricks like this aren't used more to make sql and such. Heck, you could do similar tricks for shell execution. Or any general "string that is parseable." Seems we always take the route of not parsing the string as much as we can?

This is a pretty neat application, but most embedded languages like SQL have a way more complicated grammar that would require a really complicated set of types to parse. This can tank the performance of your type checking step and it also means that the error messages you get out of the parser-in-types are going to be nearly useless.

A more common solution is to parse the string at runtime with a proper parser with decent error handling and then have the parser return a branded type [0] which you can use elsewhere to ensure your strings are well formed.

[0] https://egghead.io/blog/using-branded-types-in-typescript

Re: Type-Safe Printf() in TypeScript

#42

Post by quaunaut »

zogrodea wrote: post #33
eyelidlessness wrote: post #19

Earlier quoted context omitted.

This is such a cynical take. The point is to model what types exist at runtime in the type system, so that you can reason about those same runtime types statically. They’re only “fictitious” if they’re defined incorrectly, or if the type system can’t sufficiently express certain of their nuances. The former is usually only the case when developers intentionally work around the safety provided by the type system; the…

I find myself inclined to the opinion you're disagreeing with in all honesty. When defining types in other languages, the task is prescriptive (you specify what fields there are in a type and the runtime accepts this as law), but in Typesxript the task is meant to be descriptive (as you say, one models the types that exist at runtime which is the inverse). I was excited about Typescript when I learned it, but found m…

Curious what your issue was with duck-typing. Were you effectively looking to create ADTs that are required to go through a specific step-by-step process, not simply 'look like' the thing that was expected?

If so, you might be interested in [newtype-ts].

[newtype-ts]: https://github.com/gcanti/newtype-ts

Re: Type-Safe Printf() in TypeScript

#43

Post by quaunaut »

cobbal wrote: post #8
Touche wrote: post #3

Except missing the pesky runtime implementation. We don't need though, right? As long as the types say it's right.

The static types depicted in typescript are entirely fictitious. Any similarity to runtime types is purely coincidental.

I mean, all types are "entirely fictitious" as far as the computer is concerned. Yeah they usually have fewer layers than JS does, but that's a pretty arbitrary line to draw.

Re: Type-Safe Printf() in TypeScript

#44

Post by quaunaut »

taeric wrote: post #30

I've been kind of curious why tricks like this aren't used more to make sql and such. Heck, you could do similar tricks for shell execution. Or any general "string that is parseable." Seems we always take the route of not parsing the string as much as we can?

There is actually efforts in the Typescript community attempting to do just that. Personally I think it'll end up being a waste, but these sorts of experiments, even when they fail, often can help along new discoveries.

And on the off-chance they get it right, then damn that's pretty great.

Re: Type-Safe Printf() in TypeScript

#45

Post by iainmerrick »

gibbitz wrote: post #20
cobbal wrote: post #8

Earlier quoted context omitted.

The static types depicted in typescript are entirely fictitious. Any similarity to runtime types is purely coincidental.

Yeah. I see a lot of "typescript is more readable" arguments out there, but I find this code dense and verbose. The more words you use to explain something the more likely you are to be misunderstood. What we're looking at here is basically a restricted wrapper for console.log and a regex implementation meant to simulate a logger in another language. Why not just write a cross-compiler for that language? There's no l…

Hmm, let me try to defend TypeScript, then. I think it’s a terrific language, and more importantly manages to salvage JavaScript into a very decent language.

Coming from a mostly C/C++ background, I had been very skeptical of “gradually typed” languages like Dart (and now Python), but I’ve come around to the view that for many purposes it’s better than a completely statically typed compiled language.

You don’t need to compile TS at all, just bundle it, which is lightning fast in current tools, so it feels almost as nimble as pure JS. But you have almost-instant type checking in tooltips and code completions, and you can run a full project check whenever you want (that’s slow, but still way faster than compiling Rust).

The type system isn’t perfect but it’s incredibly expressive. Almost anything you could imagine doing in straightforward JS can be typed (admittedly sometimes with a lot of effort and head-scratching) and once typed it’s generally easy to use with confidence that most runtime errors will be avoided.

The fact that JS and TS are separate languages is a bonus -- it keeps TS honest, and the competition between JS engines means runtime performance is great. If you were designing TS from scratch, I think you’d be tempted to add some kind of runtime type reification, but TS is better off without that. Completely erasing types means compilation will always be fast, and in my experience RTTI causes more architectural problems than it solves.

Re: Type-Safe Printf() in TypeScript

#46

Post by quaunaut »

jitl wrote: post #38

Word of warning: the typescript compiler is not a particularly fast evaluator of recursive list manipulation programs, which is what these kinds of types are. They’re great in small doses where you really need them, but overuse or widespread use of complex types will make your build slower. It’s much better to avoid generics or mapped types if you can. The typings for a tagged template literal (without digit format s…

While I certainly agree, I've found that this is often an indication of too-complex an architecture, and a fundamental re-think being necessary. I've had projects that depend on [fp-ts], which end up incredibly generic-heavy, but still make it entirely through a typecheck(not build- typescript's just worse at that than other tools like esbuild) in seconds-at-worse.

Obviously depends on your organization/project/application, but I do like these things as complexity-smells.

[fp-ts]: https://gcanti.github.io/fp-ts/

Re: Type-Safe Printf() in TypeScript

#49

Post by zogrodea »

quaunaut wrote: post #42
zogrodea wrote: post #33

Earlier quoted context omitted.

I find myself inclined to the opinion you're disagreeing with in all honesty. When defining types in other languages, the task is prescriptive (you specify what fields there are in a type and the runtime accepts this as law), but in Typesxript the task is meant to be descriptive (as you say, one models the types that exist at runtime which is the inverse). I was excited about Typescript when I learned it, but found m…

Curious what your issue was with duck-typing. Were you effectively looking to create ADTs that are required to go through a specific step-by-step process, not simply 'look like' the thing that was expected? If so, you might be interested in [newtype-ts]. [newtype-ts]: https://github.com/gcanti/newtype-ts

Thanks for the link. That was exactly my use case and I should remember your helpful suggestion next time I use TS.

Re: Type-Safe Printf() in TypeScript

#50

Post by 38 »

quaunaut wrote: post #31
38 wrote: post #10

[flagged]

Go's type system is inferior to Typescript's in every possible way. About the only saving grace it has is that it didn't start out in a non-typesafe ecosystem, but most of those issues have been alleviated in Typescript for years. At this point, folks are seeing how far they can push the Typescript type system because it's capable of expressing so, so much more with its types than is seen typically(including in most…

Typescript typing isn't even required, so your argument just fell apart.
Post reply on HN