4 ms·
I can attest to this, the amount of times I've had a look and used go's stdlib as a reference for what to do when implementing something in the std for crystal
by RX14 8y ago
I can attest to this, the amount of times I've had a look and used go's stdlib as a reference for what to do when implementing something in the std for crystal is too many to count!
Unfortunately, transpiling has a huge bunch of problems, which you can see in for example how quickly nim vs crystal compiler matured - even though the crystal compiler is more complex. I'd be interested in seeing go's stdlib, ssa backend, and toolchain turned into a robust library. Like LLVM but including a GC, a stdlib with a CSP implementation, and a complete toolchain for static compilation.
- kodablah 8y agoI'm curious about the transpiling problems from, say, Go to Crystal (not after SSA, but before w/ the high level constructs). I have toyed with Go to Kotlin and even though duck typing is unimplemented in the latter, I can basically get there. I even started a project to dump Go AST and type info[0] but I haven't completed it really. There are just too many amazing Go libs out there to not exercise this option. Go does have a buildmode for c-archive and c-shared, but it's built around the hobbled Cgo, so you have to explicitly export funcs, and things like structs cannot be exported. Still, a swig-like shim/bridge could be developed, but I am unsure at what cost (I think the go mobile stuff does a form of this). 0 - https://github.com/cretz/go-dump https://github.com/cretz/go-dump