Re: Some rather stupid questions about Rust and FreeBSD

On Wed, Sep 11, 2024 at 6:36 PM B. E. <estrabd@gmail.com> wrote:
>
> 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.

Nobody is invading anything.  Myself and the other Rust boosters have
been involved with FreeBSD for longer than Rust has existed.

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

Systems programming IS the problem domain that Rust is uniquely good
for.  Nor do we have a solution in search of a problem.  As I've
explained elsewhere on this list (but you can 100% be forgiven for
overlooking; there've been a lot of posts), I've already encountered
many problems within FreeBSD that could've easily been solved by Rust.
Being experienced with both C and Rust, but being forced to use the
former, feels like a real handicap.  To recap:

* I considered writing the fusefs test suite in Rust.  It would've
been well-suited.  But I was forced to do it in C++ instead.
* I tried to write a prometheus exporter for CTL in Rust.  But when I
realized that the API is unstable, I had to abandon using ports, which
meant that I had to abandon using Rust, and use C instead.
* I had to fix several file-parsing and memory-handling bugs in ctld.
Just to help myself understand the code, I rewrote part of it in Rust.
The portion that I rewrote took about 5.5x less code and was free of
memory-handling bugs.  But I can't finish it, because the src tree
currently only allows C and C++.
* ALL of the recent security advisories involved memory handling bugs.
We obviously can't rewrite all of the affected components overnight,
but those SAs should serve as a wake-up call that C is insufficient
for developing reliable and secure software.  Any components that we
can rewrite will improve the quality of our project.


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

I've noticed that the most vociferous opposition to using Rust in
FreeBSD comes from users like yourself: casual users who do little to
no development of FreeBSD.  If you aren't a developer, then what are
you afraid of?  Longer compile times when updating your desktop from
src?  If Shawn Webb's project works out, then you won't have to worry
about that.  A larger .iso for installation?  Even the smallest thumb
drives are now larger than our dvd image.  Please explain to me: what
negative impact do you foresee for yourself?

-Alan

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