Hacker News Reader

Comment by Hinrik | Hacker News Reader

Layperson here: what is special about Go's runtime, aside from the GC?

Chief design goals were radically easy concurrency and speed of compilation.

Speed of compilation feels like a distant second in terms of goals given the weird new generic features they keep adding..

I was fine with basic generics they complicated it quite a bit much for my liking.

What weird new generic features? Generic type aliases? Those aren't very complicated.

Is the Go GC that special? Is it even generational yet?

I'm not sure it would ever make sense to be. That makes the assumption tons of allocations get made that don't live long, which was(maybe is still?) more common in some languages. Go is more aggressive about not heap allocating, and has tools to help you avoid them.

It makes plenty sense to be. There aren’t many negatives and there are plenty of workloads that would benefit.

Idk, is it? https://go.dev/blog/greenteagc

> Is it even generational yet?

Is there any reason in particular it should be? Or are you just throwing random buzzwords around?

Anyways, https://github.com/golang/go/discussions/70257#discussioncom...

You seem to be really hostile for no apparent reason. There are plenty of reasons to be generational, there are lots of workloads that the current implementation might fall flat if it wasn't.

Goroutines?

It's literally the most sophisticated scheduling engine in the world.

In practice, Go can typically outperform Rust in throughput (using more memory), despite having a mountain of disadvantages against it in theory.

That's how good the Go scheduler/runtime is.

> n practice, Go can typically outperform Rust in throughput (using more memory), despite having a mountain of disadvantages against it in theory

This is a huge claim that disagrees with both my real-world experience and everything I've seen from artificial comparisons.

Every high performance Go system I've worked on has quickly reached the point where we're optimizing memory management and doing things that would have been explicit in a non-GC language like Rust anyway.

The Go runtime is amazingly optimized, but it comes with overhead over doing the same work directly in a lower level language.

Go has few issues with performance (lack of in-line union types, interface overuse, inefficient idioms reg. collections, some missed optimizations) but its seems plausible for a idiomatic Go program to outperform an idiomatic rust program in some situations.

Example: https://news.ycombinator.com/item?id=22336284

This is the first I've heard anyone claim higher throughput for Go than Rust. Any articles you'd point to to learn more?

I think one of the few performance benefits with a GC is that you can defer allocations. You can do that in Rust too though.

> It's literally the most sophisticated scheduling engine in the world.

That seems unlikely regardless of how good it is. This is a domain where state-of-the-art research is not in the public literature. Scheduling is an AI-complete problem.

I think this is interesting and warrants explanation. There are cases where a GC can be faster (sort of, Arenas get you most of the gains) but "the most sophisticated scheduling engine in the world" should be easy to at least partially support.

What benchmarks are you referring to?

Rust itself doesn't have a scheduler of course, I assume this is comparing against tokio or one of the other async executors?

What a joke, ignoring Erlang, and the custom schedulers from JVM and CLR runtimes.

Erlang's scheduler is not sophisticated, which is what makes it AWESOME.

but yeah. i would be surprised if the JVM's scheduler is not more sophisticated than go's if for no other reason than it has way more knobs you can tune. you know they put that knob in there because someone (probably Google cough cough) asked for it

The missing part is that if what is in box isn't enough, both JVM and CLR allow you to fully customise how the scheduling algorithm works.

Reply on news.ycombinator.com