Why Go Is Not Good

Re:Why Go Is Not Good by stcredzero on Sunday June 29, 2014 @08:00PM (#7963002)

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.)

[ Parent | on HN ]

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 ]

Re:Why Go Is Not Good by wyager on Sunday June 29, 2014 @08:05PM (#7963013)

>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.

[ Parent | on HN ]

Re:Why Go Is Not Good by stcredzero on Sunday June 29, 2014 @11:15PM (#7963517)

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.

[ Parent | on HN ]

Re:Why Go Is Not Good by dragonwriter on Sunday June 29, 2014 @11:29PM (#7963554)

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".

[ Parent | on HN ]

Re:Why Go Is Not Good by coldtea on Monday June 30, 2014 @03:12AM (#7964071)

>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.

[ Parent | on HN ]

Re:Why Go Is Not Good by stcredzero on Monday June 30, 2014 @10:01PM (#7968815)

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

Don't write those languages in Go.

[ Parent | on HN ]

Re:Why Go Is Not Good by coldtea on Tuesday July 01, 2014 @05:13AM (#7969741)

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.

[ Parent | on HN ]

Re:Why Go Is Not Good by stcredzero on Wednesday July 02, 2014 @12:33PM (#7977939)

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.

[ Parent | on HN ]