TypeScript to C++(github.com)
github.com
TypeScript to C++
https://github.com/ASDAlexander77/TypeScript2Cxx
14 comments
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!
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.
The compilers with C++ target on that list don't "do a lot more". The others are not directly comparable.
yakir22/ts2cpp compile to C++, has GC, FFI and etc. Canvas example: https://github.com/yakir22/ts2cpp/blob/master/TestScripts/Gr...
I stand corrected. The readme gave the impression of a much less mature project.
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.
https://www.haxe.org/
https://www.haxe.org/
Haxe is definitely underrated in the industry. It's a real surprise why someone like Microsoft hasn't tried to partner with the platform.
Haxe has been around for a while. I don't understand why it's never become a mainstream technology.
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.
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.
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.
Yeah, sadly for Vala and our CPUs, there is too much JavaScript love at GNOME.
However the conversion from some GNOME components to Rust, seems to still be ongoing.
However the conversion from some GNOME components to Rust, seems to still be ongoing.
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.
`shared_ptr` would get you most of the way there (except for cycle collection).
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.
Garbage-collectors often don't release memory either. Just don't produce so much garbage, do more recycling yourself, you'll be fine!
I'm only half-joking.
I'm only half-joking.
A similar alternative (a TypeScript subset that compiles to WASM): https://github.com/AssemblyScript/assemblyscript
Looks interesting, I think I'll try this out with arduino.
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.
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.
> You'd be jumping through so many hoops
Jumping through hoops is a good metaphor for fun.
Jumping through hoops is a good metaphor for fun.
That’s what I’d be interested in also.
Seems like a syntax-directed translation that doesn't really respect TS or C++ semantics?
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.?
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.
What could go wrong... :)
Can’t say I’ve ever seen the “any” keyword in C++ before
It’s not a keyword, it’s a strict defined in core.h
It is a type adopted in C++17.
https://en.cppreference.com/w/cpp/header/any
https://en.cppreference.com/w/cpp/header/any
love this!!! keep it up
kill it with fire
Why?
Maybe I want to have a C++ (native) port of my web library. I may want to start by transpiling my TS code (interfaces and classes) to C++.
I also wonder why isn't there to C# yet?
I also wonder why isn't there to C# yet?
You're not going to port existing libraries with this. They will have to be written in a subset that is easy to compile.
GraalVM's native image has the same trade off.
GraalVM's native image has the same trade off.
* 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