
Rust and SPARK: Software Reliability for Everyone (2017) - oherrala
https://www.electronicdesign.com/industrial/rust-and-spark-software-reliability-everyone
======
kibwen
_> 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...](https://www.ralfj.de/blog/2018/11/16/stacked-borrows-
implementation.html)

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.

~~~
cpeterso
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.

[https://rain-1.github.io/golang-aslr.html](https://rain-1.github.io/golang-
aslr.html)

[https://insanitybit.github.io/2016/12/28/golang-and-
rustlang...](https://insanitybit.github.io/2016/12/28/golang-and-rustlang-
memory-safety)

~~~
jimktrains2
Defense in depth.

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.

------
sidcool
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.

~~~
atoav
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.

~~~
danieldk
_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.

~~~
mitchty
I'll snag that book then, thanks for the pointer! I'm semi-useful right now
but every little bit helps.

Edit: neat, its on safari queue, i don't need to buy a thing (sorta.... ignore
that I pay for this yearly)

------
thramp
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.

------
steveklabnik
(Note this is from April of 2017)

------
Animats
SPARK, the language. Whatever happened to that?

~~~
inamberclad
Not much reason to run across it unless you're in the avionics and high
integrity world

