Try this! It works going the other way, just use esbuild to target ES2020 before you run in it. If you want to transpile to Go that's also interesting, probably tsgo's ast parser can be leveraged to do that. See: https://github.com/aperturerobotics/go-quickjs-wasi-reactor
There are a number of little projects like that but I'm not aware of any that have attained liftoff.
Javascript was a weird exception, being rigidly the only thing available in the browser for so long and thus the only acceptable "compile target" for anything you want to run in the browser. In general I can't name very many instances of "write in X and compile it to Y", for some Y that isn't something you are forced to use by a platform, being all that successful. (See also assembler itself.) The Javascript world gives a false signal of this being a viable approach to a project; in general it doesn't seem to be.
(Note this is a descriptive claim, not a normative one. I'm not saying this is how it "should" be. It just seems to be the reality. I love people trying to buck the trend but I am a big believer in realizing you are trying to buck a trend, so you can make decisions sensibly.)
I keep waiting for a LLVM IR reverser. If there's a LLVM IR to foo reverser written, you would be able to use any language supported by LLVM and convert them to foo. It seems like a much better solution than all the disparate one-offs that exist today.
You may be waiting a long time. Low-level IRs lose a lot of information compared to the source language - their purpose is only to execute correctly, which means a lot of the information that we depend on when reading code is eliminated. I'm reminded of Hal Abelson's quote, " "Programs must be written for people to read, and only incidentally for machines to execute." IRs are the opposite of that. In general, a reverser is going to suffer because of that.
I did some reverse engineering of compiled C code back in the day. Back when compilers and CPUs were simpler, and optimizations were fewer, it was relatively straightforward for a human to do. That's no longer true. I suspect an LLM would have difficulty with it as well, plus the non-determinism that would introduce would be likely to be problematic.
Not sure if humor, but this is meant to make a distinction with a non-human readable compilation target, many of which aren't, even when using high level languages.
hey ! i like the idea but I don't get why not using WASM instead of transpiling ? (I get the "transpiled typescript might be more readable" argument, but it seems less bullet proof / prone to unexpected behavior)
There are many environments that don't support WASM yet. Plus, JavaScript is a lot lighter weight for some things - particularly if you just need to register a bunch of callbacks that process data when events come in. I'm using WASM too quite a bit, though! Try out tinygo, gopherjs, or Go's built in wasm/wasi support for that.
Neat! I have experimented with various ways to convert Go structs to/from TypeScript interfaces.
- https://quicktype.io/
- https://github.com/danielgtaylor/huma then OpenAPI -> TS
- https://github.com/gzuidhof/tygo
- https://github.com/coder/guts
guts also does some AST stuff.
It seems like this project could help with this and then some.
Interesting I feel like I'd rather go the other way, write something in a language with nice syntax and features, then transpile to go
Try this! It works going the other way, just use esbuild to target ES2020 before you run in it. If you want to transpile to Go that's also interesting, probably tsgo's ast parser can be leveraged to do that. See: https://github.com/aperturerobotics/go-quickjs-wasi-reactor
There are a number of little projects like that but I'm not aware of any that have attained liftoff.
Javascript was a weird exception, being rigidly the only thing available in the browser for so long and thus the only acceptable "compile target" for anything you want to run in the browser. In general I can't name very many instances of "write in X and compile it to Y", for some Y that isn't something you are forced to use by a platform, being all that successful. (See also assembler itself.) The Javascript world gives a false signal of this being a viable approach to a project; in general it doesn't seem to be.
(Note this is a descriptive claim, not a normative one. I'm not saying this is how it "should" be. It just seems to be the reality. I love people trying to buck the trend but I am a big believer in realizing you are trying to buck a trend, so you can make decisions sensibly.)
I keep waiting for a LLVM IR reverser. If there's a LLVM IR to foo reverser written, you would be able to use any language supported by LLVM and convert them to foo. It seems like a much better solution than all the disparate one-offs that exist today.
You may be waiting a long time. Low-level IRs lose a lot of information compared to the source language - their purpose is only to execute correctly, which means a lot of the information that we depend on when reading code is eliminated. I'm reminded of Hal Abelson's quote, " "Programs must be written for people to read, and only incidentally for machines to execute." IRs are the opposite of that. In general, a reverser is going to suffer because of that.
I did some reverse engineering of compiled C code back in the day. Back when compilers and CPUs were simpler, and optimizations were fewer, it was relatively straightforward for a human to do. That's no longer true. I suspect an LLM would have difficulty with it as well, plus the non-determinism that would introduce would be likely to be problematic.
If there is such an interesting language, you can transpile to static python first and then use py2many to gain access to many systemsey languages.
The other option is to evolve static python into such a language. Looking forward to the PEP that proposed DSLs in Python.
Wait, go isn't human readable?
Not sure if humor, but this is meant to make a distinction with a non-human readable compilation target, many of which aren't, even when using high level languages.
hey ! i like the idea but I don't get why not using WASM instead of transpiling ? (I get the "transpiled typescript might be more readable" argument, but it seems less bullet proof / prone to unexpected behavior)
There are many environments that don't support WASM yet. Plus, JavaScript is a lot lighter weight for some things - particularly if you just need to register a bunch of callbacks that process data when events come in. I'm using WASM too quite a bit, though! Try out tinygo, gopherjs, or Go's built in wasm/wasi support for that.