[dgunay]

It is mostly an example of the mindset that I think GP is trying to illustrate.

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.

Go has generics, but only after a decade of pressure from users (and even then, they are much much less useful than Rust's type system).

I like Go and I feel very productive in it, but its commitment to simplicity is dogmatic in many ways and it very much is missing milestone advancements in PLs from the past several decades. It could easily have been made in the 90s.

[christophilus]

I would love a language that combined the best aspects of Go and F#: expressive, great type system, fast compilation, native binaries, opinionated formatter, excellent concurrency, comprehensive standard library, consistent documentation, etc.

Throw in great compile to JS capabilities with small bundle sizes and the ability to map Typescript typings into the language so you can seamlessly consume well typed libraries, and man. Killer language, right there.

[dgunay]

Me too! Go's tooling and runtime are great, I just want a more useful type system.

[curun1r]

I feel like Go was built with primary design considerations that are often not considered publicly and often at odds with what programmers want out of a language. I saw one of the first public talks from the creators at Google I/O and they stressed two things: compilation speed and new developers coming up to speed quickly. From what they said, Google had a few C++ projects with multi-hour compilation times that, when profiled, showed about 90% of the time was spent reading header files. So a core Go philosophy was single-pass compilation to cut down compile times as much as possible. Similarly they stressed that the focus on simplicity meant there wasn’t as much variation in style of Go code and new programmers—even those unfamiliar with Go—could quickly come up to speed and contribute to a project.

Viewed through this lens, the resistance on the part of the creators to changes that compromise these values even a little bit makes sense. Generics take time to get used to and any code base that makes extensive use of them will take longer to get up to speed in, even if it enables you to move faster later on.

That talk has really shaped how I look at Go. I think it solves problems that Google has (really large projects built by teams that have a ton of turnover) really well. But as with a lot of things that emerge from Google, it’s a solution to a problem that not too many other companies face. The ones that do will get an awesome tool that’s proven to work. But the ones for whom it’s 90% of what they need are going to get a lot of pushback getting that last 10% accepted because it already does almost exactly what Google needs it to do and any departure from that will be, in their minds, counterproductive.

[dgunay]

I agree, I've mostly made peace with what Go is and I still enjoy using it.

It just tantalizes me because of how close it is to my ideal general-purpose programming language. There is a large middle ground between the minutes-long compile times of Rust and the seconds-long compile times of Go.

[ncmncm]

If such a compromised process produced something close to your ideal, that should worry you deeply.

[justinsaccount]

As someone that writes a bunch of go but has never really gotten off the ground with rust:

  * Option? I don't mind if err != nil, but sure, it would simplify some things.
  * Result and real tuples? awesome.
  * real enums? sign me up.

If that was all added to go I wouldn't mind at all. But what does any of that have to do with

  impl<'a, H, Fut, Tail> Execute<'a> for Dispatcher<H, Tail>
  where
    H: Fn(&'a Update) -> Fut + Send + Sync + 'a,
    Fut: Future<Output = ()> + Send + 'a,
    Tail: Execute<'a> + Send + Sync + 'a,
  {

[dgunay]

It doesn't, primarily the way I saw the discussion heading was (warning: strawmen ahead):

> "Go is a good alternative to Rust because it is easy to write performant, concurrent code"

> "Go is not very comparable to Rust. I won't describe why, here's a quote by Rob Pike and I'll strongly imply it's because its creators deliberately avoided complexity, even where useful."

> "You did not explicitly criticize anything about Go, therefore it must not have flaws"

Then I came in and described exactly where I feel Go ignores the state of the art in PLs.

> But what does any of that have to do with (Rust-shaped vomit)

Go doesn't need all those type system gymnastics because it does not have the problem of the borrow checker to deal with and doesn't promise to avoid segfaults for you.

[int_19h]

It is a serialization of relative lifetimes, basically. Whenever you write code in any language that doesn't have a GC, you either have to maintain a mental map like this to avoid bugs, or you make the language do it for you like Rust does.

[0des]

Shit like this makes my brain hurt

[ngrilly]

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.

[dgunay]

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.

[int_19h]

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.

[ngrilly]

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.

[int_19h]

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.

[ngrilly]

I absolutely agree with everything you just wrote and would use a language like that.