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

Node.js adds experimental support for TypeScript

github.com

Post reply on HN
Print view View original

511–520 of 570 posts

Re: Node.js adds experimental support for TypeScript

#511

Post by zarzavat »

klodolph wrote: post #461
zarzavat wrote: post #298

Earlier quoted context omitted.

The problem can be traced back to ASCII/typewriters only including three sets of paired characters, plus inequality signs, which is not enough for programming languages. We really need five sets: grouping, arrays/indexing, records, type parameters, and compound statements. Curly braces {} are also overloaded in JS for records and compound statements, leading to x => {} and x => ({}) meaning different things. Square b…

Five sets, but at any given place in the syntax, not all five are possible. (I would add function calls to the list—so, six.) In most languages, (grouping and compound statements) cannot syntactically appear in the same place as (indexing, records, type parameters, function calls). So we are immediately down to four. Rust takes the approach that you use :: before type parameters, so they are easily distinguished from…

> In Go, there’s nothing that can be both indexed and take a type parameter.

True, but TypeScript has a rule against type-dependent emit - it’s not allowed. Code must always do the same thing regardless of what the types are. And in any case JavaScript does allow indexing on functions, since functions are just objects.

Re: Node.js adds experimental support for TypeScript

#512

Post by ivanjermakov »

zelphirkalt wrote: post #309

If this means, that one day I don't need to use a bundler any longer to make a website using TypeScript, I am all for it.

For that browser needs to understand ts natively. Otherwise, transpilation has to be done: by tsc, bun, or by something else.

Re: Node.js adds experimental support for TypeScript

#513

Post by 3np »

klodolph wrote: post #295
the_gipsy wrote: post #158

Earlier quoted context omitted.

You would also have to update your compiler. I guess you could phrase this as: you can't update your TS versions independently from your node.js version. But that's probably not an issue.

Not necessarily. With a couple exceptions (like enums), you can strip the types out of TypeScript and end up with valid JS. What you could do is stabilize the grammar, and release new versions of TypeScript using the same grammar. Maybe you need a flag to use LTS grammar in your tsconfig.json file.

> With a couple exceptions (like enums)

Apart from a clueless engineer attempts them, it's been working out fine to pretend they don't exist.

Re: Node.js adds experimental support for TypeScript

#514

Post by nyssos »

lolinder wrote: post #440
nyssos wrote: post #404

Earlier quoted context omitted.

> Do you have an anecdote (just one!) of a case where TypeScript's lack of type system soundness bit you on a real application? Sure. The usual Java-style variance nonsense is probably the most common source, but I see you're not bothered by that, so the next worst thing is likely object spreading. Here's an anonymized version of something that cropped up in code review earlier this week: const incomingValue: { name:…

I mean... yes, there's a footgun there where you have to know to spread first and then add the new properties. That's just a good practice in the general case: an intermediate type that fully described the data wouldn't have saved you from overwriting it unless you actually looked closely at the type signature. And yes, TypeScript types are "at least these properties" and not "exactly these properties". That is by de…

> That's just a good practice in the general case: an intermediate type that fully described the data wouldn't have saved you from overwriting it unless you actually looked closely at the type signature.

The issue isn't that it got overridden, it's that it got overridden with a value of the wrong type. An intermediate type signature with `updatedAt` as a key will produce a type error regardless of the type of the corresponding value.

> I'd be very interested to know what you'd do to change the type system here to catch this.

Like the other commenter said, extensible records. Ideally extensible row types, with records, unions, heterogeneous lists, and so on as interpretations, but that seems very unlikely.

Re: Node.js adds experimental support for TypeScript

#515

Post by austin-cheney »

harshitaneja wrote: post #88

I really enjoy typescript and have been yearning for a typescript runtime but I can't help but laugh that I left java all those years ago to finally seek something a lot closer to java. I guess we all just wanted java with JIT, more feature rich type system and gradual typing. Also for all the shortcomings of npm ecosystem, it is a lot less daunting and more fun to be using libraries in this ecosystem. And surprising…

> I guess we all just wanted java with JIT

Oh god no. What an abomination.

Greater than 95% of the incompetence in JavaScript comes from two camps. The first of those are people who absolutely cannot program at all. The second of those are Java developers who were taught Java in school and it’s all they can do, so everything must look like Java.

The result of both tribes is pretending to do something they cannot do on their own. When you’re a pretender vanity becomes excessively important because everything is superficial, so you get layers of shit you don’t need that they cannot live without. Any attempts slice off the unnecessary bullshit always results in hyper emotional distress because people feel threatened when exposed. That right there is why I will never write JavaScript for employment ever again.

Re: Node.js adds experimental support for TypeScript

#516

Post by bazoom42 »

Timon3 wrote: post #425
felixfbecker wrote: post #402

Earlier quoted context omitted.

This is true, but in other cases they added keywords in ways that could work with type stripping. For example, the `as` keyword for casts has existed for a long time, and type stripping could strip everything after the `as` keyword with a minimal grammar. When TypeScript added const declarations, they added it as `as const` so a type stripping could have still worked depending on how loosely it is implemented. I thin…

