Hacker News Reader

Comment by OutOfHere | Hacker News Reader

If you are worrying about cache structure latencies in Go, maybe you should just be using Rust or Zig instead that implicitly handle this better.

View on HN

Not necessarily: you can go quite far with Go alone. It also makes it trivial to run "green threads" code, so if you need both (decent) performance and easy async code then Go still might be a good fit. Despite Go being pretty high level GC language on the surface it actually allows you to control stuff like struct layout, CPU affinity, etc, which typically matter more for performance than just a programming language of choice. There's a reason why e.g. VictoriaMetrics is still in Go even though they could've easily chosen any other language too

In what way does Go have async?

Aren't goroutines by their nature asynchronous? Am I misunderstanding what you mean by 'async'?

Asynchronous is a programming style; it does NOT apply to Go. The goroutines run in parallel. Also, don't use complicated words when simple words will do.

    Asynchronous is a programming style; it does NOT apply to Go.

Ok, good to know. I guess I jammed threading and async into the same slot in my brain.

    Also, don't use complicated words when simple words will do.

I'm not sure what you mean by this in relation to my above comment.

In golang, there is no guarantee that goroutines will run in parallel; also, it is quite common to use channels as means of synchronization of results, akin to common async programming patterns.

> In golang, there is no guarantee that goroutines will run in parallel;

That's not specific to Go lang. Most of the constraints you're thinking of apply to all parallel programming languages. It goes with the territory. All parallel programming languages impose certain flavors of their management of parallelism.

Go is certainly capable of async programming. https://en.wikipedia.org/wiki/Asynchrony_(computer_programmi...

> The goroutines run in parallel. Also, don't use complicated words when simple words will do.

That’s not called for, especially since you’re wrong.

Well, essentially Go doesn't have a separate async keyword because all goroutines run asynchronously under the hood. In the beginning the advised (and default) way of running Go code was GOMAXPROCS=1, essentially ensuring there is no actual parallelism, just asynchronous code. Since then, of course, around Go 1.5, the default switched to number of cores, making goroutines both async and parallel

News for most folks, even writing C does not help, if neither of these advices are taken into account on how to lay out structures, nor algorithms are written with mechanical sympathy in mind.

Reply on news.ycombinator.com