3 ms·
I would rather fight the borrow checker now than fight race conditions, use after free, or buffer overruns later.
by thesuperbigfrog 4y ago
I would rather fight the borrow checker now than fight race conditions, use after free, or buffer overruns later.
- bmitc 4y agoSeveral fast languages with garbage collectors have none of those problems.
- enedil 4y agoWhich one prevents race conditions?
- bmitc 4y agoWell, for one, Rust doesn't. And I think you mean data races and not race conditions, or at least race conditions with regards to data/memory access. I don't know of a language that prevents race conditions. In Elixir and Erlang, mutating data is impossible, so those. A language like F# makes it easy to avoid race conditions as well, but it is possible if you use classes or the mutable keyword. Even then, you will not corrupt memory and are only having race conditions in terms of the order in which data is accessed. But is rarely a problem with a functional first approach. I never even need to use a debugger with F#. Any language with asynchronous computations will have race condition surface area, but there are several high-level languages that makes this difficult.
- amalcon 4y agoThe only ones I can think of with literally none[0] of those problems use a shared-nothing concurrency model. Usually, that's fine -- downright pleasant, even. Occasionally, it's a real problem to accomplish something in a shared-nothing environment. [0]- Well, assuming "race conditions" means "data races". Obviously no tooling can prevent race conditions in general.