I don't know a lot about parser theory, and would love to learn more about ways to make parsing resilient in cases like this one. Simple cases like "ignore rest of line" make sense to me, but I'm unsure about "adversarial" examples (in the sense that they are meant to beat simple heuristics). Would you mind explaining how e.g. your `as` stripping could work for one specific adversarial example? function foo () { retu…

CSS syntax have specific rules for how to handle unexpected tokens. E.g if an unexpected character is encountered in a declaration the parser ignores characters until next ; or }. But CSS does not have arbitrary nesting, so this makes it easier.

Comments as in your example is typically stripped in the tokenization stage so would not affect parsing. The TpeScript type syntax has its own grammar, but it uses the same lexical syntax as regular JavaScript.

A “meta grammar” for type expressions could say skip until next comma or semicolon, and it could recognize parentheses and brackets as nesting and fully skip such blocks also.

The problem with the ‘satisfies’ keyword is a parser without support would not even know this is part of the type language. New ‘skippable’ syntax would have to be introduced as ‘as satisfies’ or similar, triggering the type-syntax parsing mode.

Re: Node.js adds experimental support for TypeScript

#517

Post by antifa »

miki123211 wrote: post #89
mattnewton wrote: post #55

Earlier quoted context omitted.

Before that there was the closure compiler (Google) which had type annotations in comments. The annotation syntax in comments was a little clunky but overall that project was ahead of it's time. Now I believe even inside google that has been transpiled to typescript (or typescript is being transpiled to closure, I can't remember which - the point is that the typescript interface is what people are using for new code)…

Closure was also interesting because it integrated type checking and minification, which made minification significantly more useful. With normal Javascript and typescript, you can't minify property names, so `foo.bar.doSomethingVeryComplicated()` can only be turned into `a.bar.doSomethingVeryComplicated()`, not `a.b.c()`, like with Closure. This is because objects can be indexed by strings. Something like `foo.bar[f…

Teaser has a mangle props feature. The mangle props by exact name or pattern has worked for me, but it might affect library objects or browser built-ins that I definitely don't want it to, but I've not gotten the mangle all props of this object version of it to work.

Re: Node.js adds experimental support for TypeScript

#518

Post by hajile »

joseferben wrote: post #504
hajile wrote: post #322

Earlier quoted context omitted.

If JS ever adds type checking, I hope it doesn't choose Typescript. We need a type system that is actually sound and TS is intentionally unsound. We need a type system that doesn't allow bad coding practices like TS does. We need a type system that enforces program design that allows programs to be fast. We need a Hindley Milner type system. If you want a module to be typed, add a `"use type"`. This should disallow b…

having written ocaml in production for a few years, i think soundness comes at a cost of dev ergonomics. at least with the type systems of today’s industry languages. it blows my mind weekly how ergonomic and flexible typescript’s type system is. it allows me to write great apis for my team mates. is it possible for the type checker to end up in an infinite loop or for a junior developer to abuse “as”? absolutely, bu…

Ocaml types are USED by the compiler to generate FAST code.

TS types are IGNORED by the JIT to generate SLOW code.

All the features that make Typescript more ergonomic for devs also allow it to generate slower JS code. AssemblyScript tries to be TS for WASM and it doesn't support huge swaths of TS because they output unusably slow garbage.

I also suspect that more than a few Ocaml ergonomic issues are due to nominal typing. StandardML's structural typing and inference give an experience very similar to TS, but without the major soundness issues (though it must be noted that ANY generics in JS will be slow unless the compiler is creating multiple function variants).

Re: Node.js adds experimental support for TypeScript

#519

Post by hajile »

dwb wrote: post #383
hajile wrote: post #317

Earlier quoted context omitted.

Flow tries to be sound and that makes it infinitely better than TS where the creators openly threw the idea of soundness out the window from the very beginning.

This is a point in Flow's favour. However! Seven years ago or so, when TypeScript was quite young and seemed inferior to Flow in almost all respects, I chose Flow for a large project. Since then, I spent inordinate amounts of time updating our code for the latest breaking Flow version, until one came along that would have taken too long to update for, so we just stayed on that one. We migrated to TypeScript a little…

Turning on EVERY safety feature won't mitigate the unsoundness because the problem goes beyond stuff like `any`.

Re: Node.js adds experimental support for TypeScript

#520

Post by hajile »

recursive wrote: post #474
hajile wrote: post #472

Earlier quoted context omitted.

I think this is not a very good example. Not only does it also throw in TS, but it even throws in Haskell which is pretty much the poster boy for sound type systems. This isn't a type error unless your type system is also encoding lengths, but most type systems aren't going to do that and leave it to the runtime (I suspect the halting problem makes a general solution impossible). main = putStrLn (["a", "b", "c"]!!4)

Yes it throws in typescript. Typescript isn't the the language chasing soundness at any cost. This just illustrates the futility of chasing soundness. Soundness is good as long as the type-checking benefit is worth the cost of the constraints in the language. If the poster child for soundness isn't able to account for this very simple and common scenario, then nothing will actually be able to deliever full soundness.…

My balance point is StandardML. SML and TS both have structural typing (I believe this is why people find TS to be more ergonomic). SML has an actually sound type system (I believe there is an unsoundness related to assigning a function to a ref, but I've never even seen someone attempt to do that), but allows mutation, isn't lazy, and allows side effects.

Put another way, SML is all the best parts of TS, but with more soundness and none of the worst parts of TS and non of the many TS edge cases baked into the language because they keep squashing symptoms of unsoundness or adding weird JS edge cases that you shouldn't be doing anyway.

Post reply on HN