While I appreciate the direct link that bypasses the email form, here's the page describing the report and its author:<p><a href="http://www.oreilly.com/programming/free/why-rust.csp" rel="nofollow">http://www.oreilly.com/programming/free/why-rust.csp</a><p>"One of the original designers of the Subversion version control system, [Jim Blandy is] a committer to the SpiderMonkey JavaScript engine, and has been a maintainer of GNU Emacs, GNU Guile, and GDB."
From page 19:<p>> But all those other languages include explicit support for null pointers for a good reason: they’re extremely useful. [....] The problem with null pointers is that it’s easy to forget to check for them.<p>There is no inherent reason for that; just that mainstream languages which support `null` haven't been checking `null` usage. Some of the recent ones do. For example, Kotlin has non-nullable types by default, and null types have to be explicitly marked and checked for null-ness.<p>Even for Java, null analysis is built into Eclipse with the help of annotations. Though, ofcourse, it would be far nicer to have it baked into the language.
The book is exactly what it says it is. "Why Rust", an argument for Rust. 50+ pages. It's a fun read, but not too useful. My own comment on Rust is that the borrow checker is brilliant, and we'll see that again in other languages. The type/generic system picks up where C++ left off, and is very complex. But that may get better as the mess settles down and gets better documentation.<p>We now need a "programming in Rust" book which is not by one of the Rust developers, who are too close to the design.
<p><pre><code> The std::thread::scoped function used here is undergoing some redesign...
</code></pre>
/grumble /grumble<p>Yes, I know, it'll all eventually settle down, but darn its annoying at the moment trying to use stable.
I know this not the optimal place for this comment/question, but I think likely that many who are interested in this post would be able to speak to the post.<p>I'm also a huge fan of the Chapel Programming language. Anyone else think they're both hitting a sweet spot and would potentially have a beautiful love child?
There is nothing in Rust that would ease solving hard problems. Graphs are unsupported. No transactional memory. No distributed computing. No migration. No support for trying. No memoization. No proofs.
> It’s very difficult to write multithreaded code, which is the only way to exploit the abilities of modern machines.<p>QED? Really? I'm not so sure I trust the author to give rust fair treatment anymore. An operating system that does multithreading is not the same as a modern machine.<p>Edit: Any brave down voters want to explain why? Threads are a way to model concurrency. There are other ways.