TypeScript to C++ | Hacker News Reader

TypeScript to C++

github.com

117 pointspjmlp39 comments

Other TypeScript to C/C++ projects which did a lot more:

* 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

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.

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.

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!

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/

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.

Haxe is definitely underrated in the industry. It's a real surprise why someone like Microsoft hasn't tried to partner with the platform.

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++?

`shared_ptr` would get you most of the way there (except for cycle collection).

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.

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.

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.

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.

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.

That’s what I’d be interested in also.

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

Jumping through hoops is a good metaphor for fun.

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.?

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... :)

Weird that strings are passed by value instead of reference

Looks like they aren't std::string though, so maybe they're refcounted and behave like a shared pointer.

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

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?

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.

Reply on news.ycombinator.com