Hacker News Reader

Comment by kodablah | Hacker News Reader

I always wanted to see a Go/Nim interop project in a little different vein. Since Nim is a superset of Go (and Go is fairly simple), why not a Go implementation in Nim via cross-compilation? Then you can even build a Nim macro that does a "Go get" and Nim developers can use Golang libraries right in their code as imports. Not to mention we get a full, alternative Go impl.

It should be easy to bootstrap by first using Go's parser to dump some AST that Nim code can then translate, and then once that version is done, just reference the Go parser using this new impl. The only real struggle with the project from what I can see is deciding which standard library items to use the Go transpiled implementation (probably most of them) vs which need to have Nim backends (e.g. runtime package). Meh, just rambling thoughts in my head I was considering playing with given the time...

View on HN

> Since Nim is a superset of Go

I seriously doubt that Nim is out of the box binary compatible with another runtime's fundamental types.

I am not looking for binary compatibility. I am looking for feature parity. Go interfaces can be handled with concepts [1] or just macros. I am talking about an alternative Go implementation (i.e. just sitting on top of Nim), not ABI compat between the two runtimes.

1 - http://nim-lang.org/docs/manual.html#generics-concepts

Along that way is C++ and "we should attempt to be a superset of all programming paradigms". Fewer features is better, and more restrictions allow better tooling and iteration if they don't functionally restrict the programmer.

Basically, I'm not sure of the benefit of building go on top of nim. They appear to fill the same space in orthogonal ways.

> Since Nim is a superset of Go

what ?

I was under the impression this was true feature-set wise. I may be wrong though and am happy to be corrected.

Almost. Go had the advantage of M:N threading with its goroutines and elegant CSP implementation.

Calling something a superset usually means it's actually an expansion of something... kind of like C++11 might be a superset of C++03 (not sure if that's accurate).

That's a really strange metric to use. It'll rarely be true, except in a sort of Turing completeness way.

> why not a Go implementation in Nim via cross-compilation?

Nim's macros have one limitation that prevents an accurate implementation of another syntax: they can't fully modify the existing syntax.

See how I had to use "scase" inside "select" blocks because the existing "case" keyword insists on having "of" after it. So Nim's semantics put some limits on the amount of hijacking one can inflict on it through macros.

If you front compilation with Go's parser, you could generate bog-standard Nim code from the AST.

You can, but you'd be limiting yourself to pure Go. I'd rather have Go with Nim's generics, transpilation to C, macros, compile time computation, etc.

I don't believe they should accept the full Golang syntax, just help with the import. E.g.

    macro goImport(path: string): stmt
      // TODO
      discard
    
    goImport("golang.org/x/crypto/nacl/box")

Reply on news.ycombinator.com