Author of the second to last compiler -- although simple in scope, it was one of the more exciting pieces of our undergrad coursework projects to work through (translating a language into another language).
Implementing lexical analysis and parsing manually as opposed to using lex/yacc felt much more valuable to understanding the module, which was very useful for the exam. Definitely recommend the challenge!
Notable that the first three are TypeScript to LLVM, they are aimed for AOT compilation of TypeScript instead of source translation to C/C++. Together with a good FFI this could work better than source translation.
The compilers with C++ target on that list don't "do a lot more". The others are not directly comparable.
Seems like people looking for this solution might appreciate Haxe which is a strongly typed ECMA influenced lang that compiles to C++ and many other targets.
My guess is that it's mentally associated with Flash, and as such always had the image of being something built for maintaining old projects rather than create new ones.
Some of the biggest early Haxe users like Tivo were explicitly looking for a vehicle to transition off of Flash. That part of it definitely makes sense.
But more generally it is incapable of the kind of end-user tooling that attracts early adopters. This is because it targets everything, and so really using it means knowing the platform you target and being able to debug at both levels - it does what you would expect a best-effort compiler to do, but it does not try to magically cover up what's going on. You can be put at sea pretty quickly if things break several layers down.
And that makes Haxe a great technology and a less great product. When it's paired with a framework like OpenFL it seems to get a lot of interest though. I see it as a long-term "survivor language" since its premise is still valid - it will be able to keep hanging on, gradually accumulating more of a basis for itself.
I went ahead and skimmed the sample output C++ files for their test sources, but I have not yet seen everything in the project. I can not find an import for a garbage collector, so does this compile Typescript to non-GC’ed C++?
Looking at the example code in the readme, it looks like it doesn't even bother freeing memory. This project looks like it's just "write (a memory-leaking subset of) C++ in Typescript syntax". Maybe neat for educational purposes for people learning about the languages or learning about parsing, but doesn't seem directly useful.
I’ve looked a little more since I posted and I think your right as far as memory management goes. I hope this is a WIP project and not just a learning project doing what you guess. I think the idea/challenge of implementing a structural type system and then compiling it down to C++ more basic bidirectional checking style is interesting.
Doesn't Vala compile to C and handle memory safety somehow? Obviously that depends on some GObject stuff but I think a similar approach could probably be used in this case.
> Doesn't Vala compile to C and handle memory safety somehow? Obviously that depends on some GObject stuff but I think a similar approach could probably be used in this case.
Well, Vala still has some amount of manual memory management because it translates directly to GObject, not only for system resources but for types as well, so it isn't 100% memory safe, like Java or Javascript.
Vala is/was a great project, unfortunately, the C people at Gnome hated that and some Gimp maintainers refused to hear about Vala, and then it was blamed for I'm not sure what exactly by people who wanted to turn Gnome into a Rust project. The later also failed, because the same C guys don't want to hear about Rust either.
Interesting bits about internal politics at Gnome.
At that point I am wondering what the point of the project is... If you end up implementing a GC and all the other bells and whistles then it is possible that the end result is not much faster than just running a conventional Javascript VM. However, without a GC you are better off just writing C++ code.
At first glance, you create new object subclasses on the heap without cleanup. So it is obviously either very early or designed for rather short-lived applications.
At the risk of being downvoted into oblivion, why?
You'd be jumping through so many hoops to set up a build pipeline for transpiling Typescript into C++, let alone writing a BSP library in Typescript to interact with the Arduino SoC. ( Which is vaguely interesting, I'd still call it a fool's errand though. )
You'd surely be much better off investing the same amount of time and effort becoming proficient in writing C for the target platform.
This is interesting. What would you say would be the intended use case? I can imagine: Trying to introduce Typescript for Hardware Programming and continued development of legacy products written in C++?
Perhaps code related to Operating System drivers, etc.?
It would be nice if the README contained more samples of translated code.
For example, I'm really curious on how it handles string literal union types or union types of things with different base types.
* https://github.com/ovr/StaticScript * https://github.com/ts-llvm/ts-llvm * https://github.com/nervosnetwork/minits * https://github.com/andrei-markeev/ts2c * https://github.com/yakir22/ts2cpp * https://github.com/duncanhorn/ts2cpp * https://github.com/sebbekarlsson/typescript * https://github.com/andrejusk/typescript-compiler * https://github.com/sebbekarlsson/tscc
and etc