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

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

[Jacob Lifshay]

There's lots of good quotes about Rust:

https://stackoverflow.blog/2020/06/05/why-the-developers-who-use-rust-love-it-so-much/?cb=1

I particularly like this quote (italics translated to asterisks):

> daboross: “As a library author, the complex trait/generic system means I
can craft intricate, yet easy to use interfaces. These interfaces *cannot
be used incorrectly*, which means I don’t have to perform runtime checks,
and my users don’t have to even *think* about problem cases, because they
*can’t write them*.

I definitely agree, and the lack of good interfaces is one of my biggest
pain points with Python.

Jacob
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Luke Kenneth Casson Leighton]

On Wed, Jun 10, 2020 at 9:22 AM Jacob Lifshay <programmerjake@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.

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

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.

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

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Luke Kenneth Casson Leighton]

On Wed, Jun 10, 2020 at 1:06 PM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:

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

which has me thinking: is there any way that we could improve things
for python... however _without_ interfering with the code-compactness,
readability and speed of initial development?

one thing i noticed with python type-checking: i found it to be an
absolute nuisance - a hindrance far greater than its value.

the increased function definitions and type definitions frequently
require functions to be expanded from a single horizontal line into a
vertical multi-line definition, running the definition off the page.

the typechecking itself often means that using the Liskov Substitution
Principle is interfered with, because the initial declaration of the
types no longer fit the use to which the over-rides are put.

of course, that *is* the whole point of having the type-checking: to
ensure that the types of base classes and LSP *are* declared!

so i have no clue, here.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Hendrik Boom]

On Wed, Jun 10, 2020 at 01:44:46PM +0100, Luke Kenneth Casson Leighton wrote:
> On Wed, Jun 10, 2020 at 1:06 PM Luke Kenneth Casson Leighton
> <lkcl@lkcl.net> wrote:
> 
> > 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.
> 
> which has me thinking: is there any way that we could improve things
> for python... however _without_ interfering with the code-compactness,
> readability and speed of initial development?

There is definitely a trade-off between speed of initial development and speed of 
development.

-- hendrik

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Jacob Lifshay]

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

> On Wed, Jun 10, 2020 at 9:22 AM Jacob Lifshay <programmerjake@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
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Cole Poirier]

As someone who's only been programming for ~2-3 years, I actually find
rust much, much easier to use than python, because it's complier
assisted programming. Dramitically easier for someone like myself with
so little 'blank-page' programming experience to both get started and be
productive long term. And oh the types, so beautiful, yet so much more
productive and easy for me than 'typeless' python, as jacob mentioned above.

Cole

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Hendrik Boom]

On Wed, Jun 10, 2020 at 02:28:31PM -0700, Cole Poirier wrote:
> As someone who's only been programming for ~2-3 years, I actually find
> rust much, much easier to use than python, because it's complier
> assisted programming. Dramitically easier for someone like myself with
> so little 'blank-page' programming experience to both get started and be
> productive long term. And oh the types, so beautiful, yet so much more
> productive and easy for me than 'typeless' python, as jacob mentioned above.

I learned to appreciate static typing when I was writing complex data 
structures in PL/1 in the 1960's -- it didn't have it.  A pointer was a 
pointer, and it would just believe it pointed to whatever you said it 
pointed to when you used it.

A learned to *love* statis typing when  got to use Algol 68 a few years 
later, in the mid 1070's..

It was a long time before I had it available to me again.  
I found it again in Modula 3.

-- hendrik

> 
> Cole
> 
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev@lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev