> Programming languages often defer reliability and security to tools and processes. Two initiatives--SPARK and Rust--state that language is key to reaching those objectives.
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.
In contrast, Go programs are not compiled with ASLR/PIE by default. Go's developers do not want to give up the debuggability of deterministic address space layout, comparing ASLR's extra protection to "seat belts in restaurants" because Go fixes these vulnerabilities at the language level.
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 am currently and avidly learning Rust. It's a steep learning curve, but I hope it pays off in future. And by pay off I don't mean financially, but creating some cool software.
I am essentially a art student who picked up some python and C along the way. I feel very comfortable with Rust (started a year ago). Make sure to read the books and maybe consider buying "Programming Rust" by Blandy & Orendorff which is easily one of the best language books I ever read, especially when combined with the free books available online.
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.
Make sure to read the books and maybe consider buying "Programming Rust" by Blandy & Orendorff which is easily one of the best language books I ever read, especially when combined with the free books available online.
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.
Programming Rust is the exact book I am referring. I am facing issues getting my head around the concepts as I was brainwashed by Java, Python, Scala and JavaScript. But it gets easier.
Yeah, same! I'm making my way through "The Book". Observations thus far: Other than fooling around with GatsbyJS, I've never had to work with dependencies - not sure if I'm a fan of this yet. The language is well organized. I should learn more about u8, u16, etc, data types - I haven't worked with them before and if I did, I wasn't aware that I was. `cargo check` is neat. You know that argument in C++ where one should use `std::` rather than `using namespace std`? I wonder if that argument is also applicable to Rust. Enough rambling, are you using the learning resources mentioned on the Rust Documentation or some other resources? Any you'd recommend?
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.
Even if you don't end up using Rust in the future, having a Rust background will give you a solid foundation for writing C and C++, since Rust strongly encourages the sort of structure and idioms that are generally considered best-practices in those languages. Being inclined to structure things hierarchically when possible will also subtly help any programs you write in dynamic languages from becoming too tangled, as will the general attitude of separating data from behavior.
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. :)
The point above is correct in very broad strokes, but they’re still different languages. It gives you the kind of background understanding for what problems the languages are trying to tackle, and many of the idioms are related, but there’s still big differences.
Idris is a gateway drug. Once you are hooked it's hard to get rid off. I tried it for a week and realized I won't probably like anything else after this. I will pick Idris when I am prepared to kick the bucket.
It's a solid comparison, but I find it interesting that the author refers to Rust/Java/C++ as coming from the “IT World”. I guess the bit about human subcultures being fractal rings true here.
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.