Rust and SPARK: Software Reliability for Everyone (2017)
electronicdesign.com
electronicdesign.com
I wouldn't quite put it like that. I can't speak to SPARK, but Rust absolutely doesn't want to displace or discount the value of tools and processes--it wants to augment them.
Rust positions itself as one layer in a defense-in-depth strategy; that's the reason why Rust, despite striving to provide strong memory safety guarantees, still compiles programs with RELRO, NX, ASLR, PIE, basically whatever binary-level mitigations it can get its hands on.
As far as tools go, the Rust compiler is viewed as just the first tool of many. Rust recently changed the default allocator of Rust programs to be the system allocator rather than jemalloc (the system allocator was already the default on some platforms, like Windows), in order to (among other reasons) support Valgrind out of the box. And I don't know the current level of support for these, but Rust does eventually seek to support LLVM's various sanitizers: asan, tsan, ubsan, msan, etc. (currently I think these might work primarily on 64-bit Linux). Rust is also developing external tools of its own; see for example this blog post series from Ralf Jung about creating a tool to dynamically check the validity of unsafe code in Rust programs, with the eventual goal of having a formally-proven model: https://www.ralfj.de/blog/2018/11/16/stacked-borrows-impleme...
As for processes, one of the impetuses for locking undefined behavior behind the `unsafe` keyword was to better focus developer processes on writing and reviewing code. For example, Servo has a bot that comments on any PR that touches a file containing the `unsafe` keyword. In an organization using Rust, I would expect any first-time Rust programmers to be disallowed from checking in code using the `unsafe` keyword until they get a handle on the language.
https://rain-1.github.io/golang-aslr.html
https://insanitybit.github.io/2016/12/28/golang-and-rustlang...
Check rust should also not have these types of problems, but that doesn't mean that C libraries and other unchecked behavior won't. This is probably why Go does support ASLR.
I found the hardest part was stopping myself from using concepts I learned from python (e.g. Object Oriented stuff). I tried to make everything as class-like as possible. This always worked for a bit and then quickly started to make things immensly complicated. This was in fact never really necessary to solve the problem at hand. I learned to love custom data types, traits and the ability to just (for example) make my own Vec and extend it with some specialized functionality.
Rust has a incredibly good tooling and I use it more than Python nowadays.
I used this book in a Rust course and I can also recommend it. What is particularly nice about this book is that in the chapters about ownership, moves, and references (which is what most learners find the most difficult) it uses neat graphs to visualize memory layout. It also places Rust memory management a bit into context by comparing Rust's memory management to other languages that the reader might know. The largest shortcoming of the book is the lack of exercises.
That said, I don't think any of the books is as good as K&R or The Go Programming Language yet. The Kernighan books are lucid and contain a lot of small, but useful, exercises/practical examples. This gives a stronger sense of accomplishment while working through the book.
Edit: neat, its on safari queue, i don't need to buy a thing (sorta.... ignore that I pay for this yearly)
Agreed. Excellent book; very well paced and has a wonderful flowing narrative.
Otherwise, I too hope it pays off in the future. I'm an undergraduate and at the moment, I don't know one language fully. My background in programming has been sporadic and I would argue I'm in the middle of beginner and proficient in regard to writing C/C++. I'm most likely going to end up building a C/C++/Rust skillset - hopefully it pays off, particularly for landing a new-grad gig in a few years.
That said, I also encourage learning a wildly different language as well. If you know C/C++/Rust, then take a shot at something like Scheme. This is the advice that I wish that I had gotten in college, when I spent years doing nothing but Java, and then had to spend additional years practicing four other languages before I finally stopped trying to fit every program into a Java-shaped box. Having a wide variety of experiences to draw from will be useful in the long run. :)
Specially the best practices to write good quality code.
The need to interoperate with OSes, language plugins and system libraries written in C and C++ isn't going away for the foreseeable future.
Yet I still make the effort to have a grasp of what other languages offer in terms of tooling, paradigms, libraries, whatever.
It always pays off to learn.
I'm (re)learning rust (last i used it was 3 years ago), after Haskell/Idris/Agda its really not that big of a deal I find.
My only annoyance is similar to what JAI is intending to accomplish, that is RAII resource cleanup like c++ does isn't always the best solution.
But other than that its fine, I'm championing using it in a new project at work and testing it out for embedded things at home.