Re: Some rather stupid questions about Rust and FreeBSD

From: DaLynX <d_at_l.ynx.fr>
Date: Thu, 12 Sep 2024 01:51:28 UTC
Le 12 septembre 2024 00:11:03 UTC, Aryeh Friedman <aryeh.friedman@gmail.com> a écrit :
>On Wed, Sep 11, 2024 at 7:02 PM Alan Somers <asomers@freebsd.org> wrote:
>>
>> in Rust
>> =======
>> let mut arr = vec![170, 45, 75, 90, 802, 24, 2, 66];
>> arr.sort();
>
>The fact the data structure even worries about behaviour instead of
>being passable to objects is asking for it (this is from my software
>engineering hat). Also the fact there is no explicit size of the
>array defined since if it is static a Turing complete process can be
>implemented on it but if it is dynamic how do you keep from
>overflowing the storage allocated to it (aka buffer overflow).
>
>> * The size of the array
>
>Very good idea from the resource management POV
>
>> * The size of each element
>
>Again correct call for an OS level language.
>
>> * The name of the comparison function
>
>Separation of concerns *STANDARD* software engineering.
>
>>
>> Each of those is error-prone. Stuff like that is a common source of
>> bugs in C code. But Rust tracks it automatically.
>
>At the cost of coupling stuff far too tightly it appears.
>

Hi,

I am more of an IT security guy by trade and just do programming for fun but I have played with Rust. I think your worries are very legitimate but come from a lack of knowledge or understanding of the language.

- Size questions are not absent from the language. They are explicit. Even more than in C (I do not need to know the arch to know that an u32 is 32 bit and a u64 is 64.). They do not appear at the sort function level because it is automatically taken into account by the compiler through typing.

- The vector we are looking at here (which technically is automatically typed as a Vector<u32>, I believe) is a container class, pretty much like the STL's vector<T> in C++. It keeps track of its length (and capacity, which you can also work with if you need to be precise about that).

- You seem to worry that the sort function is implemented at the data structure level, like you would do by putting a method in a class, coupling too tightly to your taste behaviour with structure. This is not really the case. Rust works with traits: there is an Ord trait, for which you provide an implementation for the types you want to work with, then the sort function automatically applies to any type implementing that trait.

You seem to think the sort function is defined in the vector's class because you look at the "." like it accessed the member of a C struct. It is not. That's just syntaxic sugar. The sort function is implemented separately, agnostically, taking anything that implements the Ord trait as arguments. So that behaviour is totally separate from the data structure, and applies to a Vector of anything that implements an Ord trait (a comparison function).

(Actually you can work with a PartialOrd too if you don't have a total order, with some extra precautions.)

And of course you can just use vec.sort_by(f) if you want to provide a specific comparison function that is different from the one in the Ord trait for your data type. So if you prefer to keep the separation explicit that way, you can. It's just coding guidelines.

As I said, I think the points you raise are most pertinent and legitimate. But making your opinion of another language just based on brief examples sent to you by email will never be enough to let you construct a complete, accurate and thus fair opinion of it.

So to anyone who doesn't know rust I advise to take some time to look at it and play with it. That's how we all learn.

I hope that's constructive.

Kind regards,
DaLynX