I'm hacking on a PureScript-to-Go transpiler (ie. alt backend for existing PureScript compiler once PR #3117 gets accepted). Watch http://github.com/metaleap/gonad/ --- hoping to "get there" within 2 weeks. Taking unreasonably long already, given that purs already does its jobs on its own like parsing, type-checking, transforming-ML-to-imperative. One reason I'm taking a bit longer than the quickest-dirtiest approach would, I want to preserve the type information as much as possible rather than have all functions accepting and returning and passing `interface{}`s in a JS-like manner. Ie it's meant to generate sane readable human-like idiomatic Go code. Type-classes mapped to interface types, etc. Will also have to attack the need to have any Go package be represented readily on the PureScript side as an existing module that'll show up in auto-complete and pass compilation, so to quickly auto-generate some kind of dummy FFI bindings whenever a Go-land dep is imported and used. Fun ride!

There's clearly value in combining Go's compilation speeds, stdlib functionality, rich ecosystem, lean fast binaries, GC etc with a rich and cutting-edge Haskell-ish/ML-ish type system (and the leaner syntax and compressed idioms). Will be great for clear thinking and expressive high-level type-driven dev and DSLs (and naturally, implicitly generics/code-gen haha), without having to wrestle with GHC/cabal/stack build annoyances/times and Haskell's whacky academic overly-PhD-ish "wrappings" around raw straightforward real-world needs such as http-server and db-client, where again the Go ecosystem shines.

Thanks for the tip! I'll keep an eye on it.

I don't get how low latency GC can be a good selling point.

I mean, sure, the Haskell's GC is a big downside, but if latency is so important that you have to look how the performance of you GC compares to an usual language, why don't you go with a language with no GC for once?

Because once you start to look at the details, you will need all of them, and how deterministic is Go's GC performance? What's its 99th percentile? What's the 99.999th percentile? Will any of those change in a future version?

Games. I like low latency and garbage collection. I feel like, hey, it's 2017, those things (along with performance within a reasonably small multiple of C's) really should go together.

Java and .Net games seem to have no problem getting into 120fps. Go's GC is optimized further.

120 fps is a measure of throughput, not latency. A high frame rate is good, but it's no guarantee that you're not going to drop a frame. Dropping a frame kills the experience, especially in VR.

In any case, .Net (and I gather Java) games typically go to considerable trouble to reduce GC pressure by pre-allocating memory pools and reusing them during execution. For certain kinds of games, like where you load everything in a level up front and don't deallocate until you finish, that can be fine. For other kinds of games, that's a nasty constraint to try to deal with. It ends up bending your architecture in ugly ways that make it hard to develop the game.

Well, that's a good rationale. That's indeed a good reason to look into Go.

If you want a nice ML with low GC latency, how about Rust?

(Did you look at tuning the GC? As a Scala guy I know a some people write off the JVM because the default GC settings are optimised for throughput rather than latency (whereas Go does the opposite), when often their requirements are comfortably within what the JVM can do when suitably configured. That said I've heard the CLR is less tuneable)

Rust is too complicated for me to learn and be productive with in a reasonably short period of time, and the CLR is not good at keeping GC pauses down. :-(

I have high hopes for Pony, though.