3 ms·
> i am always asking myself, how often "little" things like race conditions break something in production It can basically corrupt the whole program. I bet h
by camus2 10y ago
> i am always asking myself, how often "little" things like race conditions break something in production
It can basically corrupt the whole program.
I bet half go apps out there have data race. People who boast about Go's simplicity can't even see the elephant in the room. A simplistic type system doesn't fix unsafe concurrency. You'd think that safe concurrency would be an important design goal for a highly concurrent language, well apparently it isn't.
- fortytw2 10y agoIn fairness, Go has an extremely good race detector (run/test with -race to enabled it), and makes no guarantees about memory or correctness if you write code with races in it
- llogiq 10y agoLast time I checked, the race detector could only find a certain percentage of data races – those easier to detect . The crux with such systems is you tend to rely on them...
- moomin 10y agoSpeaking as an experienced programmer: all the time, in subtle ways, sometimes that you don't notice for a long time. Sometime benign, sometimes your data has been being corrupted for months before you notice. My standard advice on concurrency is, quite simply, don't. It always looks way simpler than it actually is. If you're doing something that _requires_ it, get all the help you can. Type-level enforcement sounds _excellent_ to me.
- macintux 10y agoIf you want to avoid data corruption in concurrent software, there's always Erlang as an option.
- pimeys 10y agoI haven't checked Erlang too well, but is it so that the concurrency in Erlang software is basically actors only? Of course in this space you can also use Akka and even Rust and C++ have actor libraries available. But there are definitely use cases where you don't want to use actors, where you might want to compose several futures together without the overhead of actor mailboxes.
- masklinn 10y ago> it so that the concurrency in Erlang software is basically actors only? Erlang's concurrency is "don't communicate by sharing, share by communicating" enforced at the language level: an Erlang system is composed of processes which each have their own heap (and stack) and an incoming "mailbox", an Erlang process can only interact with the world by calling BIFs (built-in "native" functions, Erlang syscalls if you will) or sending messages to other processes, and messages can only contain immutable data structures (mutation happens only at the process level). Of course one of the sources for this design is that Erlang comes from a world where 1 = 0 (if you don't have redundancy you don't have a system) thus two processes may live on different nodes (erlang VMs) on different physical machines and shouldn't behave any differently than if they were on the same node.
- pimeys 10y agoSo basically it's like Scala/Akka, except in Erlang you can send functions which is a nice feature. One thing that has kept me from using it in production is its dynamic typing. Once you've been spoiled with a good type system, it's quite hard to go back to dynamic typing.
- macintux 10y agoAkka is modeled on Erlang but the JVM has very different characteristics. The Erlang VM is optimized for immutable languages and message passing. GC is very different (almost a non-issue) because of the process model. And pattern matching in Erlang is a joy every developer should experience. I've not been impressed with my limited exposure to Scala, which also bears the burden of trying to be a kitchen sink language.
- MichaelGG 10y agoYep. I deal with a platform that has some sort of race and accesses a destroyed object. It's incredibly tricky to find it, and customers only hit it at the worst time, with certain traffic loads. It's a subtle bug that's lasted years and is in a codepath used millions of times a day.