Hacker News Reader

Comment by stcredzero | Hacker News Reader

Depends on your particular value of "better." If you're optimizing for programmer time, writing a language in Go is not a bad tactic. You get out of having to write your own GC, you can incorporate a few nice concurrency features with little effort, and you still get pretty good performance. (Admittedly, far from the best performance, though.)

View on HN

Writing a language in Go, which doesn't have sum types won't be fun.

Also, if you want to implement a compiler, and not an interpreter, the host language having GC is not very useful to get GC.

Haskell is going to make working with ASTs much easier and safer. It also has a superset of the concurrency features of Go.

I'm writing a language in Go. It is fun. Sum types (and ASTs) are implemented with interfaces which provide a pretty clean and type safe way of doing this.

Can you show some small example encoding of an AST in Go?

http://golang.org/pkg/go/ast/

Well, not that small, i guess :-)

The code for Twik has a simple AST in it. Of course, it's Lisp, so it's perhaps too simple.

http://blog.labix.org/2013/07/16/twik-a-tiny-language-for-go

The duplication there in each AST node kinda hurts the eyes :)

Also, the type-switch on interface {} is ugly.

Consider how an AST looks like in Haskell:

  data AST
    = LiteralInt Int
    | LiteralFloat Float
    | List [AST]
    ...

And then an eval looks like:

  case ast of
    LiteralInt int -> ...
    LiteralFloat float -> ...
    List nodes -> ...

and it is safe, rather than interface{}, you get the AST type and you get exhaustiveness checking that you covered all cases.

Also, if you add an annotation to each AST element (e.g: inferred types), you can very easily and safely map over them, etc.

>You get out of having to write your own GC

You also don't have the ability to write a GC-less language, because there is no practical way to write non-GCed Go code.

>you can incorporate a few nice concurrency features with little effort

You also can't implement any custom OS-level concurrency features.

You also don't have the ability to write a GC-less language, because there is no practical way to write non-GCed Go code.

True, so you probably don't want to do that.

You also can't implement any custom OS-level concurrency features.

True. But for "journeyman" level language implementation, the toolset is quite good.

Most of those seem to be things that could arguably be "implementing a language that compiles to Go and then leverages the Go compiler & runtime", which is pretty much orthogonal to "implementing a language in Go".

>You get out of having to write your own GC

No, you really don't. The built-in GC is nothing like the GC needed for lots of other languages.

The built-in GC is nothing like the GC needed for lots of other languages.

Don't write those languages in Go.

That kind of defeats the whole idea that it's a good language for writing other languages in.

Not to mention that to use the GC, you'd have to carry the whole baggage of Go's runtime with you in the new language. And that's Go's GC is not that good in the first place.

There are different levels of language implementation. Doing it in Go is more of a "Journeyman" level. If something like the Go runtime is going to enable more people to have written an interpreter, then this is a good thing. Most people's implementation of GC will probably be no better or worse than Go's.

Reply on news.ycombinator.com