Hacker News Reader

Comment by Touche | Hacker News Reader

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

I think the point is safely typing the pattern of having variadic functions with a format string argument.

The function implementation itself isn’t that interesting, or “pesky” to be honest

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

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 latter is possible, but at this point it’s usually only ever the case for patterns that are hard to reason about regardless of the type system or even the presence of types at all.

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 myself disillusioned by actual experience when using it (of course others love it and have good reason to). Had defined classes in Typescript so I can have some of my types reflected at runtime.

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.

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 learning curve for the syntax then, only the target platform.

<rant>The invention, support and defense of Typescript baffles me. It feels like an intensely wasteful work-around for poorly written interpreter error messages concocted by comp-sci grads who think compiled languages are superior to interpreted ones in all situations and they want to bring this wisdom to developers of loosely typed languages. </rant>

This isn't typical application code, but either proof-of-concept or library code. What you'd instead get is the type error, which in turn would explain itself well enough- that it expected a certain type, and got a different type.

The reason you wouldn't want a cross-compiler for that other language is that there are true semantic differences between languages, and many languages simply cannot fully support the JS runtime- and if your primary application is still in Typescript, trying to cross-compile for a single feature is downright ridiculous.

> The invention, support and defense of Typescript baffles me. It feels like an intensely wasteful work-around for poorly written interpreter error messages concocted by comp-sci grads who think compiled languages are superior to interpreted ones in all situations and they want to bring this wisdom to developers of loosely typed languages.

I sincerely don't think statically typed languages are superior, but I'd argue a large part of the increase in quality over the last few years of the ecosystem is due in large part to Typescript.

Is it going to fix all, or even a majority of the issues? Probably not. But if it can improve upon the situation I don't see why we'd make perfect the enemy of good.

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.

> 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

Counterpoint: It's a desperate attempt to make Javascript useable and nearly does so, but ends up being weird in itself to get around the limitations of the underlying language.

I use Typescript most days and I hate it. Part of that is that npm is a dumpster fire but a lot of it is that Typescript is a rubbish version of much better languages and it hurts to use it. I am so desperate to get back to something sane like C# that I will quit this job for less money.

I'm sure we'll never fully agree, but I am surprised that you think TypeScript "ends up being weird in itself". To the contrary, I think the type system feels very natural; what feels weird is when you switch to another language and realise it doesn't have e.g. sum types.

One big problem I do bump into with TS is that the tooling of TS itself is pretty bad -- the way it manages compiler options, import paths, etc. Luckily you don't need to use TSC very much in practice, and other TS-aware tools like esbuild and Bun are vastly better.

(Likewise, I find myself much happier with NPM than with other package managers like Maven or PyPI, at least when you switch the NPM tool itself for a better drop-in replacement like PNPM.)

Anyway, each to their own! I hope you're able to find a good C# gig or similar.

Guardrails won't keep you on the road if you intentionally steer into them at full speed either.

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.

If they're "coincidental" you missing the point, and not doing them right.

What do you mean? `console.log` supports `%d` and `%f` already.

console.log("This is a %s and a %d!", "string", 4.3) -> This is a string and a 4!

Reply on news.ycombinator.com