Why Go Is Not Good

Re:Why Go Is Not Good by Peaker on Monday June 30, 2014 @12:47AM (#7963738)

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.

[ Parent | on HN ]

Re:Why Go Is Not Good by zik on Monday June 30, 2014 @07:59AM (#7964593)

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.

[ Parent | on HN ]

Re:Why Go Is Not Good by Peaker on Monday June 30, 2014 @10:14AM (#7965119)

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

[ Parent | on HN ]

Re:Why Go Is Not Good by stcredzero on Tuesday July 01, 2014 @04:57PM (#7973463)

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

[ Parent | on HN ]

Re:Why Go Is Not Good by Peaker on Wednesday July 02, 2014 @01:53AM (#7975454)

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.

[ Parent | on HN ]

Re:Why Go Is Not Good by rogpeppe1 on Tuesday July 01, 2014 @10:04AM (#7970701)

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

Well, not that small, i guess :-)

[ Parent | on HN ]