The Case for Rust (in the base system)

[T-Aoki]

And the upstream will change almost daily, just like NPM, CPAN, PIP does. Crates.io is just another clone of these

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

 

[kpedersen]

Yes. This is one of the reason I'm staying neutral (not welcoming, but not "fully" denying with regard to "memory-safe" aspect).

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.

 

[T-Aoki]

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.

 

[kpedersen]

I think Rust should've been built as a C frontend.

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

 

[Rock]

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.

To be C friendly is a oxymoron. But Visual C is more friendly for graphical users.

 

[T-Aoki]

To be C friendly is a oxymoron. But Visual C is more friendly for graphical users.

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.

 

[cracauer@]

I don't think that compile-to-C ever worked well for any language implementation. Just implementing exceptions is mostly impossible.

 

[kpedersen]

But Visual C is more friendly for graphical users.

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.

 

[Jose]

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.

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

 

[Crivens]

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?

 

[kpedersen]

I don't think that compile-to-C ever worked well for any language implementation. Just implementing exceptions is mostly impossible.

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)

 

[Crivens]

Maybe this is of help?