The Case for Rust (in the base system)

Crivens said:
I would take the position that we do not know in which way it is screwed up. There seems to be a fundamental problem with manual resource tracking and no amount of work will fix that - just like the halting problem (also known as a compiler writers full employment theory).
Click to expand...

Well, since we now determined that GC is actually required we can as well build a new Lisp Machine. No compromises.

Just need to find a hardware vendor to make the special keyboards...
 
cracauer@ said:
Well, since we now determined that GC is actually required we can as well build a new Lisp Machine. No compromises.

Just need to find a hardware vendor to make the special keyboards...
Click to expand...
Well you may be able to bridge the gap, so to speak.

And if I get this right, the thread started about rust being dragged into the base for no apparent good reason. Maybe this is a unknown-known thing to us what makes this a good idea. But the main argument about rust seemed to be memory safety, so I would say any other language that has a mandantory pointer check, array check and yes, a GC, would fit the bill. Managing the resources really smells like the halting problem (you need to make sure that EVERY code path possible does it right), so a GC is a good idea. The array and pointer checks only help if no one directly overwrites your memory, then no language specific things will help you. Sure, lisp would fit the bill, but so does Oberon. And I think the system in the OberonStation (available as a spartan design), was completely written in Oberon, with no assembly code required.

So what can I say? Lisp is great (I'm currently reading up on CL), but when faced with the rust eco system .vs. needing a special keyboard, I might decide the only winning move is not to play.

And that is a risk I see in this move to rust. Old greybeards will decide not to play, you will attract more new developers. So you will loose experience and gain shiny, but brittle. Good deal? I think not. But my beard is getting grey, so what do I know...
 
As a greybeard I think our experience counts for far less than we believe it does! Every generation has to make their own mistakes and learn from them. Did our generation really listen to people like Dijkstra & Hoare & Wirth & Brinch Hansen & John McCarthy and all? We put them on a pedestal but we still wrote shitty code in C (& worse, C++) and most were *proud* of that! Later generation are at least trying to use safer languages! As I was telling my college friends who were moaning about “kids these days…”, the kids are alright!
 
Let's go back to the first place.

What Rust guys should need is to demonstrate that "at least some important part of FreeBSD can be ported to Rust and it is clearly easier to maintain than C/C++, of course safer". But without actually doing so, it doesn't seem to be possible.
In other hand, existing C/C++ based FreeBSD SHALL not be broken by new toolchains/libraries. There's a chicken and egg problem.

My proposal is to create a dedicated branch something like freebsd-rust from main branch and do all work there, without merging back unless the efficiencies are clearly demonstrated.
The branch SHALL be kept in sync with main branch for parts other than Rust specific. Without this, merge back wouldn't be done sanely once the efficiency and maintainability is demonstrated, WITHOUT PULLING IN NON-BSD-COMPATIBLY-LICENCED COMPONENTS, INCLUDING CRATES. More, crates needed for the work should be allowed to committed to FreeBSD repo.

If this causes too much a pain for official repo, forking from github (or something else) mirror and create branch there could be a candidate, as some committers already accepts pull requests on github.

Another important thing is that slowing down the developments on current code base is clearly DISALLOWED. All Rust-related work should be done by new-comers, although some mentors would be still needed.
This way, how many well-talented Rust programmers are attracted and kept using/developing FreeBSD can also be demonstrated.
 
bakul said:
As a greybeard I think our experience counts for far less than we believe it does! Every generation has to make their own mistakes and learn from them. Did our generation really listen to people like Dijkstra & Hoare & Wirth & Brinch Hansen & John McCarthy and all? We put them on a pedestal but we still wrote shitty code in C (& worse, C++) and most were *proud* of that! Later generation are at least trying to use safer languages! As I was telling my college friends who were moaning about “kids these days…”, the kids are alright!
Click to expand...
Nah. Modern C++ is fairly decent. "Safe by construction" isn't difficult to achieve e.g. if you stick to the C++ Core Guidelines. (I do participate in WG21 and in particular SG23).

C is a basket case. It is the lingua franca of interfaces so it can't really go away. I'm not very familiar with MISRA and the like but as far as I know the only way to make C safe is to not use a large part of the language and library.
 
smithi said:
Graham Perrin posted in honour of Wirth's death on Jan 1st:

READ.ME special edition: In memoriam of Prof. em. Niklaus E. Wirth

Some students of language history might also appreciate
https://dcreager.net/wirth/1968-closing-word/
Click to expand...

I recently got a copy of "Algorithms + Data Structures = Programs".

One appropriate quote:

"We will assume that adequate computing systems provide a warning in the
case of such mistaken access to a non-existent array component."

By that definition neither C nor C++ is adequate by default.
 
Paul Floyd said:
"Safe by construction" isn't difficult to achieve
Click to expand...
Yet, it is, as evidenced by vulnerability analysis. The point is that people had a lot of time to do the right thing by choice and they didn't so now people are proposing to make them do the right thing and of course this is "not fair" to people who always did the right thing (or merely did not get caught...) but nobody stopped people from doing the wrong thing or even tried to stop them because "why?" and the answer is becoming, "well, it's unacceptable now to write programs in a way that statistically creates more security vulnerabilities when you don't have to."
 
T-Aoki said:
My proposal is to create a dedicated branch something like freebsd-rust from main branch and do all work there, without merging back unless the efficiencies are clearly demonstrated.
The branch SHALL be kept in sync with main branch for parts other than Rust specific. Without this, merge back wouldn't be done sanely once the efficiency and maintainability is demonstrated, WITHOUT PULLING IN NON-BSD-COMPATIBLY-LICENCED COMPONENTS, INCLUDING CRATES. More, crates needed for the work should be allowed to committed to FreeBSD repo.

If this causes too much a pain for official repo, forking from github (or something else) mirror and create branch there could be a candidate, as some committers already accepts pull requests on github.

Another important thing is that slowing down the developments on current code base is clearly DISALLOWED. All Rust-related work should be done by new-comers, although some mentors would be still needed.
This way, how many well-talented Rust programmers are attracted and kept using/developing FreeBSD can also be demonstrated.
Click to expand...
So, who's gonna do it?

There's nothing preventing someone from doing the forking the code into an independent project, but you kind of have to know what you're doing, and how to overcome technical hurdles.

And whose call is it to allow the slowdown of development (or not) ?

When work is done for free, who can say that it's worth some money to invest in a manager who can, at the minimum:
  • Keep track of progress
  • Actually understand some of what's going on
  • Decide on priorities like bugs and features
  • Figure out which skill is actually relevant to a task (who can be asked to do something, and who it's better to not ask?)
  • Tell people to not engage in flamewars and be civil to each other?
  • Do all of the above with some authority that the team can respect and work under?
 
bakul said:
Every generation has to make their own mistakes and learn from them.
Click to expand...
Yes. And they can add those mistakes to their own goddamn operating system and leave ours alone ;)

As mentioned, I like Rust. I have always been waiting for a safe language that was also native (not VM like limbo/Java/.NET or GC like Go, D to keep with my retro interests). Once Rust has proven itself, I really do support the idea of pulling it into foundational projects. But not prematurely. It will just make a mess if it gets stripped out again. Rust has the potential to be more secure than Ada, especially when dealing with ASM/C boundaries. At least it isolates the entry and exit points for i.e memory bugs.
 
+1 for Rust for being able to build native libraries and executables instead of having garbage collector and being a runtime like Go. Many AUR packages in Arch Linux distro were rewritten in Rust and they are working as intended and even with better performance as their counterparts in c++. Still, I like the way that Rust control memory in a more deterministic way.
 
kpedersen said:
And they can add those mistakes to their own goddamn operating system and leave ours alone ;)
Click to expand...
:)

