The Case for Rust (in the base system)

kpedersen said:
And the upstream will change almost daily, just like NPM, CPAN, PIP does. Crates.io is just another clone of these
Click to expand...
Yes. This is one of the reason I'm staying neutral (not welcoming, but not "fully" denying with regard to "memory-safe" aspect).
"Moving goals" do not fit for base. So even if Rust (or any other candidates for "memory"-safe languages) itself is well standardized in the future, crates (and any kind alike) used in official userland and/or kernel should be developed and maintained by FreeBSD project (and/or its variants like HardenedBSD).
 
T-Aoki said:
Yes. This is one of the reason I'm staying neutral (not welcoming, but not "fully" denying with regard to "memory-safe" aspect).
Click to expand...
That's a good position to maintain.

I know I often talk negatively about Rust here, but if they can just sort out their dependency / bindings issue, the language is *so* close to being a game changer. That is probably why I give it such a hard time.
 
I think Rust should've been built as a C frontend. If so, talented and experienced C developers (unlike me) in FreeBSD project and any other projects would be understand what's still-in-C side of codes do to obtain best results from Rust via code reviews.

This kind of process was, IIRC, often done when asm was most frequently used, to see the asm outputs of the compilers are fine or problematic.

I (recently) consider C as kinda structured assembler or good intermediate language (even though, some codes are still needed to be in asm, sometime for optimization, sometimes for defining specific memory layouts and/or special (unusual-in-C) sections, and/or specifying quite specific MMU configurations.

So for Rust-specific sections would be needed to be asm in those cases.
 
T-Aoki said:
I think Rust should've been built as a C frontend.
Click to expand...
I exactly agree. It would allow Rust to benefit from direct interop with C libraries (probably the core reason why C++ has remained so popular). Of course we all want safety but there is no way we can give up clean access to C when the entire computing platform *is* C (for better or for worse).
 
T-Aoki said:
I'm still neutral about Rust (but my thought is still that it should be more C friendly by default on linking together for looooong transition timeframe and that strict standardization for keeping backward compatibilities after the point is mandatory), but for anyone interested:

Early PoC for introducing Rust into userland is disclosed by HardenedBSD project.
Related toot on Mastodon by Shawn Webb is here.
Click to expand...
To be "C friendly" is an oxymoron. But Visual C is more friendly for graphical users.
 
Last edited:
Rock said:
To be C friendly is a oxymoron. But Visual C is more friendly for graphical users.
Click to expand...
To be C friendly is far more friendly for C developers than graphical users.
Not at all oxymoron.

New languages with new concepts/philosophys are hard to understand/learn for anyone experienced with old languages.

Generating old language (here, C) as the intermediate language hopefully helps understanding the new concepts/philosophies.
 
I don't think that compile-to-C ever worked well for any language implementation. Just implementing exceptions is mostly impossible.
 
Rock said:
But Visual C is more friendly for graphical users.
Click to expand...
I never understood this, Visual C is not visual at all compared to the competitors. I suspect it was just another classic Microsoft wordplay to confuse people and cash in on the success of Visual Basic at the time (which *was* friendly for graphical users).

Microsoft do this a lot. C# to cash in on the popularity of C, VB.NET to hide the death of Visual Basic and Visual Studio mac to hide the fact that VS is not cross platform.
 
T-Aoki said:
I'm still neutral about Rust (but my thought is still that it should be more C friendly by default on linking together for looooong transition timeframe and that strict standardization for keeping backward compatibilities after the point is mandatory), but for anyone interested:

Early PoC for introducing Rust into userland is disclosed by HardenedBSD project.
Related toot on Mastodon by Shawn Webb is here.
Click to expand...
Not enough resources to support LibreSSL, but able to add a giant Rust dependency to userland? No, thanks.

HardenedBSD Switching Back to OpenSSL | HardenedBSD

hardenedbsd.org hardenedbsd.org
 
I'd say rust is the smaller problem. Before going further, I would like to see a solution to the crates swamp that is lurking under the surface. How do they plan to reign that dependency hell in?
 
cracauer@ said:
I don't think that compile-to-C ever worked well for any language implementation. Just implementing exceptions is mostly impossible.
Click to expand...
Thats fine. The Rust guys claim to simultaneously both support and not-support exceptions depending on whatever argument and narrative they are trying to give that moment ;)

I don't think a C transpiler is necessarily a good approach (Bjarne struggled with this in CFront). I think a C frontend working more with the AST / gimple is more likely to work.

