User avatar
clicky
Posts: 511
Joined: Thu Oct 25, 2012 7:34 am

Re: Anyone using Rust on a PI ?

Tue Jul 14, 2020 7:01 pm

Sorry to join in late - but it might help @jahboater with his original question:

I've picked up Rust 2 (or so) weeks ago - on Raspberry Pi.

I have (headless) program written in Python which was:
- reading gyro + accelerometer over i2c
- driving motors using GPIOs and PWM (pigpiod)
- sending 'telemetry' over TCP (fixed length records of words, ints, longs and many double floats - all in binary format)
- and sundry - it was 'controlled' over MQTT (start/stop)
- it utilities rest of my 'system' (called PyROS - LOL) to read 'storage' which keeps some config values + using same MQTT topics allowing for them to be changed at runtime (and automatically stored by another Python based 'service'
- and - I have written Python code with Pygame to receive and to display many of those telemetry things (gyro stuff, PID internals, etc) in some form of nice graphs.

That code, when running reading gyros/accel at 200Hz, along with pigpiod (which is quite heavy) took around 90% of CPU - hence my idea to try to rewrite it from Python to Rust.

First I have rewritten telemetry library which has TCP listening port which accepts connections and sends those fixed size records. That required me to learn how to do following in Rust:
- handle polymorphism (creating different 'classes' for singed byte, unsigned byte, signed word...)
- do overriding methods - so for passed argument to execute different 'pack' for those variants
- how to have methods that can accept var args (turned out to be macros in Rust) so my 'telemetry streams' can work based on definition not pre-written methods with fixed args)

After that I have gone to battling not so OO design - learning correct idioms in Rust for encapsulating gyros, accel, pid, motors, etc...
Implementing reading/writing to i2c was relatively easy similarly as setting gpio on or off... Problem arose when I decided not to use pigpiod (latency? CPU heavy?) and found dma-gpio in docs.rc. That crate has been 'yanked' (?!), but luckily docs.rs had saved source so I have manually downloaded all files and recreated it locally. But, then found out that crate was made for 32bit OS and my problem was that I was coding on Pi4 with 64bit OS (viewtopic.php?f=34&t=278333) while my target system is PiZeroW. So, next thing I had to learn is how to have two versions of the same package for two different sizes of usize type. Turned out that you can just add conditional compiling (but again - it did take almost another day until I found correct incantation for target arch, etc)...

And last was tinkering with MQTT, passing received values from one threads to another, etc...

Result? All works fine an it doesn't take more than 30% of CPU (less than that ~ 27%-ish). Even dma-gpio stuff works flawlessly (BTW I have no idea why original author has removed crate from docs.io/crates.io and deleted github repo) - it is fast and reliable translation of PiBit's ServoBlaster alike code. (copied so many times around)

