3 ms·

I think what we'll see coming soon, assuming some people work on it, is the recognition that Go's stdlib and all the supporting libs is where the real awesomene

I think what we'll see coming soon, assuming some people work on it, is the recognition that Go's stdlib and all the supporting libs is where the real awesomeness lives. And for langs that support Go-style concurrency (like Crystal basically does, Kotlin, etc), people will start transpiling with only a couple of things dropping into the target language. There're just too many good pieces of crypto, http2, etc to rewrite it over and over.

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 ago
  I'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

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 ago
I'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