Re: Some rather stupid questions about Rust and FreeBSD

It doesn't matter the technicalities, Rust enthusiasts are looking for
relevancy in a post-language wars world; and they think falsely that their
only recourse is to invade established camps.

I feel sorry for them in a lot of ways, but this is the time for them to be
discovering problem domains or creating solutions that Rust is uniquely
good for; and not copying or corrupting established technical communites.
Augmenting FreeBSD *somehow* is not a legitimate problmem domain nor is it
something uniquely solved by Rust. Don't be a solution in search of a
problem is my best advice to the Rust community - unfortunately much of the
low hanging problems have been picked; but there are plenty of slightly
less easy problems to solve.

So, this is ideologically and existentially driven, and rational arguments
are not enough (FreeBSD is not experiencing this alone). Setting extremely
hard boundaries, in charity, is the only answer. I am a mere casual but
consistent user of FreeBSD from a long time ago, and I very strongly
support all firm (but charitable) opposition to Rust being required to run
FreeBSD.

Cheers,
Brett

On Wed, Sep 11, 2024 at 7:11 PM Aryeh Friedman <aryeh.friedman@gmail.com>
wrote:

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