Re: Some rather stupid questions about Rust and FreeBSD

On Wed, Sep 11, 2024 at 7:02 PM Alan Somers <asomers@freebsd.org> wrote:

> > 2. The code looks no better than portable assembly and if that is the
> > case why does it need to be in the kernel when there is already a
> > perfectly good portable assembly already there known as C?
>
> I don't know if you're being serious or trolling.  I ought to assume
> the former, but if you genuinely can't tell the difference between
> Rust and assembly source code then you obviously haven't looked at one
> or the other for more than a few seconds.

If I had wanted to troll instead of genuinely out of pure curosity I
could of compared all three languages to a language I am currently
writting to use in a forth come PhD thesis that is purefly function,
gate level (with abstractions allowed), has no explicit flow control
except for calling functions and  few other really oddball things.
But I am not going to say anything more about that and instead focus
on why I made the comment I did:

1. C when super optimized has about a 2 to 1 ratio between expressions
and emitted machine instructions but it self is semantically much
easier to deal with then assembly and the fact it is a high level
language means it in theory portable to any machine a compiler is
implemented on.

2. I consider assembly fairly high level actually compared to the
topic I am not trolling on (I am at the level of building UTM's from
gates)

> So I think you must be
> exaggerating, and you really mean "Rust looks no more or less readable
> than C".  For a good example of why Rust (and other modern languages)
> can be more readable than C, compare these examples, which sort an
> array:
>
> in C
> ====
> int compare(const void* a, const void* b) {
>      return (*(int*)a - *(int*)b);
> }

I completely agree pointers are evil and that's why I (like Rust it
appears) *ONLY* allow arrays and array references not direct pointers
into physical address space.   This way we still have the advantage of
being able to use base+offset addressing modes instead of having the
language processor/executor compute absolute addresses at run time.

>
> int arr[] = { 170, 45, 75, 90, 802, 24, 2, 66 };
> int n = sizeof(arr) / sizeof(arr[0]);
> qsort(arr, n, sizeof(int), compare);

So C is not OO (what a surprise ;-)) but it does do one thing right is
it separates out the concerns of storage from processing at the lowest
levels (hard to get above that level and that is why I use Java for my
freelancing work).   Which when working in any language is a good idea
but since C is not OO we are stuck with naked function calls (no harm
in that)

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