Rust in base

[David Demelier]

Le 27/01/2020 à 18:01, Ihor Antonov a écrit :
> FreeBSD uses clang to compile, and clang uses LLVM as a backend, so as
> Rust. So theoretical number of platforms that both platforms support are
> the same. Looking at links below I think it is not fair to say that
> FreeBSD supports more platforms:
> 
> https://www.freebsd.org/platforms/
> https://forge.rust-lang.org/release/platform-support.html

This has probably changed, I just remember that it was a common complain 
on several IRC channels. Happy to see that it's no longer the case.

> Well so is clang and llvm, but these are in base. And there are people
> who would like to have options to have a slimmer base (embedded as an
> example)

In contrast to popular belief, clang+llvm codebase is smaller than gcc :-).

I'm not huge fan of having compiler in base, but it is required by 
POSIX. [0]

> It speaks more about disadvantage of C than anyting else. In C you have
> only 2 options - hope that necessary dependency is supplied by your
> operating system (or system's package manager) or bundle the dependecy
> whith your code. The latter is especially bad because it prevents code
> re-use, and such dependencies often left unmaintained, because they are
> hardly relevant to the goal of the main part of the codebase (look at emacs for
> example).

Libraries are usually well written in both C, C++. They usually don't 
try to provide minimalist interface for doing anything. Did you remember 
left-pad fiasco? [1].

I don't see how bundling a dependency is a bad thing, this is common for 
C/C++ applications under Windows and macOS. Note: even flatpak does it 
(and I hate that). Note: I try to avoid that if possible though.

Libraries (and shared libraries especially) were designed to deduplicate 
space disk and bring security updates easily. With Rust packages, it is 
required to rebuild/reinstall all applications if there is a security 
issue in one widely used dependency.

> I can argue that writing kernel or dirviers requires fair amount of
> knowledge and skill too, and complexity of Rust in this comparison looks
> tiny. And Rust's complexity comes with memory safety guarantees, and as
> we all know memory related bugs are very common in C (simply because
> humans can't write safe C in general).

That's what unit testing is made for if obviously people are enough 
motivated to write. Hardware drivers are more complicated to test but 
whatever which language they are written if you don't “communicate” with 
your hardware correctly it'll still not work. In 16 years of use I never 
had Linux kernel panic. On FreeBSD I had some but I can count them on my 
fingers.

With direct access to hardware, memory and such, I'd be glad to know how 
that would be possible in Rust without having at least one `unsafe` 
block though.

> As Polytropon said - FreeBSD is moving towards modularization of base.
> So rustc is not going to be included, even more so, I think even clang,
> sendmail and other non-essential things will be modularized and become
> optional.

That's a good thing but I still hope we won't need Rust (or Python, or 
Perl, or Ruby, or Tcl, etc.) to build base. In my very strong and utopic 
opinion, base should be built with only POSIX tools other parts should 
just move to ports. My vision of what base should be is: kernel + POSIX 
"coreutils" + FreeBSD specific commands (gpart, devd, etc).

> Without community support these efforts will remain academia experiments
> and will be forgotten. It is sad to observe how people in this thread
> unilaterrally sceam "NO!", without even reading into the question.

No, there are already people trying this. It's called redoxOS [2].

The difference here is asking to FreeBSD developers which are usually 
found of KISS, UNIX, simplicity and where C is pretty among those 
philosophies as well.

[0]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html
[1]: https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos
[2]: https://www.redox-os.org

-- 
David