Thanks! I could see why the name is a problem. Especially how N rotated 90 is Z. Unfortunate a bit late, given it was free on the package systems etc :/
Naming still remains the hardest programming problem ...
This is extremely early per the disclaimer at the top, like too early to even run most toy programs.
In general I'm kind of skeptical of the approach these rewrite in rust/go projects are going. Maybe as wasm plugins for hot paths in existing tools, but it's not clear to me that the full rewrites are where we want to be long term as a community.
I don’t see how this project can be considered a rewrite of anything. Yes, it compiles JavaScript and uses TypeScripts typing syntax, but it has different features and semantics compared with TypeScript. It’s like saying C++ is a rewrite of C.
Very cool! I'm curious, is this intended for dev tooling?
For example, I could see this (or something similar) being useful as the engine for a typescript language server that would be faster than the standard one
But if it's not aimed at 1:1 with tsc, would it be intended more for something like swc[1]?
Or what would you expect people to use this for, besides just being a cool project to learn from?
There is a specification but it's fallen a bit behind the implementation. Of course the implementation is open source, pretty well documented and covered in lots of tests. So, you could think of that as a living specification.
Very cool! Congrats on the launch, even if it is very early.
Unsolicited feedback: I read the name an Enzo (n-zo) until I read the readme and realized it was Ezno (es-no).
Since in a previous post [0] you say you're unsure on the name, Enzo could be a good one if this is a common mistake.
[0] https://kaleidawave.github.io/posts/introducing-ezno/
I saw it as Enzo as well
A newer update than one you linked: https://kaleidawave.github.io/posts/ezno-23/
I read it as Enzo and just assumed it was fast (like a Ferrari).
Thanks! I could see why the name is a problem. Especially how N rotated 90 is Z. Unfortunate a bit late, given it was free on the package systems etc :/
Naming still remains the hardest programming problem ...
I think Enso is already taken by a YC company [0]. Could get confusing.
[0] https://enso.org
Enzo is a common name and I associate it with the founder of Ferrari.
It’ll have different associations to different people. Good reason to just add to it.
This is extremely early per the disclaimer at the top, like too early to even run most toy programs.
In general I'm kind of skeptical of the approach these rewrite in rust/go projects are going. Maybe as wasm plugins for hot paths in existing tools, but it's not clear to me that the full rewrites are where we want to be long term as a community.
Unlike stc, Ezno is meant to be an extension for what TS offers today. Check this article[1] for all the cool stuff it can do.
[1] https://kaleidawave.github.io/posts/introducing-ezno/
I don’t see how this project can be considered a rewrite of anything. Yes, it compiles JavaScript and uses TypeScripts typing syntax, but it has different features and semantics compared with TypeScript. It’s like saying C++ is a rewrite of C.
I think the HN title is pretty misleading.
I don't know what it is about this name but I just can't not read it as "enzo".
Very cool! I'm curious, is this intended for dev tooling?
For example, I could see this (or something similar) being useful as the engine for a typescript language server that would be faster than the standard one
But if it's not aimed at 1:1 with tsc, would it be intended more for something like swc[1]?
Or what would you expect people to use this for, besides just being a cool project to learn from?
[1] https://github.com/swc-project/swc
The analogy (by swc's author) would be https://github.com/dudykr/stc
Discussion from when it was first announced: https://news.ycombinator.com/item?id=32941613 (2022-09-22, 175 points, 98 comments).
The issue has always been that people start these projects, see just how big/hard checking the whole of TypeScript is and don't finish it.
It would be awesome if you finished it :]
Naw. Projects like these are useful reninders that 25 years of mitigation easily save a few weeks of initial design.
Perfected developers don't need two weeks of initial design or any mitigation.
does TS even have a spec? I thought the type checking rules are basically "whatever tsc does"
There is a specification but it's fallen a bit behind the implementation. Of course the implementation is open source, pretty well documented and covered in lots of tests. So, you could think of that as a living specification.
Some pointers from this stackoverflow discussion:
https://stackoverflow.com/questions/52148566/is-the-typescri...
Which means being always behind. I rather have the Typescript team improve the experience, on their bootstrapped compiler.
Yeah, stc seems to be just using the TypeScript test suite as a proxy for completeness. Pretty far along, but unclear when it will actually be usable.
https://stc.dudy.dev/blog/this-week-in-stc/week-23
I haven't looked at the source, but the way to write one of these that's fast is to use incremental computation. [0]
It tends to take a lot of RAM, but the speedups possible are 3-5 orders of magnitude in the projects I've studied.
Here's a parallel C++ library to do so that requires relatively minor changes to the original algorithm. [1] [2]
I also believe it would be possible to develop a compiler framework to do the transformation mostly automatically, using an MLIR dialect.
[0] https://en.wikipedia.org/wiki/Incremental_computing
[1] https://dl.acm.org/doi/pdf/10.1145/3409964.3461799
[2] Source code: https://github.com/cmuparlay/psac
Does this have tsconfig support, or is it only checking on a per-file basis so far?
Just one file at a time for this preview. Eventually want to decide some customisations/options inline with tsconfig.