What I found is that my understanding how compilers work (I've written my first when I was 18 - more than 30 years ago), how other languages work, and all my previous exposure to assembler, CPU architecture, etc - didn't help a lot. It helped less than I expected/hoped for. In order to do correct stuff in Rust I had to learn new ways of doing things and by 'new' I mean something completely different to manual malloc stuff in C and spoiled GC stuff in many other languages. Mostly it is about side-effects that one needs to pay much attention to.

And, that part plus really nice support for functional programming makes Rust the most schizophrenic:
- on one hand one can 'see' pointers in registers of CPU and when memory is on heap or stack
- and compiler that tracks all references anally to the point of it wanting you mark your structures copyable and cloneables (which I was avoiding as much as I could)
- so, it kind of, forces you to do nice, side-effectless functional coding as much as you can + provides loads of libraries for it

One of the things I really like, as it was my long standing day dream is associating new methods to existing 'objects' (read mostly primitives). So you can easily add new methods to i32 (integer) which will accept that integer (self) and do something with it... Zero abstraction works well in that case...

I definitively haven't regretted learning it and will try to add more code written in Rust to my robots.

User avatar
paddyg
Posts: 2602
Joined: Sat Jan 28, 2012 11:57 am
Location: UK

Re: Anyone using Rust on a PI ?

Sun Jul 26, 2020 9:41 am

To join in even later (and more tangentially). Following up on @Heater's question "how to pass mutable slices to functions in python" you can do this with numpy (sometimes unwittingly!) i.e.

Code: Select all

def mess_up_slice(s) :
    s[0] = 0

v  = numpy.arange(0, 10)
print(v)
mess_up_slice(v[2:3])
print(v)
''' produces
[0 1 2 3 4 5 6 7 8 9]
[0 1 0 3 4 5 6 7 8 9]
'''
To approximate a read only view

Code: Select all

fn dont_mess_up_slice(s: &[i32]) {
You can set v.flags.writeable = False but it doesn't really enforce this. i.e.

Code: Select all

v  = numpy.arange(0, 10)
b = v[:]
v.flags.writeable = False
mess_up_slice(b[2:3])
also https://groups.google.com/forum/?hl=en-GB&fromgroups=#!forum/pi3d

Heater
Posts: 17118
Joined: Tue Jul 17, 2012 3:02 pm

Re: Anyone using Rust on a PI ?

Sun Jul 26, 2020 10:28 am

Ha, thanks for that.

Now that you mention numpy I guess I have done this when toying around with some OpenCV a while back. Not a standard part of the language then.

It's the "sometimes unwittingly" which bothers me. And is part of the motivation to use Rust and it's memory usage correctness checking.
Memory in C++ is a leaky abstraction .

User avatar
jahboater
Posts: 6511
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: Anyone using Rust on a PI ?

Sun Jul 26, 2020 6:14 pm

Heater wrote:
Sun Jul 26, 2020 10:28 am
It's the "sometimes unwittingly" which bothers me.
Yes. I thought it was dodgy too (see earlier post), and was pleased that its not directly possibly in Python like it is in Rust.
Numpy is a third party math library.

Languages like C are "call by value" - all function arguments are a copy.
Pi4 8GB and Pi4 4GB running Raspberry Pi OS 64-bit

Heater
Posts: 17118
Joined: Tue Jul 17, 2012 3:02 pm

Re: Anyone using Rust on a PI ?

Sun Jul 26, 2020 7:01 pm

jahboater wrote:
Sun Jul 26, 2020 6:14 pm
... and was pleased that its not directly possibly in Python like it is in Rust.
I'm not sure what you are talking about there. Are we talking about the same thing?

Rust will not let you pass anything anywhere that can mutate it without explicitly allowing for it.
jahboater wrote:
Sun Jul 26, 2020 6:14 pm
Languages like C are "call by value" - all function arguments are a copy.
Hmm... kinda, sorta.

Certainly in C all arguments are passed by value, or "copy" as you say.

Typically those values are actually pointers to the actual thing of value. At which point one does not know who owns it, who can mutate it, etc.

For example, what does this do:

Code: Select all

#include "stdio.h"

void messupvalue(char* s)
{
    s[2] = 'x';
}

int main (int argc, char* argv[])
{
    char* value = "My valuable thing";

    messupvalue(value);

    printf("%s\n", value);
}
Memory in C++ is a leaky abstraction .

User avatar
jahboater
Posts: 6511
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: Anyone using Rust on a PI ?

Sun Jul 26, 2020 7:33 pm

Heater wrote:
Sun Jul 26, 2020 7:01 pm
At which point one does not know who owns it, who can mutate it, etc.

void messupvalue(char* s)
Instead you say:

Code: Select all

void messupvalue( const char *s )
which declares that "messupvalue" is a misnomer and the function cannot in fact alter anything that "s" points to :)

You may also declare it as "restrict" to say that the thing "s" points to does not overlap with anything else (aliasing) which allows all sorts of optimizations.
Pi4 8GB and Pi4 4GB running Raspberry Pi OS 64-bit

Heater
Posts: 17118
Joined: Tue Jul 17, 2012 3:02 pm

Re: Anyone using Rust on a PI ?

Mon Jul 27, 2020 7:07 am

jahboater wrote:
Sun Jul 26, 2020 7:33 pm
...which declares that "messupvalue" is a misnomer and the function cannot in fact alter anything that "s" points to :)
Almost.

'const' is a wonderful thing in C/C++ but it does not stop one from doing anything:

Code: Select all

$ cat junk.c
#include "stdio.h"

void messupvalue(const char* s)
{
    ((char*)s)[2] = '*';
}

int main (int argc, char* argv[])
{
    char value[] = "My valuable thing";

    messupvalue(value);

    printf("%s\n", value);
}
$ gcc -Wall -O3 -o junk junk.c
$ ./junk
My*valuable thing
"Don't do that!" I hear you say. Sure but I bet you have seen things like that done many times. In Rust you just cannot.

Note: Also in the original code above 'messupvalue' was passed a pointer to a literal string, which is actually immutable, the compiler did not care, hence the segfault at run time. Blech!
You may also declare it as "restrict" to say that the thing "s" points to does not overlap with anything else (aliasing) which allows all sorts of optimizations.
'restrict' is not about safety of memory use, it is a hint to the compiler that may allow it to optimize better. 'restrict' does nothing to stop one passing two, or more, pointers to the same data. It does not prevent anti-aliasing at all.

