Re: Re: The Case for Rust (in the base system)

Interesting responses.
I figured I'll give some input on those.

On 2024年01月21日 09:04, the silly Alan Somers claimed to have said:
> I think I touched on a sensitive issue.

This is expected to happen, especially after the amount of controversy
this already has caused on the Linux side of things.

> * Why Rust instead of Perl, Java, C#, or Go?
> 
> The crucial difference between Rust and those other four, basically between
> Rust and everything else since C++ [1], is that Rust is suitable for low-level
> systems programming.  It lacks memory manangement, green threads, etc.  The
> runtime is small (and optionally can be removed entirely).  Rust isn't quite as
> low-level as C, but it's in about the same position as C++.

There is the borrow checker though.
I haven't coded in Rust further than just the first chapter kinda level,
but it theoretically sounds like instead of the burden of memory
management being put on the runtime (Java, Go, C#) or on the programmer
(C, C++), it's done by the compiler (Rust, Zig).

> * Why not just use C++ then?
> 
> Speaking from experience, I'm far more productive in Rust than C++, and my code
> has many fewer bugs, too.  I had been using C++ professionally for 11 years
> before I learned about Rust, but after 6 months my Rust skills were better than
> my C++ skills.  That's why I finally realized that I wasn't the cause of my C++
> problems; C++ was.  In general, it feels like C++ has a cumbersome mix of
> low-level and high-level features. Smart pointers, for example, are handy.  But
> because it retains so much C-compatibility C++ can't enforce the use of smart
> pointers.  And it can't even warn against the use of dumb pointers.  It
> certainly can't check their lifetimes.  But in Rust, all pointers are smart
> [2], so the compiler can help you avoid a wide range of common bugs.

I know the feel man, I attempted to learn C++ so many times, only to
find myself uncontiously using C instead.
Actual C++ is so rich in features, I feel like you just can't learn C++
unless you've been with it since the 1980s.

Rust does seem to suffer from the same problem as C++ in that features
keep getting added on over time.
It's quite a contrast from C or Go where the standard libraries barely
change throughout their entire existence.

> * Rust will go out of fashion by the 2040s
> 
> Perhaps it will.  But Like David Chisnall, I'm afraid that if FreeBSD never
> modernizes, then it itself will go out of fashion by the 2040s.

I don't really see changing languages as "modernization".
In the webdev space we've seen so many "modernizations" so many times,
it more often feels like this whole space is building the Tower of
Babel, rather than something like a Sphinx; so a structure doomed to
eventually collapse, rather than something that only loses 1 piece, but
other than that survives thousands of years of history.

> * "<something> can't be implemented unless written in rust"

As long as it's a real language, anything can be implemented in any real
language.
By the end of the day, every language eventually becomes assembly, which
in turn becomes machine code, and a programming language is only there
for the programmer to make him or her understand what the hell is going
on.

> * Rust in base would double our compile times
> 
> Yes, it would.  That's the worst thing about it.

Compile times could be lowered by refraining from using Cargo packages
for literally everything, but from so many projects I've come across, it
really seems just as impossible for Rust developers as it does for
Javascript developers to refrain from using NPM packages.

And this is my biggest issue with everything being turned into Rust,
especially after having witnessed everything being turned into NodeJS
prior.

-- 
lain.

Did you know that?
90% of all emails sent on a daily basis are being sent in plain text, and it's super easy to intercept emails as they flow over the internet?
Never send passwords, tokens, personal information, or other volunerable information without proper PGP encryption!

If you're writing your emails unencrypted, please consider sending PGP encrypted emails for security reasons.
You can find my PGP public key at: https://fair.moe/lain.asc

Every good email client is able to send encrypted emails.
If yours can't, then you should consider switching to a secure email client, because yours just sucks.

My recommendations are Claws Mail or NeoMutt.
For instructions on how to encrypt your emails:
https://unixsheikh.com/tutorials/gnupg-tutorial.html