[libre-riscv-dev] why developers love rust on stackoverflow blog

[Jacob Lifshay]

On Wed, Jun 10, 2020, 05:07 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> On Wed, Jun 10, 2020 at 9:22 AM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
> > I definitely agree, and the lack of good interfaces is one of my biggest
> > pain points with Python.
>
> yep.  except... in a large well-maintained collaborative and useful
> project, you need unit tests, regardless of what language the code is
> in.
>

agreed, however unit tests can't catch everything except in trivial cases
or maybe languages where they use typing to limit the number of possible
inputs to a testable level.

>
> and if that language is python, well-written and properly
> comprehensive unit tests will inherently find you any interface
> problems pretty much instantly - just not at compile-time, because
> there isn't one [except if you use cython].
>

it will potentially find interface problems, however, it definitely won't
find problems where someone is misusing an interface in ways that don't
cause the tests to visibly fail, which is much more likely with Python than
with Rust.

There is also the factor that in a large and complex codebase such as
libre-soc's that is often lacking in documenting the expected types
everywhere, you often have to look through several files before you can
figure out what interface that some variable in the code your writing
conforms to. That was certainly the case for me when trying to figure out
what fields are included and what they mean for self.i.ctx.op, since there
was so much indirection that pyls wasn't able to give very useful
information, it thought op was a Signal since it didn't realize opkls was
set. At least in Rust, you have to define which traits your types implement
(basically a codified version of what interfaces you're allowed to use in
whatever code is using that type, that even applies to type variables in
generic contexts), also the compiler knows which concrete types are used
everywhere, so you can easily look up the type's definition, even for
autogenerated code.

>
> and if they're _not_ found, that's indicative of a failure of the
> whole team - including the contributing userbase - to write (or
> contribute) sufficiently comprehensive unit tests.  *not* of the
> language itself.
>

there is a practical limit on how many unit tests there can be, at some
point, you just have to give up on testing all possible edge cases for any
non-trivial code. Having the compiler prove at compile time that some
conditions are met (yes, the type system is Turing complete) by all code
that calls your functions or uses your types definitely makes it easier to
know that your code will work.

>
> rust, i get it: there's a strong reliance on the compiler, and on the
> definition of types, in ways that have not been done in other
> langugages.  in my mind, the alarm bells there are to imagine that
> because the language provides that safety net, therefore
> "automatically unit tests are not necessary to write, because the
> compiler will catch everything for me".
>

the compiler will catch quite a lot, however there is still a strong focus
on unit tests -- the language is designed to make writing unit tests really
easy:
just decorate a test function with #[test] and it will be automatically
added to the list of tests that the build tools will run. Additionally, the
build tools will automatically compile and test all example code in the doc
comments, each code example can be set to run as a normal doc test, a test
that code shouldn't compile (the build tools will verify it produces a
compile error), or code that the compiler should ignore for some reason
(such as not being written in Rust). There are also several other supported
testing methods that aren't used as often. You can also use a little macro
magic to test example code in external markdown documentation using the
same doc test magic. I use that macro stuff in the algebraics library to
test the example code in the README.md file:
https://salsa.debian.org/Kazan-team/algebraics/-/blob/v0.2.0/src/lib.rs#L21

Jacob