The concurrency and threading in Go just feels like magic compared to every other language. I'm a goroutine addict and I refuse to be rehabilitated.
Just from observations over the years, I don't think there's any other language quite like this, in terms of how things can end up happening in any thread.
I was amazed how well are goroutines integrated into the language when I saw the first videos from Rob Pike. Then I actually started using Go for concurrent code, and noticed one thing, it's extremely easy to leak goroutines. There is no proper way to cancel them, they need to cooperate via select/context. Go developers eventually learn hacks to deal with it, but the simple go+chan style of programming style you see in tutorials is usually not safe. I still consider Go a remarkable piece of software. The runtime really doesn't have any seriously bad edge cases, it just works. But as a developer, I now prefer a slightly more explicit approach to concurrency. I've spent the last year developing an async runtime for Zig and I'm now more comfortable writing concurrent code in Zig than I was every using Go. I have more options for how to handle closed channels, I can cancel any operation, etc.
Never really thought about this but it seems to me that if you want to launch separate processes? Goroutines are built around functions, so you're just stuck with function semantics. If you want an entire process, you just invoke self with a feature flag on your binary and control a subprocess. If you need to communicate you establish your own message passing channels with STDIO or something.
I don't feel this is hacky or even a work around. Just different promises on what goroutines are vs threads/concurrency/processes in other languages.
Exit and panics are promised at the process level in Go.
No, this has nothing to do with processes. It has to do with the `context` package, which the best way to do goroutine cancellation in Go, but if you look how it works under the hood, it requires a lot of hacks, because there is no direct cancellation support for operations in the runtime. For example, every single `Read()` in the standard library would have to be wrapped by `AfterFunc()`, not all of them actually do it, so some reads are cancellable, some reads are not. It's all just best-effort with no guarantes.
SamInTheShell · · focus · HN ↗
Just from observations over the years, I don't think there's any other language quite like this, in terms of how things can end up happening in any thread.
lukaslalinsky · · focus · HN ↗
SamInTheShell · · focus · HN ↗
I don't feel this is hacky or even a work around. Just different promises on what goroutines are vs threads/concurrency/processes in other languages.
Exit and panics are promised at the process level in Go.
lukaslalinsky · · focus · HN ↗