Hacker News new | ask | show | jobs
by ngrilly 1481 days ago
3 issues you listed with Go are actually about the same thing (the lack of sum types):

- Go has nil where Rust has Option.

- Go has weird not-quite-tuple returns & if err != nil where Rust has Result.

- Go has no real enum concept, where rust has its powerful enums and matching constructs.

And the point on generics coming late is unfair. All programming languages got major features introduced late (for example async/await in Rust).

But I admit I'd love sum types, a less verbose error handling (but to be honest I'm not sure exactly how), and that I missed generics.

1 comments

Yeah I don't mean to criticize Go's generics for being less featureful given how late they were introduced, but they do currently prevent me from building any kind of mapping/filtering/pipeline style code because of their limitations (no generic type parameters on methods). A Go implementation of Result or Option could paper over the lack of sum types if we only had that.

The more I think about it, what I really want is something with the ML feeling of Rust, but in the space that Go occupies (good performance GC languages). Go frustrates me because it nails the runtime and tooling side of things but falls far short of it in the other ways I mentioned.

There's no shortage of good-perf languages with a GC: F# would be one prominent example that sounds very similar to what you describe.

The usual objection is that it requires a .NET runtime, whereas Go produces a single self-contained executable. But .NET can produce self-contained executables these days.

Yes, .NET can produce binary executables, but is it a common practice? I’m asking because I think the ecosystem matters a lot. If it’s a common practice, then it’s more tested and more stable and you get more tools and documentation.
It's a relatively recent feature, at least the "pure" implementation (what they had before was, essentially, a self-extracting binary), so it's still gaining popularity. But seems to be fairly common with containers.
I absolutely agree with everything you just wrote and would use a language like that.