That’s me being very very generous and just restating the supposed goal of this effort since rust_codegen_gcc provides a much better solution to the “I want to be able to hit all the gcc targets”.
I’m not actually convinced that a new fronted actually helps as much for that effort especially when weighed against the very real downsides we see in c and c++. I have a strong suspicion that addressing under specified parts of the current implementation can be done more cheaply and effectively using other mechanisms.
Indeed, I don’t see the typescript community really complaining that there isn’t another implementation of typescript. And cpython remains the de facto Python implementation with other distributions seeing less adoption due to network effects and I don’t really see cpython benefiting from the existence of the other frontends.
> Indeed, I don’t see the typescript community really complaining that there isn’t another implementation of typescript.
There are actually numerous third-party implementations that can take TypeScript code and compile it to JavaScript. Babel can do it in pure JS/TS, SWC can do it in Rust, and ESBuild can do it in Golang.
The catch is that AFAIK none of these implementations enforce the actual type checks. This is usually called "type stripping" within the JavaScript community, but it's basically equivalent to the "Rust without the borrow checker" implementation that gccrs is working on.
Well, except that the Rust community is extremely ideologically opposed to "Rust compiler without the borrow checker" existing as a viable product, so you end up with the situation described in the article where that implementation is just used to compile a hybrid compiler with all the hard-to-implement type-checker stuff copied verbatim from rustc. That erases most of the spec-robustness benefits of doing a full third-party implementation, but there are still some practical benefits, like being able to bootstrap the compiler more easily.
And who knows -- if you hack the build to re-disable the borrow checker, the resulting compiler might run faster. (That's the main benefit of the third-party TypeScript implementations in practice.)
Typescript was written very intentionally to be really easy to transpile to JS which is why you see so many solutions. The type checking piece remains not reimplemented despite high profile third party attempts to rewrite it in a faster language. The type checking piece is exactly the thing that makes typescript typescript. And the reason the external frontend attempt failed is that it can’t keep up with mainline development which is also true for CPython and its offshoots. In fact, TS is so easy to strip that the syntax is being standardized within official ecmascript so that any type checking annotations could be layered into JS code and engines would natively strip without needing transpolation in the first place.
As for “rust without the borrow checker” it’s very much not the same thing as Typescript transpilation for many reasons among which are that there are many other language rules would still have to be enforced. It’s akin to making a TS type checker that didn’t validate 1 of the language rules but enforced the others.
I’m not opposed to a compilation mode that didn’t enforce the borrow checker but repeated tests of compiling various software packages reveal that the borrow checker is within the noise performance wise. So you’d need a more compelling reason than “maybe it runs faster”.
> repeated tests of compiling various software packages reveal that the borrow checker is within the noise performance wise.
Out of curiosity, do you have a source for this? The stuff I remember reading on the topic is from back in 2018 where they managed to get the NLL borrow checker to be not much slower than the old borrow checker (https://blog.mozilla.org/nnethercote/2018/11/06/how-to-speed...) -- but that took a concerted effort, and the borrow checker was overall a large enough contributor to compilation time that it was worth spending a bunch of effort optimizing it.
I’m not actually convinced that a new fronted actually helps as much for that effort especially when weighed against the very real downsides we see in c and c++. I have a strong suspicion that addressing under specified parts of the current implementation can be done more cheaply and effectively using other mechanisms.
Indeed, I don’t see the typescript community really complaining that there isn’t another implementation of typescript. And cpython remains the de facto Python implementation with other distributions seeing less adoption due to network effects and I don’t really see cpython benefiting from the existence of the other frontends.