Re: Some rather stupid questions about Rust and FreeBSD

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

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

This ^

Cheers,
Brett


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