5 ms·
According to Wikipedia, Go's concurrency-model is not safe, and that's a huge problem in my opinion: "There are no restrictions on how goroutines access shared
by nawitus 13y ago
According to Wikipedia, Go's concurrency-model is not safe, and that's a huge problem in my opinion:
"There are no restrictions on how goroutines access shared data, making race conditions possible. Specifically, unless a program explicitly synchronizes via channels or mutexes, writes from one goroutine might be partly, entirely, or not at all visible to another, often with no guarantees about ordering of writes.[36] Furthermore, Go's internal data structures like interface values, slice headers, and string headers are not immune to race conditions, so type and memory safety can be violated in multithreaded programs that modify shared instances of those types without synchronization."
- irahul 13y agoIdiomatic go concurrency uses channels for synchronization and passing data around. You shouldn't be writing to shared data from multiple co-routines.
- bascule 13y agoIt's easy to say that, but when Go added a race detector, they immediately found 40 data races in the standard library
- rdtsc 13y agoUse Erlang or Elixir then. They have truly isolated process heaps. Processes are lightweight and preemptively scheduled. You can spawn 100Ks of them on a single machine, each with its own isolated heap that can crash and not affect the rest of the system. That is kind of amazing.
- bascule 13y agoSidebar: Rust solves this problem by tracking the lifetime of memory throughout the program, ensuring there's no unsafely shared mutable state.
- rgbrgb 13y agoYou know you can write code with race conditions with nodejs too though, right? 2 callbacks called in the same closure can modify the same variable. I love node but after correcting many, many errors like this in intern code I question whether aync callbacks are strictly simpler than multithreading.