Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

Note that we don't forbid shared mutable state entirely (we don't forbid anything really, as we have an unsafe sublanguage that allows all the pointer tricks that you can do in C++), but we want to contain data races. Basically, as the FAQ says, "you can break the rules, if explicit about where and how".

We've learned that, especially when it comes to concurrency, there really is no one model that supports everything you might want to do. Instead, the idea is to support safe, data-race-free language constructs, and to make those the easiest ones to use. Data races (and memory unsafety) are clearly marked in "unsafe" blocks, with the idea that if you find a concurrency bug in your software, you can grep for that keyword and go over those blocks only, instead of having to crawl through the entire codebase.

The same principle applies to null. You can get nullable pointers (use option<T>), but you have to declare that that's what you want. You also have to declare some strategy for handling the null case every time you use the pointer, or at least communicate your intent to fail on null via the .get() method. The vast majority of pointers in any program aren't nullable, so in practice we've found that this eliminates a lot of bugs.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: