Re: Some rather stupid questions about Rust and FreeBSD

On Wed, Sep 11, 2024 at 3:26 PM Aryeh Friedman <aryeh.friedman@gmail.com> wrote:
>
> Let's start with the only thing I know about Rust is it is some
> language that is all the rage among in some corners and not in others.
>   I have built it in ports before when just setting a normal old XFCE4
> desktop and looked at some sample code in it from that I will say:
>
> 1. It takes FOREVER to compile

I assume you mean lang/rust.  It does take FOREVER to compile, because
it builds its own version of LLVM.  That's why I suggest adding it to
ALLOW_MAKE_JOBS_PACKAGES , if you're using Poudriere.  Ordinary Rust
programs generally compile at a similar speed as C programs.  Slower
than Go, but faster than C++.

> 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.  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);
}

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

in Rust
=======
let mut arr = vec![170, 45, 75, 90, 802, 24, 2, 66];
arr.sort();

The most visible difference is that C needed a comparison function to
be provided, and that function must be defined far away from where the
sort happens.  With Rust, the comparison operator is a property of the
data type (technically, it's defined by the data type's PartialOrd
implementation, which can be derived automatically for most structs
but can also be manually implemented).  But readability isn't the
important part.  Notice that in C, the programmer must tell qsort
* The size of the array
* The size of each element
* The name of the comparison function

Each of those is error-prone.  Stuff like that is a common source of
bugs in C code.  But Rust tracks it automatically.

>
> So to help me understand all this fuss can people tell the
> journalistic (who, what, when, how and why) for the following:
>
> 1. What exactly is Rust?

It's a compiled, strongly and statically typed, memory-safe, systems
programming language.  It first appeared 9 years ago, sponsored mostly
by Mozilla.  Mozilla was interested because web browsers are too
complicated to reliably program in C/C++, but too performance-critical
for other memory-safe contemporary languages like Java or Go.

> 2. What's all the fuss about it over (both here and the larger
> computing community)?

The computing community in general is excited because Rust really hits
a programming language design sweet spot.  Modern features like
modules and procedural macro make Rust highly productive.  Its safety
features make Rust code more reliable than C/C++ code.  And yet most
of that safety is achieved at compile-time, incurring 0 runtime
overhead.  So Rust is faster than other memory-safe languages like
Java and Go.  Crucially, it isn't memory-managed like those two, so
it's suitable for systems programming and even for embedded systems.

> 3. What is the entire debate about ports vs. base

At this time, there is absolutely no reason not to use Rust for
programs that will live in ports.  Nobody is arguing about that.
However, there is quite a lot of code in the base.  Much of it can't
move to ports, because it's too tightly coupled to the kernel or to
other stuff in base.  And the fact that we ship our own compilers in
base limits the base to sh, C and C++ (plus a little bit of Lua).
That limitation is a big impediment to both our productivity and our
code quality.  Some of us would like to use better languages in the
base (mostly Rust, but Go and Oberon fans have chimed in too), but it
just isn't possible.  Making it possible would require either:

1) Importing the Rust toolchain into contrib/ (currently the least
favored option, because compile times are too long)
2) Allowing some parts of the base to depend on an external toolchain
(what Shawn Webb is currently working on)
3) Being more like Linux, meaning that the base system will slim down
to be little more than a kernel while many other programs move to
ports.

> and why should a normal user care?

It probably won't make a difference to a pure desktop user or a
non-programming sysadmin.  If anything, they'll just notice that their
operating system of choice gets less buggy.  Error messages might look
a little bit different.  The size of the .iso download might increase.
But it will make a big difference to developers, even occasional ones.
We'll all be more productive, and we'll build a higher-quality
product.  Occasional developers will have more confidence that their
changes won't cause regressions.

I hope that helps.