Rust For The Linux Kernel Sent Out For Review A Fourth Time

[Vistaus]

I was simply pointing out that the steady rise in popularity and increased adoption of Rust is an indication of its "success" as a language.
The time frame is irrelevant (albeit that helps on the "maturity" scale), it's the rate of adoption that really matters.

Age is never a definition of maturity. If it was, then we wouldn't have 40-year olds acting like 16-year olds, for example. Hell, even in software land, that would mean that we should be using KDE 1 instead of KDE 5, as KDE 1 is more mature in terms of age.

[akira128]

Age is never a definition of maturity. If it was, then we wouldn't have 40-year olds acting like 16-year olds, for example. Hell, even in software land, that would mean that we should be using KDE 1 instead of KDE 5, as KDE 1 is more mature in terms of age.

Maturity (at least in my mind) has nothing to do with functionality, capability, features...etc.
Maturity refers to things like being well-understood, having a formal language specification...etc

ie

https://en.wikipedia.org/wiki/ANSI_C

I mean, developers want a language and associated libraries to be well-documented, api stable, and bug free.
And that obviously takes time to get to that point.

So in short: stability and standardization --which again, are traits that have absolutely nothing to do with overall functionality.

Also, I simply said that time helps on the maturity scale (as in it doesn't hurt). I never said it was the be-all end-all.
There's obviously a million other factors involved.
And why does everyone on the g*d damn internet take everything to the extreme?!
Oh...he said that "time helps on the maturity scale"....oh...that must mean that he thinks "time == mature == better".
I bet you'd be great at this game called "jumping to conclusions" .... you definitely have the mind for it ; )
I mean c'mon man, understanding context and nuance is key. Unfortunately, not everyone has the ability to process information like that...

[pabloski]

I bet it's not C fault, but some developer. It's quite hard language, but very powerful one.

Yes obviously. If we programmers were omniscient God, we would program with a hex editor. Why waste time with IDEs, debuggers, high and not so high level languages, runtimes, garbage collectors? You only need a hex editor.

But, on planet Earth, things are very different. Programmers are just humans. Their brains have very limited powers. We get tired. We lose concentration. And we make mistakes.

And if the programming model isn't there to help you, disaster is around the corner. It is that simple.

The radical innovation proposed by Rust is the implementation of a new programming model, a restricted model that squeezes the state dimension of a software and make it tractable by an automatic system. To understand this concept, thing about AES cryptography. Do you know why it is secure? Because the space of possible solutions ( keys ) is hugeeeee. This means the problem is intractable. There is no computer capable of brute forcing it in a reasonable time.

But what happens if you make a part of the key fixed? Maybe you force the highest 192 bit to be all zeros? The dimension of the problem decreases dramatically. Our computer can manipulate it and extract a solution in a relative short time.

Rust makes the same thing to the programming problem. The restrictions imposed by the ownership rules, make it possible for the compiler to track the lifecycle of a program object from the start to the end. This is why Rust's compiler can catch a lot of bugs at compile time.

Also Rust imposes on the programmer I code of conduct, by which no undefined behavior is tolerated. Think about strings in Rust. They are just vecs, so all the typical bound checks, ownership rules, etc... apply. But the string class adds another rule, that the byte sequences inside its buffer must be valid Unicode code points. This is not something imposed by Rust's programming model, but it is imposed by the code of conduct. A programming construct must identify the shortcomings and undefined elements of its domain and remove them.

So it isn't the language the only component being sanitized. It is the ecosystem. Build small modules, with restrictions in place if necessary and controls to shoot down every possible undefined behavior or other type of uncertainty.

[CommunityMember]

Yes obviously. If we programmers were omniscient God, we would program with a hex editor.

Real programmers set the universal constants at the start such that the universe evolves to contain the disk with the data they want.

Obligatory xkcd: https://xkcd.com/378/

[smitty3268]

Can you show us how successful the Rust is? I'm not against it, but I'm trying to figure out on what basis some people formulate their claims.

No, because I have no intention of trying to prove anything. I don't care what people think about rust. I'm not a huge proponent of it. I do think it's done a great job of generating ideas about what languages can do and showing that C can be improved upon, but that doesn't mean I think Rust will replace it or anything like that.

I just think someone claiming that Rust is a high level language and seemingly thinking that it relies on not being able to manage memory is hilarious to laugh at.

[jacob]

Weird quote pick for System76. We've made better pitches for Rust in the past, and that was just a description of a small project.

This would be more appropriate: https://www.rust-lang.org/production/users (138 companies listed)

But it's only a small fraction of companies using Rust, because your company has to willingly and voluntarily request to be added to the Rust website. Apple, Google, Microsoft, IBM, and virtually all the fortune 500 won't bother.

That's a fair point actually, and in that case another good reference would be the Rust Foundation. Google, MS etc are all there.

[STiAT]

I have written some device drivers in C, and I do not think Rust will help me a lot implementing, but yes, on the side of memory and thread safety.. yeah. It happens that you just oversee the obvious buffer overflow or race. It happens, no matter how experienced you are. It should not, but it does.

Time spent for me was hardly on the issues with C as a language but with unpredictable hardware and bad documentation, where it just does stuff it's not supposed to do. Rust will not change that.

I'd think on using Rust too, but for me Rust in the past years was waiting for features and fixes in stable. And my guess is this patches will have the same issue (I didn't even screen them, so it's just a guess).

When there is a version of Rust they deem fit for the task.. sure, I'd consider it. There are better and more knowledgeable people to decide where it makes sense and where not than me, and they know where their safety issues primarily come from. I don't have the full picture, only the perspective of somebody having developed device drivers, for me it would make sense. Not more work, and kills the issue of me and colleagues making stupid mistakes.

And for haters of Redox, I like what they're doing. They are not close to anywhere as of the time writing of becoming competitive, but it could one day in certain markets. Linux has a long history, Redox is young. For me it's a nice proof of concept. If it will have any mainstream real life application in industry or private use is to be seen. But with Linux around it will certainly be hard, just by the manpower and industry focus today behind the Linux kernel. But Linus himself said he's waiting for the next big thing to replace Linux. It may not be Redox, but something will come up some day. I may not live to see it though.

[jacob]

Actually, the most successful OSs (and their predecessors) were written in System 360/370/ESA/Z assembly language and (in some cases) PL/X. z/OS, z/VM, z/TPF, z/VSE are the current variants. While you may never have heard of those OS's, they do run a significant part of the underlying infrastructure and would be considered advanced and successful.

You are fighting a losing battle my friend. Those are people who think that before the C language and Unix there was Nothingness(tm), and that those two are also forever the last word in programming language and OS design, respectively. Anything that exists or has existed outside of them shall not be named, and any attempt to evolve beyond them is strictly Verboten.

[shmerl]

OS kernels are a low level endeavor. C is an extremely mature and successful low level language.

Old, rather than mature. C is also riddled with dated design problems that can't be fixed due to the need for backwards compatibility. C is good, but not good enough in the sense of language design progress. Rust is better.

[STiAT]

You are fighting a losing battle my friend. Those are people who think that before the C language and Unix there was Nothingness(tm), and that those two are also forever the last word in programming language and OS design, respectively. Anything that exists or has existed outside of them shall not be named, and any attempt to evolve beyond them is strictly Verboten.

I actually still developed in System 360/370 and PL/X. Since most programs people who still know those .. they're highly requested people. To maintain the stuff and to port it. I personally don't see a bright future for those, but actually - they still exist, and companies (especially banks) pay high salaries for people with skills in this field, who can maintain and help to port those. I even thought Cobol/BS2000 out of the picture until I realized they still exist (sure, Cobol has little to do with OS development, but I still wonder how they still exist, and how the *** they can still maintain BS2000 systems, the hardware should long be gone).

For those not knowing, BS2000 was released 1975, and even has a current release as of 2021.