The Case for Rust (in the base system)

The way a non-technical person might see it is that us nerds have had 52 years to figure out how to stop making these kinds of mistakes and we continue to not adopt practices that prevent them. If we're going to make stuff that's so important to people's lives, and we won't do anything about it, the non-technical people outnumber us and are going to do something about it. I would suggest not being so smug about just writing "correct" C, which obviously hasn't worked for fifty years, and solve the problem before they come for us. That's why people are suggesting using Rust.

Look at Boeing.
 
Basically the Rust developers are spending their time lobbying the "White House" to do their advertising for them rather than making their language actually feasible. Classic Rust "talkers". Very much par for the course.
It's reassuring to know that POTUS is a master programmer after all, though! I bet he writes his specs in Z. :cool:
 
Rust is mentioned only once in the report. So is CHERI, the capability architecture for processors.

Too much paranoia & conspiracy theories in this thread.
 
The way a non-technical person might see it is that us nerds have had 52 years to figure out how to stop making these kinds of mistakes and we continue to not adopt practices that prevent them. If we're going to make stuff that's so important to people's lives, and we won't do anything about it, the non-technical people outnumber us and are going to do something about it. I would suggest not being so smug about just writing "correct" C, which obviously hasn't worked for fifty years, and solve the problem before they come for us. That's why people are suggesting using Rust.

Look at Boeing.

Well, on the grand scale C and C++ as the canonical memory-unsafe languages are actually pretty new languages.

The memory safe (well, kinda, if such a thing exists) language Lisp came along in 1957.

Unix and the C language it brought us are practical, but they represent significant steps back in a number of areas, safety being one of them. Goes back to "Worse is better" by Richard Gabriel https://www.dreamsongs.com/WorseIsBetter.html
 
Basically the Rust developers are spending their time lobbying the "White House" to do their advertising for them rather than making their language actually feasible. Classic Rust "talkers". Very much par for the course.
everyone and their uncle, too. 😏
 
The way a non-technical person might see it is that us nerds have had 52 years to figure out how to stop making these kinds of mistakes and we continue to not adopt practices that prevent them...
Since the vast majority of security compromises come from social engineering, I can turn that right back around and tell non-nerds to stop clicking on every link in that email from "russianbridesforyou.com". And please, change your password. Yeah "password1234" is not secure. And whatever crusty warez you're looking for are not worth the trojan they're going to install.

Look at Boeing.
What about Boeing? The problems there started when the Harvard MBAs took over from the engineers.
 
And whatever crusty warez you're looking for are not worth the trojan they're going to install.
Sometimes, that 'crusty warez' is LibreOffice with an infected installer. We had a specially licensed version of Office for a specific class of machines at $JOB. License for that version of Office, expired, rendering many Office installs unusable. Renewing the license was a complicated process that was taking forever, mired in bureaucracy. In the meantime, user really needed Office on that class of machines. Most departments do have their own 'utility repos' that have been vetted by Cyber Security. The copy of LibreOffice in question - it was fresh stuff (at the time) off the Internet, not from an internal repo. Machine in question had to be carefully de-commissioned and a brand-new replacement had to be deployed - sans Office, whose license renewal was still stuck in bureaucracy at the time.
 
A typical program written by a JS/Rust developer will fetch in 100+ micro-dependencies of shite from NPM/crates.io. I am sure a couple will start to be infected with the odd trojan too.
It has already happened:
 
Since the vast majority of security compromises come from social engineering, I can turn that right back around and tell non-nerds to stop clicking on every link in that email from "russianbridesforyou.com". And please, change your password. Yeah "password1234" is not secure. And whatever crusty warez you're looking for are not worth the trojan they're going to install.

In order to flip this, nerds have to take the log out of their own eye. Otherwise both are just as culpable.

What about Boeing? The problems there started when the Harvard MBAs took over from the engineers.
An example of bad engineering practice. You can argue that the MBAs made the practice, but 🤷‍♀️ what's the difference between that and bad choices by engineers.
 
An example of bad engineering practice. You can argue that the MBAs made the practice, but 🤷‍♀️ what's the difference between that and bad choices by engineers.
An MBA can actually say, "Yeah, maybe not the best practice or safest results, but money is rolling in, so we don't care". That's the difference that msplsh is probably looking for...

An engineer can only say, "Sorry, my boss said to release the design to manufacturing NOW or else I'm fired".

Does anyone remember the story of exploding smartphones that Dilbert comics had going right before getting dropped from syndication/publication?

Circling back to the original conversation of this thread, using a troublesome product as an important component should give you pause. This thread talked about how the Rust-lang project is in trouble, with micro-dependencies and (dev burnout due to project mismanagement) being the glaring issues that cannot be overcome by the technical benefits offered from memory safety.

