[libre-riscv-dev] Why I like Rust

[Luke Kenneth Casson Leighton]

On Mon, Apr 22, 2019 at 8:51 PM Jacob Lifshay <programmerjake at gmail.com> wrote:

> I highly recommend watching https://youtu.be/jQOZX0xkrWA it explains a lot
> of why I think Rust is better than pretty much every other mainstream
> programming language I've used, including Python.

 appreciated.  i did a skim: the main takeaway is the zero-cost
abstractions, and things like the "give away and take". being able to
hand an object over to another object, and have the *compiler* check
that, that's really good.

 i've seen how insanely complex webkit became with its refcounting
system, for example.  the level of complexity to cover all possible
cases of pass-by-ref, pointer, pointer-casting, static
pointer-casting, dynamic-pointer-casting, it was... is.... utterly
mad.

don't get me wrong: it worked, extremely effectively: it was just a
bastard to understand, and when i had to interface to gobject (which
involved *manual* down-casting to a c void* - i had to do
triple-casting: first to the base object at the c++ level, then a
dynamic void* cast and finally a *static* void* cast (!!!) - and
*manual* decrementing and incrementing the refcounters half way in
between), the complaints that i received at even "attempting to bypass
the safety" were just... deeply unpleasant to deal with.

particularly given that there literally was no other way to interface
a non-ref-counting system (gobject, written in c) to webkit's
extremely paranoid and comprehensive multiple-inheritance-capable
ref-counting system (written in c++)


i refused to use anything other than c and c++, initially, back in
1999.  it took several months for martin pool to convince me to try
python.  that was 20 years ago, and it's taken a *long* time to learn
the full extent of the libraries, mindset, and the "tricks", such as
that there's a "join" function on strings, and that "dir(something)"
can be typed at the interpreter to show the members of the object, and
"print something.__doc__" shows its docstring, and dozens more.

 without the full knowledge of these tricks - without the knowledge of
what's in the libraries and what's in the basic types, and how the
prioritisation of the casting system works (which goes through int,
float *and* complex numbers), and the "ethos" behind python - there is
the danger of feeling completely "unsafe" at its "freedom".

 the key insight i think is that far from trying to *add*
type-checking as a "substitute for the fact that it isn't there",
python is based on the principle that you *just don't do it at all*.

 fundamentally, if you are used to type safety checking at compile
time, that's just absolutely mind-blowing, that the *entire language*
is based around the concept of "don't bother checking the types".

 (!!!!)

i'm overstating it massively (as there are clearly instances where not
checking the types is bad) however you get the general idea, which is
*don't clutter the code unnecessarily*.

part of the reason why i love python is from the fact that i learned c
and c++ both self-taught, and found both very awkward.  rust didn't
exist.  without such "safe" languages, i had to learn some strict
programming rules.

at one job, for automotive engine controllers (very low-resource
microcontrollers), malloc, free, recursion and local parameters -
basically anything that could involve stack allocation and thus result
in an overflow that could cause the engine to seize up or even explode
- were prohibited.

just... outright prohibited.  code reviews involved a *FIVE man*
line-by-line code walkthrough.  five people!

so having that background, yes, i simply did not believe that it was
"safe" to go to such a language, one that had zero type-checking of
any kind.

the thing is: that lack resulted in some very good programming
practices, particularly code layout, as well as allowing much *much*
faster development.  no type-checking.... no need to even write a
function yet, wtf??? moo???

and i witnessed these practices being developed and deployed,
throughout the community, and picked up on them, particularly from
some extremely hard lessons where they were ignored or just weren't
known about.

primarily, then - and i don't want you to think that this is "cutting
corners" - python is about *not* doing things that aren't absolutely
necessary, and, as it says on that Liskov Substitution Principle page,
it's *semantic* rules *not* syntactical rules - development in python
is much quicker to develop in because you *write less code* and write
*more effective* code.

 it's a much higher bang-per-buck ratio, basically.

however if you try to continously add type-checking and type-safe
practices into python (because they're not there), the end result is
not just a massive drop in productivity, it results in code that is so
deeply unreadable, it's not only completely unmaintainable, it's
incredibly easy to then justify that of *course* it would be better to
use a strongly-typed modern programming language like rust, instead.

i have a feeling that you could really use the contrast, jacob, of
what it's like to use python at its best (over time as you've seen
i've outlined a few horror stories of python being abused, locking up
a 50-man team and making them terrified to make any code changes,
because the CTO was being an idiot, basically)

the contrast and the experience will not only stand you in good stead
and allow you in the future to spot the difference between a
well-written python project and a bad one, it will also give you a
deeper appreciation of type-safety in e.g. rust (and go), and allow
you to choose when to go with the rapid development of python or the
strong type-safety of e.g. rust.

l.