\begin{curmudgeon mode}
Where are the Ken Thompson or Linus Torvalds of post-Boomer generations?! There are some new efforts such ReactOS and SerenityOS but they are copying existing OSes and written in C or C++. Older OSes such as AmigaOS, AmoebaOS, BeOS, KeyKOS, Lisp Machine, NextStep, Oberon, Plan9, QNX, Synthesis Kernel etc. were far more interesting and each had something new and thought provoking to add to OS design canon. Now we are left with a few variations of extremely overweight Unix systems & Windows and tiny communities of fringe OSes.

Kids these days.... They need to up their game and unshackle their imagination! Choice of which language to write an OS in is not particularly interesting!
\end{curmudgeon mode}
 
bakul said:
:)

\begin{curmudgeon mode}
Where are the Ken Thompson or Linus Torvalds of post-Boomer generations?! There are some new efforts such ReactOS and SerenityOS but they are copying existing OSes and written in C or C++. Older OSes such as AmigaOS, AmoebaOS, BeOS, KeyKOS, Lisp Machine, NextStep, Oberon, Plan9, QNX, Synthesis Kernel etc. were far more interesting and each had something new and thought provoking to add to OS design canon. Now we are left with a few variations of extremely overweight Unix systems & Windows and tiny communities of fringe OSes.

