My Opinion on Rust

Chat about Zorin
1

I have seen Rust language referenced in many threads, often in a way that suggests that it is either desirable or undesirable.

I'd like to give some open thoughts on this.

Starting with the perspective of a mechanic.
You want your tools, clean, ready and where you expect to find them. Organized.
Importantly, you need a variety of tools. The right tool for the job.
You do not want to use the wrong tool for the job. It needs a good fit and practical application.

Coding is no different.

Rust as a programming language is a perfectly good tool.
It has application. It fits, in the right need.
Not all needs fit Rust.
Not all needs mean that Rust is the right tool for the job.

When it is, it should be used. When it is not, another programming language may serve better.

This is where Rust gets some heat, in the current time. It is being used sometimes, only because it is the New Thing. Used not because it is the best candidate, but for marketing appeal.

This does not mean Rust is not any good. It does not mean it should be shunned, as some broken landscape.
It has its application - places that are a good fit for it.

Nor should seeing a developer say that Rust is being used for a new application or an upgrade to an existing one be allowed to be a selling point without merit.

7 Likes
2

Exactly what I do when I'm humbly coding, if bash make the job I don't need python...
So the same applied to Rust.
Thank you for this interesting point of view.

3 Likes
3

But what about Rust being part of the kernel?

1 Like
4

It has its place.

The Linux Kernel is primarily C, and that is not going to change. Rust cannot replace it, and it won't because it cannot.

It helps to remember that the Linux kernel is a baked pie. The backbone is C and that will remain.
But, it already utilizes many languages where they are a good fit. Assembly is one.
As well as Perl, Python, Shell, DTL and Linker scripts.
Admittedly, some of these are not general languages and are quite specific use cases. But we do not balk at other languages being used for the kernel.

Rust can contribute meaningful improvements for Device Drivers and Hardware, supplying better memory security - and I say this as it actually applies. I know that currently, "Security" is a marketable angle for something else a developer wants.
Sometimes, a cigar is just a cigar. In this application, Rust handles memory management better, faster, and with a much reduced bug tree.
We would be foolish to refuse it.

But it won't replace the backbone of the kernel, nor ever gain dominance. Simply, that would also be foolish. It is not built for that kind of work and trying to do that would grossly bloat the kernel and cascade into thousands of separate actions that would be a massive spiderweb of nightmare to maintain.

2 Likes
5

I asked the question based on that article someone wrote about Rust not having any place in the Linux kernel elsewhere on here, as it appeared to be coming from an angle that some systems being developed were attempting to integrate Rust in the kernel or did I misread that?

1 Like
6

the subject is not the language we use to create a dialogue with the lower layers, only the result counts, once compiled it remains code that "speaks" the machine language...

5 Likes
7

I think I know the article you are referring to.
You linked it, I read it. I just tried a forum search, but cannot find it, now...

I then switched to my browser history and found it there.
Here is a fresh copy:

Over-all, I admired the writing. However, I did not agree with it as a whole.
Let's break down what I do agree with.

Adding a new language to the kernel has a real cost.
The maintainers of the kernel will need to either learn that language or employ people that are fluent in it.
This is a very valid concern. To me, I think the benefits can outweigh the concern. In reality, to stay sustainable, adaptation is necessary and that will come with costs.

Another of his better objections is exactly what I said above:

This is why it can contribute, but not replace. It has its place, but no place outside of it.

Rust cannot be a drop in replacement for C. Absolutely correct.

But the article then transitions from sound arguments to, dare I say, political bias.
Some claims are made that are not actually what Rust does, what the proposed changes are, etc. The author argues that Rust is to replace C - That is not the proposal.
It centers around this attitude:
"Rust advocates think Linux is wrong"

Above, I pointed out that in places where Rust fits, it can reduce bugs, make tracking of bugs easier, simplify communication with the kernel, and allow much better memory management.
This does not equate to "I hate C. It needs to go. Linux is wrong."
However... the author is not speaking blindly - From things I have read so far, some few minority rust developers have expressed that attitude. And I think this is what led the author down that rabbit hole.
In reality, that is a minority and does not speak for the majority nor implementation.
This is akin to any extreme fringe of any particular group.

