Goscript: Transpile Go to human-readable TypeScript

nzoschke 2 hours ago | parent | next [-]

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.

▲

lowmagnet an hour ago | parent | prev | next [-]

Wait, go isn't human readable?

	▲	dieggsy 34 minutes ago \| parent [-]
		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.

▲

tdaron 40 minutes ago | parent | prev | next [-]

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)

▲

tayo42 3 hours ago | parent | prev [-]

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

▲

adsharma 2 hours ago | parent | next [-]

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.

▲

jerf 3 hours ago | parent | prev [-]

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

▲

unsnap_biceps an hour ago | parent [-]

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.

	▲	antonvs an hour ago \| parent [-]
		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.