In fact 'restrict' only makes doing that undefined behavior. Which arguably puts one in a worse situation from a safe use of memory point of view. Which is why coding guide lines suggest not using 'restrict':
https://wiki.sei.cmu.edu/confluence/dis ... d+pointers
Memory in C++ is a leaky abstraction .

User avatar
jahboater
Posts: 6511
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: Anyone using Rust on a PI ?

Mon Jul 27, 2020 7:39 am

Heater wrote:
Mon Jul 27, 2020 7:07 am
'const' is a wonderful thing in C/C++ but it does not stop one from doing anything:
I get a warning ...

Code: Select all

junk.c: In function 'messupvalue':
junk.c:5:3: warning: cast discards 'const' qualifier from pointer target type 
I personally never ignore warnings like that, but I guess some people might. Modern compilers put as much as possible in the read-only "text" or the "rodata" sections, so IMHO it is madness to ignore such a warning (-Wcast-qual).
Also the cast documents in the code that something bad is happening!
In principle, its just like "unsafe" or whatever in Rust.
Heater wrote:
Mon Jul 27, 2020 7:07 am
Note: Also in the original code above 'messupvalue' was passed a pointer to a literal string, which is actually immutable, the compiler did not care, hence the segfault at run time. Blech!

Code: Select all

char value[] = "My valuable thing";
No, this is a mutable string. value points to an area on the stack which is initialized at run time to "My valuable thing".
If instead you gave:

Code: Select all

const char value[] = "My valuable thing";
and pass it to

Code: Select all

messupvalue( char* s )
Then you get this:

Code: Select all

junk.c:3:25: note: expected 'char *' but argument is of type 'const char *'
Also:

Code: Select all

messupvalue("My valuable thing");
predictably fails with:

Code: Select all

junk.c:10:14: warning: passing argument 1 of 'messupvalue' discards 'const' qualifier from pointer target type
   10 |  messupvalue("My valuable thing");
      |              ^~~~~~~~~~~~~~~~~~~
junk.c:3:25: note: expected 'char *' but argument is of type 'const char *'
    3 | void messupvalue( char* s)
      |                   ~~~~~~^
GCC 10.2 with some extra warning flags.
Pi4 8GB and Pi4 4GB running Raspberry Pi OS 64-bit

Heater
Posts: 17118
Joined: Tue Jul 17, 2012 3:02 pm

Re: Anyone using Rust on a PI ?

Mon Jul 27, 2020 9:04 am

I agree, I always strive to eliminate all warnings. Even if they are "false positives" as it were. Keeping ones builds free of hundreds of warnings means it more likely one will spot that important warning when it turns up.

I cannot agree that the cast documents anything in the code. If someone sneaks that into a large code base it's going to be hard to find when it's segfault hunting time. It may also be far away from the code that actually causes the problem later.

In principle such casts in C are nothing like "unsafe" in Rust.

"unsafe" in Rust allows one to:

* Dereference a raw pointer
* Call an unsafe function or method
* Access or modify a mutable static variable
* Implement an unsafe trait
* Access fields of unions

As the documentation notes:
It’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks:
And of course use of the "unsafe" keyword is much easier to find in a large code base. It restricts use of unsafe code to very small confined areas that are more easily verified manually.

In my original code snippet above the string was not declared as an array on the stack. It was declared as a pointer to a string literal. Which is immutable, the compiler did not care about that, hence the segfault.

In case anyone is wondering, I don't mean to bash on C. I love C. I can't imagine life without C. C is what it is, small, simple, fast and a pretty good representation of what our hardware actually does. But we should get our language comparisons straight.
Memory in C++ is a leaky abstraction .

User avatar
jahboater
Posts: 6511
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: Anyone using Rust on a PI ?

Mon Jul 27, 2020 9:26 am

Heater wrote:
Mon Jul 27, 2020 9:04 am
I cannot agree that the cast documents anything in the code. If someone sneaks that into a large code base it's going to be hard to find when it's segfault hunting time. It may also be far away from the code that actually causes the problem later.

In principle such casts in C are nothing like "unsafe" in Rust.
OK. I did mean very very generally. I think of both as notes to the compiler and to the human reader that something risky and outside of the language ethos is going on.