Same with exploding smartphones - the issue of thermal management circuitry in those phones needs to be addressed, instead of pulling wool over customers' eyes and telling them that the 'problem' is not really a problem... In that story, the benefits of even having a smartphone - they cannot be overcome by the poor design choices that make for a flaw that bad.
 
Or they make a recommendation that's bad. Engineers don't default to smartest in the decision chain.
Yeah, just because an engineer came up with a cool idea doesn't mean the engineer has the most sensible use case in mind. Brilliance and insanity are sometimes the two sides of the same coin. Remember the TempleOS guy?
 
An interesting and refreshingly honest opinion post. This part is particularly interesting:

The third example is godot-rust, which are Rust bindings to the Godot Engine. The most serious crime committed by this library is that it's not a pure Rust solution, but instead just bindings to a filthy C++ engine. I'm exaggerating a bit, but those that are looking at Rust from the outside may be surprised how close to reality this sometimes is. Rust is pure, Rust is correct, Rust is safe. C++ is bad and old and ugly and unsafe and complex. That's why in Rust gamedev we don't use SDL, we have winit, we don't use OpenGL, we have wgpu, we don't use Box2D or PhysX, we have rapier, we have kira for game audio, we don't use Dear ImGUI, we have egui, and above all we surely can't use an existing game engine that's written in C++. That would be a violation of the sacred crab code that everyone who uses rustup default nightly to get faster compile times agrees on in the license (the same one that prohibits us from using the logo (tm)(c) officially endorsed by the Rust foundation).
I think it is becoming increasingly clear that the Rust community is absolutely naive when it comes to dependencies. They believe that they are avoiding C by not using SDL and instead using winit.

You would imagine they would look at the winit Cargo.toml file to see exactly what kind of technical debt they are acruing. Some highlights:
  • "i686-pc-windows-msvc", (C compiler toolchain... Only half a dozen are supported/tested)
  • xkbcommon-dl/x11
  • x11
So SDL isn't worse (or less safe) to wrap against than libX11. It is still C all the way down, they just don't realize. winit might be *lighter* than SDL and that would be a more valid reason than that cited by the author.

Weirdly, that is probably the biggest issue I see in the article. I think many of the other issues will be resolved once Rust becomes more mature (yes, long after our+grandkids lifespans)
 
I am always disappointed when Rust macros are bashed by those who used them for a while. Compile-time computing is such an important part of changeable software.
 
The point of not using SDL in Rust is that a rewrite can be approached from the opposite direction and then you'll get the full stack.
 
So... it's not enough to have Linux fragmentation, we now have to have programming language fragmentation... in the last 10-15 years, the number of programming languages really went up. This much diversity does get in the way of standardization and creating value - in early 2000s, knowing Java was the hot thing, Python was the cool thing for 2010s, and now it's Rust for 2020s... 😩 How about we start working towards a language called Yeast? (tongue in cheek, of course). 😏
 
The point of not using SDL in Rust is that a rewrite can be approached from the opposite direction and then you'll get the full stack.
That is surely a pipe dream? They will never do it. For one there is probably a correlation between Rust fans and Wayland fans scared of the X protocol and writing a client from scratch.

So really writing SDL from the bottom up (ontop of a fundamental wayland lib when it matures) will be a more tangable solution if they ever hope to get away from C.

But that aside, libSDL or libX11 is all still C anyway so doesn't resolve the author's point of not using a C or C++ engine.

So... it's not enough to have Linux fragmentation, we now have to have programming language fragmentation...
Once you ignore the noise, you realize there is no fragmentation. Everything is C (or at most, a near superset like C++).
 
Once you ignore the noise, you realize there is no fragmentation. Everything is C (or at most, a near superset like C++).
So why is the syntax so wildly different? What about the execution model (Linear vs. interactive like sh)

BTW, I can kind of see why "Everything is C": just about any language does have a C API.

Hell, why not just go straight to brainfuck and be done with this? ;)
 
BTW, I can kind of see why "Everything is C": just about any language does have a C API.
They get access to C libraries almost for free (minus the tedious bindings).

Mainly because most languages are an "illusion". Think of them more like config file parsers. They are basically just C programs that read differently formatted text files and call the corresponding C function based on what they encounter.

Fundamentally the Python interpreter and libjson are very similar things. The only difference is that libjson by default doesn't have the ability to assign callbacks to C functions to trigger when it encounters a specific node name. (Or does it? Some actually might).

In the past I have used Lua as a config file format (it was a fairly heavy handed solution but worked weirdly well)
 
Hell, why not just go straight to brainfuck and be done with this? ;)
Because then all discussion will be centered around indent styles and function name schemes. That will create a singularity. We can't have that.

Ok, back on track. Most languages have a binding to C is because C is a pretty portable macro assembler. Few people can start at that level and write their software from that layer up. I know only one guy who did that, all the way from assembler up to the C++ compiler.

And somehow you need to write your runtime support library. And you don't want to do that over and over again. So in the end, all ways lead to C.
 
Back
Top