It switches to politically charged speculation at that point and for me, that is when Red Alert sirens sound in my head.
I do not like being Led To the Conclusion.

The reality is, no actual participants are trying to replace C in the kernel as the author tries to imply Heavily.
Only that it be used in cases needing better memory management in New Code Only.

This circles back to the O.P.: Rust language is not a bad one.
It has its use cases. We should examine the merit of them; not react immediately with fear.
Nor...
Should we tolerate Rust being used as a sales pitch or marketing gimmick, either. It is not the messiah of coding. It is just
...Another programming language.

4 Likes
8

Well as you probably already know I am not a coder, so I cannot comment. The only 'coding' I have experienced was limited to a very brief encounter with Basic on a Teletype terminal at college where we got the chance to code "Hello world" (the IT Department were very possessive, and there I was thinking they would have P.E.T. or an Apricot!

Other than that, my experience was using Casio code. With that and my Programnable Casio FX-502 P, I created a countdown timer which was easier to create than a 'clock'. The only practical use was writing code to it for computing Purchase Ledger and Sales Ledger balances. I don't have the patience to learn code, I am an end user, is all.

9

I remember the hysteria a few years ago, maintainers (developers?) leaving the project with bad blood, and a lot of what was basically political in-fighting. I watched this video, by Brodie Robertson, which goes into more recent details, especially about the Rust experiment being over. He also covers what Linus Torvalds had to say. Anyone interested can find the video here: https://www.youtube.com/watch?v=kwXn_GSd8cA

Google has integrated Rust at kernel (6.12) level, so as an Android 16 user, I’m using it every day. From what I’ve read Google reports that Rust code in Android has a ~1000x lower memory-safety vulnerability density compared to C/C++. That is pretty impressive. Not only is it more secure but it’s much faster to deploy too as, it spends 25% less time in code review, and also has a 4X lower roll back rate. It goes even further if you’re a Google Pixel 10 user. The modem firmware now uses Rust for its DNS parser to prevent remote baseband exploits.

As @Aravisian states above, Rust is a tool to be used for doing the right job. Some invested personalities can’t accept change. That happens in every sphere, including the Linux kernel project.

3 Likes
10

As programming languages and compilers evolve and improve over the years, new ones are adopted, often as they are easier to learn, or the code created is easier to understand and maintain. So the next generation of programmers/coders/software developers (call them what you wish) adopt the language that is gaining popularity and aid their continued careers, particularly when AI is threatening. I don't think there is much call for Algol or Fortran programmers these days, but software bloat is now acceptable price to pay when new programming tools emerge. Bring back Assembler and Machine Code I say :slight_smile:

4 Likes
11

I'm not a Programer. I'm only a User. And as a User, I want simply a stable, working Program. If the Developer uses Rust, C, Python or whatever, I primary don't Care to be honest.

That being said: When a Program has a specific Task and a Programming Language would fit better to this Task than another, I would not surprisingly think that it would be better to use the Language that fits better to the Task.

But when a Programmer would say that he/she has a Preferation what he/she can handle better, I would see that as an Argument. When someone programs something with a Language that he/she knows instead of a Language that he/she not knows or not know enough and the Result works fine, then I would think it is fine. As long as there aren't any mayor Flaws.

2 Likes
12

If you work in a physical machine shop - you can buy a tool. Even an expensive tool is still acquired in a moment. Maybe by budgeting and planning.

But learning a language - that takes more devotion and effort.
So, programmers will often try to adhere to languages they know, for both mental conservatism and for job security; rather than acquire a "new tool."

The kernel team is known for some rough in house fights.
And this is where human nature really applies.

When there is a strong debate, each side tends to get more aggressive about stating their case, not more willing to examine the merits of someone else's argument.
The result of this is that each side will begin to edge toward extremes.
As a party gets defensive, or tries to push their point harder, they drift from their own original arguments.
I think this has a lot to do with the mis-impression about some wanting to replace C, or hating on C - as debate drift led to a person vigorously defending their reasoning in a heated argument - it gives the wrong impression.

3 Likes