Kids these days.... They need to up their game and unshackle their imagination! Choice of which language to write an OS in is not particularly interesting!
\end{curmudgeon mode}
Click to expand...
ReactOS is written in C and assembly, I think you are finding RedoxOS.
 
astyle said:
So, who's gonna do it?
Click to expand...
Of course, who want to do it. This case, by whom having passion to pull Rust into FreeBSD.

I don't think it good thing to divide very limited developers into C/C++ team and Rust team (of course, no one can force which to choose. FreeBSD is a volunteer-based open source project.) and to change minds who are strongly objecting should need "demonstration of efficiency both in performance and maintainability".
For making this possible should need new developers in Rust area.

I'm relatively open for introducing new language, but at the same time, believing that rewriting whole bunch of components at once is impossible.
For this kind of cases, existing codes written in C/C++ (C++ should be a lot more fewer than C, though) and codes added/rewritten in new language (this case, Rust) needs to sanely coexist/cowork.
If the ABI of new language (say, Rust) is stable enough and fit enough well with C, the pain would be relatively small, but forcing --crate-type=cdylib now could spoil at least some portions of Rust's advantage, if I understand correctly.

Moving goal clearly avoids creating sane API/ABI within C/C++ parts and Rust parts.
This is because I state "it's too early" and I think demonstration is needed for breakthrough into earlier shift.

Or do you have better ideas to change minds of who are objecting?
 
For the 6th year in a row, the Rust Project conducted a survey on the Rust programming language, with participation from project maintainers, contributors, and those generally interested in the future of Rust.
- 30% of Rust user respondents can write simple programs in Rust, 27% can write production-ready code, and 42% consider themselves productive using Rust. Of the former Rust users who completed the survey, 30% cited difficulty as the primary reason for giving up while nearly 47% cited factors outside of their control.
Click to expand...


That's their user base? Doesn't lead to much confidence.
 
imnotaduck said:
+1 for Rust for being able to build native libraries and executables instead of having garbage collector and being a runtime like Go. Many AUR packages in Arch Linux distro were rewritten in Rust and they are working as intended and even with better performance as their counterparts in c++. Still, I like the way that Rust control memory in a more deterministic way.
Click to expand...

What are AUR packages?
 
T-Aoki said:
I'm relatively open for introducing new language, but at the same time, believing that rewriting whole bunch of components at once is impossible.
For this kind of cases, existing codes written in C/C++ (C++ should be a lot more fewer than C, though) and codes added/rewritten in new language (this case, Rust) needs to sanely coexist/cowork.
Click to expand...
Well, GNU coreutils are getting re-written in Rust... and yes, that is "a whole bunch of components getting re-written".

And yeah, there's no good way around a demonstration of a proof-of-concept. Pick a good time (like a FOSDEM conference), have something that actually works and you're proud to show off.
 
kpedersen said:
Completely different to the Swift community where many will know 137% of the language
Click to expand...
I didn't know it was possible to know more than 100% of a language... but considering that it's an Apple product, you can't put it past any Swift dev to make such a claim... ;)
 
You must log in or register to reply here.
Back
Top