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

471–480 of 570 posts

Re: Node.js adds experimental support for TypeScript

#471

Post by treflop »

sesm wrote: post #357
winter_blue wrote: post #35

Earlier quoted context omitted.

Flow (by Facebook) used to be fairly significant in the JavaScript several years ago, but right now it's somewhat clear that TypeScript has won rather handily.

There was no real competition, Flow was a practical internal tool with 0 marketing budget. Typescript is typical MS 3E strategy with a huge budget. Needless to say, Flow is much more practical and less intrusive, but marketing budget captured all the newbie devs.

Have to disagree. I tried Flow irrespective of marketing and didn’t think it was polished. Kept running into type situations that the language didn’t support well. Kept bugging out in my IDE. Had no elegance.

Re: Node.js adds experimental support for TypeScript

#472

Post by hajile »

recursive wrote: post #453
pansa2 wrote: post #369

Earlier quoted context omitted.

Here's an example of TypeScript failing to be sound - it should give a type error but it doesn't. I believe Flow does indeed give a type error in this situation: https://news.ycombinator.com/item?id=41069695

You don't have to go even that far to find unsoundness in flow. const arr = ["abcd"]; const str = arr[1]; const num = str.length; // this throws console.log(num); For me, typescript is a pretty good balance.

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)

Re: Node.js adds experimental support for TypeScript

#473

Post by hajile »

fabiospampinato wrote: post #463
recursive wrote: post #453

Earlier quoted context omitted.

You don't have to go even that far to find unsoundness in flow. const arr = ["abcd"]; const str = arr[1]; const num = str.length; // this throws console.log(num); For me, typescript is a pretty good balance.

Wait, so Flow is not actually sound and their website is lying? Or do they have some "technically correct" definition of "sound" that takes stuff like that into account?

Even haskell will generate a runtime error for an out-of-bounds index

    main = putStrLn (["a", "b", "c"]!!4)

Re: Node.js adds experimental support for TypeScript

#474

Post by recursive »

hajile wrote: post #472
recursive wrote: post #453

Earlier quoted context omitted.

You don't have to go even that far to find unsoundness in flow. const arr = ["abcd"]; const str = arr[1]; const num = str.length; // this throws console.log(num); For me, typescript is a pretty good balance.

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.

It's just a question of how far down the spectrum you're willing to go. Pure js is too unsound for my taste. Haskell is too constrained for my taste. You might come to a different conclusion, but for me, typescript is a good balance.

Re: Node.js adds experimental support for TypeScript

#475

Post by recursive »

hajile wrote: post #473
fabiospampinato wrote: post #463

Earlier quoted context omitted.

Wait, so Flow is not actually sound and their website is lying? Or do they have some "technically correct" definition of "sound" that takes stuff like that into account?

Even haskell will generate a runtime error for an out-of-bounds index main = putStrLn (["a", "b", "c"]!!4)

This is different. Neither flow, typescript, nor javascript generate a runtime error for an out of bounds index. It's explicitly allowed by the language.

The result of the an OOB access of an array is specified to be `undefined`. The throw only happens later when the value is treated as the wrong type.

I don't consider a runtime error to be a failure of the type system for OOB array access. But in javascript, it's explicitly allowed by specification. It's a failure of any type system that fails to account for this specified behavior in the language.

Re: Node.js adds experimental support for TypeScript

#476

Post by commercialnix »

hajile wrote: post #326
garbagepatch wrote: post #103

Earlier quoted context omitted.

Looks very similar to Reason ML, another language that compiles to Js: https://reasonml.github.io/docs/en/getting-started

ReScript was an outgrowth of ReasonML and basically split the community killing both of them.

I was not aware of this. I did see ReScript covertly bring some sanity to some NodeJS projects, and more than once. So this history of the project is worth digging into. Thank you for surfacing this insight.

Re: Node.js adds experimental support for TypeScript

#477

Post by [deleted] »

samtheprogram wrote: post #9

Bun’s DX is pretty unprecedented in this space, and most of my use cases are now covered / not causing Bun to crash (when actually using run-scripts with `bun run`). Meanwhile, I can’t configure node to not require extensions on import, nor have tsc configured to automatically add .js extensions to its compiled output, without adding on a bundler… although native TypeScript support would remedy this nit quite a bit,…

[deleted]

Re: Node.js adds experimental support for TypeScript

#478

Post by paulddraper »

parasense wrote: post #401
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…

Paired characters... That's an interesting topic. Do you happen to know if UTF-8 contains more "pair" characters? In Latex we call these delimiteres, but that's just my limited experience coming in from math side. I tend to agree that it would be helpful to have more kind of nesting/pairing/grouping/delimiting characters. The problem is my imagination is limited to what I know from the ASCII world, and so it goes...…

Nit: UTF-8 is a particular encoding. Unicode is a character system.

UTF-8, UTF-16, UTF-32 all have the same characters.

Re: Node.js adds experimental support for TypeScript

#479

Post by crabmusket »

sureIy wrote: post #415
crabmusket wrote: post #163

Earlier quoted context omitted.

What is missing for your use case or workflow?

Probably a bunch of assertion types and general DX. Node:test is just a feature, Vitest is a whole product. The former might be enough for small packages but nowhere near useful for anything non-trivial.

Fair enough. We still use Jest at work for exactly those reasons. In my personal projects, I prefer to minimise dependencies rather than get every DX benefit I can.

Re: Node.js adds experimental support for TypeScript

#480

Post by seanmcdirmid »

teaearlgraycold wrote: post #144
seanmcdirmid wrote: post #116

Earlier quoted context omitted.

Typescript’s optional and unsound type system also does nothing for a JIT beyond what it could already do for JavaScript, you can’t do optimization if your types are unreliable. However, I really really like how Typescript’s type system super charges developer productivity (type errors via the compiler and feedback via the IDE), and don’t mind this part of the design at all.

You can use typescript types to compile functions. You just might need to deoptimize when you actually hit the function.

I don’t know if Vortex-style compilation ever worked in practice.
Post reply on HN