I think people differ in their attitude to casts,
For me, a cast is an admission of failure. It means I as a programmer, have been unable to get the data types right, and have used a cast to shut the compiler up, or at least say in the code that I know its wrong. That's why I always use -Wcast-qual because the sort of casts it warns about are very very dangerous. Other things like:

Code: Select all

bytes > 0 && write( fd, ptr, (size_t)bytes ) != bytes
are safe, and, as far as I can see, unavoidable.

I agree "unsafe" is more alarming and covers a whole section of code which is probably better.
Heater wrote:
Mon Jul 27, 2020 9:04 am
In case anyone is wondering, I don't mean to bash on C. I love C. I can't imagine life without C. C is what it is, small, simple, fast and a pretty good representation of what our hardware actually does. But we should get our language comparisons straight.
I saw this recently:
Jens Gustedt: The most important strong points of C are efficiency, portability and
stability. Whenever those are the main concerns in software development, C
should be considered as a primary choice.

Efficiency: Here, efficiency can mean very different things: energy and memory
efficiency (for small or portable devices, satellites), runtime efficiency (for
mid or large-scale compute intensive calculations), or speed (for scientific
visualization, games or network communication). C's efficiency in these fields
is mostly unmatched, other programming languages tend to introduce a lot of
memory indirection, dynamic behaviour, and bloat that kills efficiency in the
egg.

Portability: C's abstract state machine is meant to be portable to about any
computing device. This concept has payed off very well: one of the first
software components that is usually developed for new CPUs (or for added
features to an existing specifications) is a C compiler. Thereby, code written
in C, in particular OSes and other system software, is rapidly ported. New
architectures can be bootstrapped at low cost. And a huge amount of software
projects profit from this; Linux distributions are collections of thousands of
software packages that are ported mostly easily to new architectures and that
keep pace with the developments of the existing mainstream platforms.

Stability: The C committee puts particular effort into guaranteeing the
stability of the code base of our users. Deprecations are rare and marginal.
Correct C code that you write now will still compile and run with very little
effort 20 years from now; code that has been written in the 80s or 90s still
kicks today. Also C has a limited set of features that should be mastered at
graduate level in any good engineering school. So maintenance can be ensured
over years and even decades. Legacy can have a very different taste with C;
good C code can be a real asset and must not be a burden.
He doesn't mention safety which relies on the programmer heeding warnings!
Pi4 8GB and Pi4 4GB running Raspberry Pi OS 64-bit

Heater
Posts: 17118
Joined: Tue Jul 17, 2012 3:02 pm

Re: Anyone using Rust on a PI ?

Mon Jul 27, 2020 11:18 am

It's a funny thing about that (size_t)bytes ) thing.

In Rust one can only index arrays with a "usize". Basically a size_t kind of type that is guaranteed to be able to address all of memory as bytes.

Of course often the thing one is using to index an array may actually be a value in it's own right used for other things beside array indexing. For example if one wants to do some unit conversion using a look up table. So one ends up writing "myArray[someValue as usize]". There seems to be some debate as to whether that is the vest way to do it though.

Jens Gustedt is spot on there.
Memory in C++ is a leaky abstraction .

User avatar
jahboater
Posts: 6511
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: Anyone using Rust on a PI ?

Mon Jul 27, 2020 12:08 pm

Heater wrote:
Mon Jul 27, 2020 11:18 am
In Rust one can only index arrays with a "usize". Basically a size_t kind of type that is guaranteed to be able to address all of memory as bytes.

Of course often the thing one is using to index an array may actually be a value in it's own right used for other things beside array indexing. For example if one wants to do some unit conversion using a look up table. So one ends up writing "myArray[someValue as usize]". There seems to be some debate as to whether that is the best way to do it though.
I guess usize is needed because most platforms need a full size register for indexing.
Is the debate because some people think the conversion to usize should be implicit? Leading to more natural readable code.
But Rust, wanting to be safe, doesn't randomly alter the type of users variables as the values could change.

The C compiler only warns when a char is used as an array index, because char may be either signed or unsigned depending on the implementation - leading to possible disaster upon sign extension.

Sounds like negative index's might be difficult.
Pi4 8GB and Pi4 4GB running Raspberry Pi OS 64-bit

Heater
Posts: 17118
Joined: Tue Jul 17, 2012 3:02 pm

Re: Anyone using Rust on a PI ?

Mon Jul 27, 2020 12:51 pm

jahboater wrote:
Mon Jul 27, 2020 12:08 pm
Is the debate because some people think the conversion to usize should be implicit?
Oh no, much worse. It's about almost anything but that.