(I have a copy of the CFront source code which I am on-and-off trying to fix templates on (would be a powerful offering for C-only commercial embedded toolchains!). The code is not good quality, suggesting that *maybe* it is possible for exceptions to be implemented by a more skilled developer than myself or an 80's Bjarne Stroustrup)
 
Jose said:
Not enough resources to support LibreSSL, but able to add a giant Rust dependency to userland?
Click to expand...
I'm not a member of HardenedBSD project, but if I understand correctly, HardenedBSD is derived from FreeBSD and basically rebasing eventually.

So unless upstream FreeBSD switches from OpenSSL in base to LibreSSL, switching to LibreSSL in its base is simply a mess (putting aside in ports).

On the other hand, HardenedBSD is (IIUC) switching options FreeBSD already has to safer side as much as possible, plus, implement original codes.
Introducing memory-"safer" language for their original codes would be on the same direction they're developing.

And don't forget that the current implementations Shawn disclosed are still PoC (Proof of Concept). If he (or other project mempers) found Rust not fully fit their needs/resources and found another better-to-fit language, they can still switch again from Rust to it.
 
T-Aoki said:
So unless upstream FreeBSD switches from OpenSSL in base to LibreSSL, switching to LibreSSL in its base is simply a mess (putting aside in ports).

On the other hand, HardenedBSD is (IIUC) switching options FreeBSD already has to safer side as much as possible, plus, implement original codes.
Introducing memory-"safer" language for their original codes would be on the same direction they're developing.

And don't forget that the current implementations Shawn disclosed are still PoC (Proof of Concept). If he (or other project mempers) found Rust not fully fit their needs/resources and found another better-to-fit language, they can still switch again from Rust to it.
Click to expand...
I guess we'll agree to disagree. Doing something like this is probably a whole lot less work than "bringing in vendored Rust crates into the src tree", and a whole lot more valuable to all users, too.
 
kpedersen said:
I never understood this, Visual C is not visual at all compared to the competitors. I suspect it was just another classic Microsoft wordplay to confuse people and cash in on the success of Visual Basic at the time (which *was* friendly for graphical users).

Microsoft do this a lot. C# to cash in on the popularity of C, VB.NET to hide the death of Visual Basic and Visual Studio mac to hide the fact that VS is not cross platform.
Click to expand...
I remember VBasic. Very popular. Never learned it. VC, VC# came later. But with VC Windows can compile C code. I am not sure if Visual C is used in Windows now. Maybe is only usefull in Microsoft.
 
Last edited:
I think that if someone wants Rust in the base system, then that someone should copy the source code to FreeBSD and build a RustBSD. Which excuse is preventing it? I like the old expression: if it isn't broken, then don't fix it. Nitpicking a language will never cease to exist. Eventually, we'll be reading comments such as "they should've stuck with C" or "Rust gets on my nerves".

I'll keep using FreeBSD. Freedom of choice means that a Rust community can build RustBSD and remain impartial to FreeBSD with C/C++ instead of thinking that everyone else should, nay must, also support Rust. :rolleyes:
 
I've got my popcorn ready for when they break their filesystem/network code with all of this pointless rewriting. An exodus of engineering talent coming to FreeBSD in the near future?
 
Beastie7 said:
I've got my popcorn ready for when they break their filesystem/network code with all of this pointless rewriting. An exodus of engineering talent coming to FreeBSD in the near future?
Click to expand...
I'd advise to switch that to clue bat and fly swatter. Those engineers will come with a certain amount of funny ideas, they will need some adjustments.
 
Crivens said:
I'd advise to switch that to clue bat and fly swatter. Those engineers will come with a certain amount of funny ideas, they will need some adjustments.
Click to expand...
Indeed. Beastie7 is correct that we will likely see more developers come to FreeBSD (systemd didn't bring "developers" as such; mainly sysadmis/power-users), especially those who want to keep with homogenous C, which will in many ways be great; more punching hands for drivers and things.

However, Linux is a disgusting cesspit and we will need ways to protect ourselves from this same thing happenening. Currently the worst technical decisions (Annoying languages, Bad Build systems, Vast Dependencies, Weak Display Systems) tend to be coming from the graphics ecosystems. I don't want to say its because they typically attract the younger generation (which I suppose I am a part of)... but I feel it is a contributing factor.

cracauer@ said:
Forking an open source project is a big deal.
Click to expand...
Yep, and for BSD which by definition is mostly monolithic as a project structure, this becomes even harder because you have to maintain *everything*. MirOS is a good case study.
 
Interesting language. lang/numbat.

Not sure how actually usable it is (as I'm not yet actually studied it), but it seems to be kinda "safe" language. It seems to free us from mangling units like km vs mile, kg vs lb, deg vs rad.

Unrelated with this thread? No, no! It's written in Rust (unfortunately for me to understand the implementation).
 
numbat is a good name for a programming language. sounds like number battle. But radians is mostly for pure mathematics {?}. On Rust I am neutral. C to me is unknown but it is very hard to replace given what it stands for in Unix.
 
Mangled units sometime causes fatal problems in real-world usage.
So I think unit-safety is far more important than memory-safety.
Note that I'm not saying memory-safety is not important. It's quite important but unit-safety is far more important.
 
You must log in or register to reply here.
Back
Top