In fact months back I started a whole thread about it on the Rust user forum: '“as” considered harmful?' : https://users.rust-lang.org/t/as-consid ... mful/35338. The discussion ran on to quite a length!

A couple of interesting responses in there:
Rust being explicit about integer types, but silently truncating in "as" is a source of bugs and vulnerabilities. ...I think the current situation is awful and dangerous (not "unsafe" per Rust's definition, but unexpected truncation caused by as can cause dangerous bugs).
Instead of "as" use "myArray[usize::from(i)]"
Others question why my type is not correct, usize, in the first place.

Others point out that in Rust a lot of such indexing can be done with iterators rather than C style loops and indices. Which has the bonus of not requiring run-time bounds checks, allowing the optimizer to use vector instructions, and allows for trivial parallelization when operating on large arrays.

What with iterators and array slices it turns out the need for "as usize" and such all but completely disappeared from the code I was writing that caused me to ask the question.
Memory in C++ is a leaky abstraction .

User avatar
jahboater
Posts: 6511
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: Anyone using Rust on a PI ?

Mon Jul 27, 2020 2:06 pm

Wow that discussion did go on and on ....

I bet Mr Kernighan and Mr Ritchie had similar discussions in the early days of C ...

As far as I can recall, size_t came into existence so that strncpy(), read() and write() and many others could have a portable size argument. That's why size_t and probably usize have "size" in their name.
Later ssize_t was invented so that functions could return a length and also -1 on error.

All interesting stuff.
Pi4 8GB and Pi4 4GB running Raspberry Pi OS 64-bit

Heater
Posts: 17118
Joined: Tue Jul 17, 2012 3:02 pm

Re: Anyone using Rust on a PI ?

Mon Jul 27, 2020 2:40 pm

I can understand the motivation for size_t and usize having widths that depend on the machine architecture.

To my mind usize sticks out like a sore thumb in Rust for me because all the other integer and float types have a strictly defined sizes and ranges no matter what platform (that is size as in number of bits they occupy, not size of an array or whatever they may be used with).

Seems to me that this is a low level hardware dependency in a high level language that does not exist anywhere else in the language. Who would care about that in C? With it's platform dependent integer widths and the like, that is the whole point of C.

I sometimes think the problem is that the types we use for arrays are not specified fully. To define an array we need: An address for it to live at, the size/type of it's elements, and it's length/number of elements. Clearly whatever we use to index it should be an integer, signed or otherwise (who says an array can't start at element -1000?).

What is missing is the type of the integer we use as an index, which rarely needs to be as big as a usize.

An array would then be defined by, it's name, it's element type, the number of elements, and the type of the index.

I'm kind of guessing that being built on LLVM has a lot to do with this usize thing.

At the end of the day it's not a big deal.
Memory in C++ is a leaky abstraction .

User avatar
jahboater
Posts: 6511
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: Anyone using Rust on a PI ?

Mon Jul 27, 2020 4:29 pm

Heater wrote:
Mon Jul 27, 2020 2:40 pm
To my mind usize sticks out like a sore thumb in Rust for me because all the other integer and float types have a strictly defined sizes and ranges no matter what platform (that is size as in number of bits they occupy, not size of an array or whatever they may be used with).
See also the types in D where things like "long" are defined to be exactly 8 bytes and so on (the normal C type names have fixed, power of two, sizes in D).
Heater wrote:
Mon Jul 27, 2020 2:40 pm
Seems to me that this is a low level hardware dependency in a high level language that does not exist anywhere else in the language. Who would care about that in C? With it's platform dependent integer widths and the like, that is the whole point of C.
Maybe Rust should decide what type of language it really wants to be. If it wants to be a fast portable systems programming language, (even with extra safe features) it has to deal intimately with the hardware, and that means certain types will vary. Otherwise on a 16-bit machine, a 64-bit usize would be a horrific waste, but on a 64-bit machine a 16-bit usize would not work.
If Rust doesn't have pointers then ptrdiff_t is not needed (and negative array index's cannot created by the programmer like they can in C). Or maybe Rust wants to be another Ada.
Heater wrote:
Mon Jul 27, 2020 2:40 pm
What is missing is the type of the integer we use as an index, which rarely needs to be as big as a usize.
But it could be, especially with virtual memory. So the chosen integer type has to be large enough and usize is that type.
Whatever integer type you choose, the compiler will convert it to a usize anyway, it has to because index registers are the same size as usize.
Heater wrote:
Mon Jul 27, 2020 2:40 pm
An array would then be defined by, it's name, it's element type, the number of elements, and the type of the index.
Or the number of elements and the "notional index" of the first element. I'm not sure about the "type" of the index, it sounds like you would have different types for small arrays than for large arrays, maybe like Pascal.

If "usize" was instead called "index" or something similar would you be liking it?
Pi4 8GB and Pi4 4GB running Raspberry Pi OS 64-bit

plugwash
Forum Moderator
Forum Moderator
Posts: 3723
Joined: Wed Dec 28, 2011 11:45 pm

Re: Anyone using Rust on a PI ?

Mon Jul 27, 2020 4:57 pm

Heater wrote:
Mon Jul 27, 2020 2:40 pm
What is missing is the type of the integer we use as an index, which rarely needs to be as big as a usize.
That comes back to a program design question.

Should your software artificially limit the size of the data it will work with? or should it support working with data as big as the platform it runs on supports? in the latter case you want an index type that can index any array that the platform can create.
jahboater wrote:
Mon Jul 27, 2020 4:29 pm
Maybe Rust should decide what type of language it really wants to be.
I have always understood rust's goal to be creation of a superior replacement for C++. One of the strengths of C++ is that it can cover a wide range of programing levels. Otoh I don't think the creators of rust have much interest in esoteric systems (non-ascii systems, systems with byte sizes other than 8 bits etc).

The short, int and long types in C/C++ are frankly a mess. They are not fixed size (either in bit terms or byte terms) and nor do they reliably represent any particular characteristic of the underlying platform. They add little useful value, other than as a compatibility layer for interfacing with C/C++ code.

size_t (and it's rust equivilent usize) on the other hand serves an important purpose, an index type that can index the largest possible array.
jahboater wrote:
Mon Jul 27, 2020 4:29 pm
If Rust doesn't have pointers
rust does have pointers. They can only be de-referenced in "unsafe" blocks though.
jahboater wrote:
Mon Jul 27, 2020 4:29 pm
then ptrdiff_t is not needed
It doesn't seem to have a specific "ptrdiff" type but it does have ssize which is basically the same thing on sane architectures.
jahboater wrote:
Mon Jul 27, 2020 4:29 pm
Or maybe Rust wants to be another Ada.
One definitely sees some similarities in the goals.

Heater
Posts: 17118
Joined: Tue Jul 17, 2012 3:02 pm

Re: Anyone using Rust on a PI ?

Mon Jul 27, 2020 5:30 pm

jahboater wrote:
Mon Jul 27, 2020 4:29 pm
Maybe Rust should decide what type of language it really wants to be.
I think the Rust devs and community decided what they want the language to be many years ago.

One aspect of that is Rust as a systems programming language. As much a C is. They have been tenacious about that, to the extent of experimenting with and discarding features that did not support that goal. A big example of that being they way they ripped out an implementation of light weight, "green", threads before version 1.0 because they required complex run-time support, which did not fit well with the systems programming goal.

There is also a Rust "parity with C" working group tasked to cleanup the last odds and ends of smooth interoperability with C and hardware.
jahboater wrote:
Mon Jul 27, 2020 4:29 pm
If it wants to be a fast portable systems programming language, (even with extra safe features) it has to deal intimately with the hardware, and that means certain types will vary. Otherwise on a 16-bit machine, a 64-bit usize would be a horrific waste, but on a 64-bit machine a 16-bit usize would not work.
I agree. I was not suggesting otherwise.

It's just that I don't see why in a high level language I can't define an array that is indexed by the type of my choosing. After all, abstractly array indices are integers.

But as I said, at the end of the day it's not a big deal, and even less of an issue when using Rust language features as opposed to trying to write C in Rust as I did when I started out.

jahboater wrote:
Mon Jul 27, 2020 4:29 pm
If Rust doesn't have pointers then ptrdiff_t is not needed (and negative array index's cannot created by the programmer like they can in C).
Of course Rust does have raw pointers. Though you are going to have to use "unsafe" to make use of them.

Rust also has a bunch of "smart" pointers for use in different circumstances, which one generally uses in regular safe application code. Rather like the smart pointers of C++.
jahboater wrote:
Mon Jul 27, 2020 4:29 pm
Or maybe Rust wants to be another Ada.
Funny you should say that. Last I heard Ada had been inspired by Rust as was looking into adopting some of it's features. Notably the borrow checker/anti-aliasing rules.
jahboater wrote:
Mon Jul 27, 2020 4:29 pm
If "usize" was instead called "index" or something similar would you be liking it?
No. That does not do what I was suggesting. My suggestion was that I should be able to define my array to use whatever integer type I like.

As I said, no matter, it all turns out not to be a big deal in the end.
Memory in C++ is a leaky abstraction .

ejolson
Posts: 6328
Joined: Tue Mar 18, 2014 11:47 am

Re: Anyone using Rust on a PI ?

Mon Jul 27, 2020 5:30 pm

Heater wrote:
Mon Jul 27, 2020 2:40 pm
I sometimes think the problem is that the types we use for arrays are not specified fully. To define an array we need: An address for it to live at, the size/type of it's elements, and it's length/number of elements. Clearly whatever we use to index it should be an integer, signed or otherwise (who says an array can't start at element -1000?).
For an array to be specified fully maybe one also needs a stride (the space between elements) and the colours red, green, yellow and blue. In a way, the point is that memory is not an abstraction at all but rather something physical that can be found inside the computer.

In my opinion, independent of language, it is extremely important for the engineer writing the code to believe it is possible to make something beautiful.

How the individual esthetic aspects of different languages appeal differently to different programmers is documented in the language wars that go on despite the end of Usenet. In the present case, depending on who is writing the code, the data ownership model in Rust could serve as an artistic constraint that leads to a masterpiece or an irritation that leads to a habit of finishing when it works rather than when it's done. It's not the hammer or the shovel which makes for a good job but the attitude.

On the other hand, given the quality of most of the Python code I've seen, I suspect many people leave their cubicles early because the mandatory social distancing rules in effect at the pub down the street are less uncomfortable than mandatory whitespace rules.

It's impossible to legislate rules that lead to the same levels of safety that come from knowledge, buy-in and common sense. For the same reason half the people in the world wear quarantine masks like a chin brace, forcing a programmer to use a language they don't believe in could lead to buggy programs susceptible to all kinds of viruses. At the same time, my suspicion is a much higher percentage of Rust coders are using that language by their own choice, take pride in their work and as a result create programs with fewer bugs.

Heater
Posts: 17118
Joined: Tue Jul 17, 2012 3:02 pm

Re: Anyone using Rust on a PI ?

Mon Jul 27, 2020 5:41 pm

plugwash wrote:
Mon Jul 27, 2020 4:57 pm
I have always understood rust's goal to be creation of a superior replacement for C++.
That is not my impression.

For a long time Rust was just a hobby project of Graydon Hoare. Later adopted as a Mozilla research project with the specific aim of being able to implement big chunks of Firefox using threads spread over many cores. Rust has changed significantly since Graydon's time to support systems programming better. It's analogous to C which was developed with the specific goal of enabling Unix to be rewritten in a portable language.
plugwash wrote:
Mon Jul 27, 2020 4:57 pm
Otoh I don't think the creators of rust have much interest in esoteric systems (non-ascii systems, systems with byte sizes other than 8 bits etc).
Perhaps true. I don't see that as a bad thing. Is anyone ever going to make a machine with odd sized words and characters again?

Rust does not want to be Ada. Rust is inspired by many decades of language design research and compiler research that have passed since Ada was created. As I said, Ada now want to borrow ideas from Rust.

Which is all well and good I think.

When will C++ adopt the borrow checker?
Memory in C++ is a leaky abstraction .

Heater
Posts: 17118
Joined: Tue Jul 17, 2012 3:02 pm

Re: Anyone using Rust on a PI ?

Mon Jul 27, 2020 6:04 pm

Speaking of Rust deciding what it want's to be I think this quote from it's creator Graydon Hoare when talking about our software universe says a lot about that:
Software-wise I really wish we'd done almost everything differently. The focus has been on eyeballs and engagement, not like "does it work" or "can it resist attack by a bad actor". Almost no modern software works well or is safe in any serious sense. It's always on fire. A sinking ship with everyone frantically bailing. Swiss cheese. Pick your metaphor. So my dream setup would involve "software that has any sort of reliability". Which probably requires rewinding time to before the personal computing era and enacting liability legislation or something.
https://usesthis.com/interviews/graydon.hoare/
Memory in C++ is a leaky abstraction .

ejolson
Posts: 6328
Joined: Tue Mar 18, 2014 11:47 am

Re: Anyone using Rust on a PI ?

Mon Jul 27, 2020 10:38 pm

Heater wrote:
Mon Jul 27, 2020 5:41 pm
plugwash wrote:
Mon Jul 27, 2020 4:57 pm
Otoh I don't think the creators of rust have much interest in esoteric systems (non-ascii systems, systems with byte sizes other than 8 bits etc).
Perhaps true. I don't see that as a bad thing. Is anyone ever going to make a machine with odd sized words and characters again?
What if 9-bit type-III unums turn out to speed machine learning by 78 percent over the latest float-16 craziness?

In my opinion, any reasonable systems programming language should be able to represent the primitive data types available in hardware before people go trying to construct more complicated abstractions based on them.

Unfortunately, every time I have tried to do something with Rust, either
  • The installed compiler is the wrong version and the project fails to build.
    • The installed compiler is the right version and automatically downloads multiple crates full of subroutines and builds those instead.
    If along with the crates one were to add in liability legislation, would that lead to the same effectiveness and efficiency as the present healthcare system when dealing with a computer virus? For some reason I don't understand how any of this could possibly improve security.

    Though Fido gave this my post a paws down for being merely a rant, it would appear Rust works well on the Pi.

    Heater
    Posts: 17118
    Joined: Tue Jul 17, 2012 3:02 pm

    Re: Anyone using Rust on a PI ?

    Tue Jul 28, 2020 10:04 pm

    ejolson wrote:
    Mon Jul 27, 2020 10:38 pm
    For some reason I don't understand how any of this could possibly improve security.
    That is a good question.

    Firstly though it should be pointed out that "improving security" has never been part of Rust's "mission statement". In the same way it is not part of the mission of C or C++ or most other languages. Memory safety is a key part of Rust and of course the fact that that helps greatly with avoiding security issues is a huge bonus, as Microsoft and others have written about: https://msrc-blog.microsoft.com/2019/07 ... cure-code/

    But what about all those package ('crate') dependencies pulled off of Rusts Crates repository? Who knows what is in there?

    For sure people worry about that and do something about it. There is the "Rust Secure Code Working Group" tracking security issues in Rust crates: https://rustsec.org/. There are others busying themselves auditing code. There are of course all the Rust users who now have a central place to report suspect packages to.

    The fact that all these dependencies are provided as source, which is compiled when you add them to your project, and the memory safety rules of Rust make it somewhat harder for a rogue to sneak something shady in.

    At the end of the day it's the same problem as we have with C/C++. Typically there when one builds a non-trivial program it requires pulling in all kind of dependencies from apt repositories, libblabal-dev and so on. Or, worse still in C/C++ people end up snagging code from all kind of random web sites.

    At the other end of the day if you want to be sure there is no rogue code in your application you have to write it all yourself or audit what you are depending on from others.
    Memory in C++ is a leaky abstraction .

    User avatar
    jahboater
    Posts: 6511
    Joined: Wed Feb 04, 2015 6:38 pm
    Location: Wonderful West Dorset

    Re: Anyone using Rust on a PI ?

    Sat Aug 08, 2020 8:18 am

    Heater,

    Earlier you posted

    Code: Select all

    void messupvalue(const char* s)
    {
        ((char*)s)[2] = '*';
    }
    pointing out that the cast discards the const qualifier. Compiler options (-Wcast-qual -Werror) are required to fail compilations if it occurs.

    For your amusement, there is another way - function attributes.
    You may specify for each pointer argument if it is read-only, write-only, read-write, or none.
    These are stronger than the "const" qualifier and I believe cannot be cast away.
    While these are currently compiler extensions (GCC and the major compilers that copy it), I suspect they will be available in C2x using the [[xxx]] attribute syntax. Certainly they are considered portable enough now that the C library functions are being annotated with them.
    Pi4 8GB and Pi4 4GB running Raspberry Pi OS 64-bit

    Heater
    Posts: 17118
    Joined: Tue Jul 17, 2012 3:02 pm

    Re: Anyone using Rust on a PI ?

    Sat Aug 08, 2020 12:13 pm

    ejolson wrote:
    Mon Jul 27, 2020 10:38 pm
    What if 9-bit type-III unums turn out to speed machine learning by 78 percent over the latest float-16 craziness?
    Good question.

    My guess would be that if that were to happen it would happen inside some NN accelerator hardware, perhaps some funky new Nvidea GPU. Data would be shunted between CPU and NN in huge blocks as it is now. In fact the CPU need not know what data format the NN is using, it's just shoving images or whatever in and out as usual.

    Surely that question applies to C as well?

    Presumably whatever weird ass number format that NN accelerator has the general purpose CPU will still be expected to run normal code with it's 8, 16, 32, 64 bit sized numbers. That uses up the current chars, ints, and floats of the C language itself. Looks like C would also have to be extended for such an extra data type.
    Memory in C++ is a leaky abstraction .

    Return to “Other programming languages”