Linus Torvalds Is Cautiously Optimistic About Bringing Rust Into Linux Kernel's Next Release (zdnet.com) 123
slack_justyb shares a report from ZDNet: For over three decades, Linux has been written in the C programming language. Indeed, Linux is C's most outstanding accomplishment. But the last few years have seen a growing momentum to make the Rust programming language Linux's second Linux language. At the recent Open Source Summit in Austin, Texas, Linux creator Linus Torvald said he could see Rust making it into the Linux kernel as soon as the next major release. "I'd like to see the Rust infrastructure merging to be started in the next release, but we'll see." Linux said after the summit. "I won't force it, and it's not like it's going to be doing anything really meaningful at that point -- it would basically be the starting point. So, no promises."
Now, you may ask: "Why are they adding Rust at all?" Rust lends itself more easily to writing secure software. Samartha Chandrashekar, an AWS product manager, said it "helps ensure thread safety and prevent memory-related errors, such as buffer overflows that can lead to security vulnerabilities." Many other developers agree with Chandrashekar. Torvalds also agrees and likes that Rust is more memory-safe. "There are real technical reasons like memory safety and why Rust is good to get in the kernel." Mind you, no one is going to be rewriting the entire 30 or so million lines of the Linux kernel into Rust. As Linux developer Nelson Elhage said in his summary of the 2020 Linux Plumber's meeting on Rust in Linux: "They're not proposing a rewrite of the Linux kernel into Rust; they are focused only on moving toward a world where new code may be written in Rust." The three areas of potential concern for Rust support are making use of the existing APIs in the kernel, architecture support, and dealing with application binary interface (ABI) compatibility between Rust and C.
Now, you may ask: "Why are they adding Rust at all?" Rust lends itself more easily to writing secure software. Samartha Chandrashekar, an AWS product manager, said it "helps ensure thread safety and prevent memory-related errors, such as buffer overflows that can lead to security vulnerabilities." Many other developers agree with Chandrashekar. Torvalds also agrees and likes that Rust is more memory-safe. "There are real technical reasons like memory safety and why Rust is good to get in the kernel." Mind you, no one is going to be rewriting the entire 30 or so million lines of the Linux kernel into Rust. As Linux developer Nelson Elhage said in his summary of the 2020 Linux Plumber's meeting on Rust in Linux: "They're not proposing a rewrite of the Linux kernel into Rust; they are focused only on moving toward a world where new code may be written in Rust." The three areas of potential concern for Rust support are making use of the existing APIs in the kernel, architecture support, and dealing with application binary interface (ABI) compatibility between Rust and C.
hmmmm (Score:2, Interesting)
Re: (Score:2, Funny)
Well, you can always run GNU Hurd. Which, as we all know, is superior to Linux in every way, except for practical ones.
That's not the only concern, but it is a concern (Score:2, Insightful)
I'm sort-of waiting for the first linux kernel exploit enabled by the presence of rust. That much code, there's bound to be some exploitable holes in it.
linus' wording looks like he might be thinking that if someone really wants it to happen he's not going to stand in the way, rather than that he's actively supporting it. It's still being taken as active support by the rust evangelisation strike force and the fawning press. Which goes to show what they know.
In either case, his long-term stewardship fitnes
Re: (Score:2)
I'm sort-of waiting for the first linux kernel exploit enabled by the presence of rust.
I'm waiting for the first kernel exploit discovered by Rust.
Re: (Score:2)
I'm sort-of waiting for the first linux kernel exploit enabled by the presence of rust.
Well, there's plenty of rot in there, so the rust probably won't amount to much. Oh, wait...
Re: (Score:2)
Twenty years ago I was surprised at how bloated the kernel was even at the lowest core. But that's ok, it's not mean for tiny systems, and a full virtual memory system is fundamental to modern Unix. The upshot means that for many embedded systems where there are some real time requirements that much of the system work gets shoved down into the kernel. And the modern kernel is designed to let this happen with various features. Still though, if you're taking an embedded RTOS based system and migrating to Li
Re: (Score:3)
It's not as bloated as it looks. A lot of kernel code is conditional compilation. But yeah, we usually err in favor of performance and scalability over terseness.
So how did it get to 30 million lines?! #if!!! (Score:2)
I am hoping that most of it is in obscure device drivers.
It is a testament to the developers that on the one hand they are clever enough to get a single blob of 30 million lines of code to work, but on the other hand are crazy enough to try. But there is no way Linus or anyone else really understands it any more.
And I hope that your comment about conditional code is wrong. Code riddled with #if is a mess. Hopefully well designed interfaces with option modules. Takes a bit more thought, but the only way
Re: (Score:2)
Yes, by far the majority of kernel code is in drivers. Core kernel is tiny by comparison and that is where you will often find large amounts of source that may compile down to a tiny amount of object code or no object code at all if some kernel option is configged off.
Re: (Score:3)
Rust has far more powerful tools for automated analysis than C does. Ever tried to read a cpp macro of any complexity, much less develop one?
Re: hmmmm (Score:2)
Re: (Score:2)
Re: (Score:2)
And why would that be the case?
What have multiple languages to do with "attack surface"?
Care to elaborate?
Linus continues being optimistic (Score:3, Funny)
like he was five days ago [slashdot.org] in the exact same conference you are reporting now.
Re: (Score:2)
He's two times as optimistic as before!
Re: (Score:2)
Would it be too much to ask that Slashdot get editors who, I dunno, actually enjoy reading the site themselves? Might avoid a lot of dupes that way.
And that's great (Score:3)
Rust is definitely more annoying to write in than C (it's half-way to Java), though it's certainly no more annoying than C++. But in return you get nearly guaranteed safety running 99% as fast.
I don't want to say 100% guaranteed because poop happens, but scaremongers crying about 'additional attack surfaces' are just missing the point. There are 30M existing lines of linux C/C++ code that are just completely riddled with vulnerabilities that are exploited every single day. Most of them would be neutralized with Rust, and FUD aside every bit of kernel that's in Rust and not C/C++ will improve that.
Re: (Score:3, Interesting)
You make a religious argument, not an engineering one. Good Rust is far safer than C, without a doubt. Superficial fashions are meaningless compared to the pragmatic assurances delivered. Perhaps use it and understand it before throwing Monday night armchair quarterback shade.
If someone wanted to make a safer Linux kernel, they might write a formally-verifiable one in Rust on top of seL4. The beauty of seL4 is being able to add other architectural pieces to the mix after-the-fact like compatibility layers f
Safety isn't free (Score:5, Insightful)
It doesn't happen by magic , extra instructions have to be inserted by the compiler in the binary to do all the runtime bounds checking. That might be fine in a desktop application but it is most definately not fine in parts of the kernel that could be in a tight realtime loop where microseconds (sometimes even nanoseconds) matter.
Re: (Score:3)
It doesn't happen by magic , extra instructions have to be inserted by the compiler in the binary to do all the runtime bounds checking.
Rust does bounds check in the runtime, but many uses of Rust that you might expect to bounds check do not actually do so. If you access a single element of an array using square bracket and an index, that will bounds check. If you use iterators to loop through part or all of an array, it will not bounds check, because it is known to be safe. Rust calls this a zero-cost abstraction because, well, it is zero-cost at runtime. Likewise, use-after-free detection, race-condition detection and many parts of the ty
Re: (Score:2)
"Likewise, use-after-free detection, race-condition detection ... .... They are all enforced at compile time"
Neither of those can be reliably enforced at compile time unless their use cases are severely restricted which rather defeats the point.
Re: (Score:2)
Rust does it by forcing you to code in a very particular way.
Eg, when you pass a bunch of data to a function, it now belongs to it, and it's a compile-time error to do anything with it afterwards. So you can't have a situation where you do (in pseudocode):
Because as of the first line, you gave up your ownership of x. In Rust, you have to either explicitly let "frobnicate" to borrow the variable, which then forces it to giv
Re: (Score:2)
If you pass a reference to a stack allocated object in C++, the function you're calling could for instance take the address and stick it into a heap-allocated list. It could spawn a thread and modify it at unpredictable times. It's your problem to establish conventions and documentation to avoid this kind of thing.
Rust decides that either it now belongs to the function you ga
Re: (Score:2)
Yes this is the compromise. Rust gets around this problem by having two parts to it. A safe part (which is the main part) and the unsafe part (which gives you just a few extra things). In safe code a use-after-free cannot happen, while in unsafe code it can. The latter has to explicitly declared and is often a very small part of the code base.
In a kernel it might be more. We don't know yet. If it works well, though, it should limit the sections of code where bad things can happen. No magic bullet, but possi
Re: (Score:2)
this claimed "safety" is just a meme until proven. Plenty of ways to cause a disaster in the kernel even with Rust's features.
Re: (Score:2)
Not like you are ever going to, having never coded a line of kernel code in your life.
Re: (Score:2)
False, had to do that in grad school.
If you don't know a thing about someone's background best not to make up cocky b.s. eh?
Let me guess, you're a butthurt Rust fanboi wishing something of significance would be done with your pet language that mostly isn't used for the infrastructure of our world?
Re: (Score:2)
So you cut and pasted some kernel code.
Re: (Score:2)
Most of Linux is drivers for obscure hardware. The core of Linux is very small.
Re: (Score:3, Interesting)
There are 30M existing lines of linux C/C++ code that are just...(snip)
a) Never trust anybody who writes "C/C++".
b) Against all common sense, Linus has never allowed a single line of C++ in the kernel.
Re:And that's great (Score:4, Funny)
b) Against all common sense, Linus has never allowed a single line of C++ in the kernel.
The best part of reading linux kernel code, is all the re-implementation of C++ that's in there.
Re: (Score:2)
Hey, we want a C based object oriented system, so let's not use C++ and re-invent it all terribly!
Re: (Score:2)
There are 30M existing lines of linux C/C++ code that are just completely riddled with vulnerabilities that are exploited every single day
Wrong on multiple levels. First, there is not C++ code in the kernel because Linus does not like C++. Second, it is not riddled with vulnerabilities, rather it is considered one of the most thoroughly debugged large bodies of code in the known universe. Third, it is big news when a Linux kernel vulnerability is found because this is a rare thing indeed. If a Linux kernel is exploited it is almost never because of an open kernel vulnerability, but rather because an attacker got root access because of poor se
Isn't Rust bad? (Score:3)
It's the degradation of iron. It flakes off in dark brown bits leaving a mess, structural integrity is compromised, and requires replacement unless you want a total collapse.
*whisper* *whisper* *whisper*
Never mind.
Re: Isn't Rust bad? (Score:2)
Wrong kind of rust.
https://en.m.wikipedia.org/wik... [wikipedia.org]
Re: (Score:2)
Rust Never Sleeps (Score:2)
"Linux is C's most outstanding accomplishment" (Score:2)
Uh, no.
Re: (Score:2)
I'd for for Unix, which is still around and of which Linux and GNU utilities are a work-alike.
Re: (Score:2)
which is still around
We're not handing out participation awards here. My grandpa doesn't get credit for me getting an engineering degree either. Unix may be "still around" but it hasn't had remotely the direct impact on people's lives that Linux has.
Posted from my phone, which ... you know ... is not running a Unix kernel.
Re: (Score:2)
Oh so you're not using one of the 55 percent the phone market which is iPhone?
You're funny, Mac OSX is Unix, so are the BSD including the tons of embedded stuff in everything from elevator controls to network switches to printers.
Seems you have a case of ignorance about just how much Unix (not to be confused with Unix TM) that is out there
Ada/Spark would be a much better addition (Score:2)
Check out 11 Myths About Ada [electronicdesign.com] if you think Ada/Spark is not a viable option. You can learn and try Ada and Spark at learn.ada [adacore.com]
Re: Ada/Spark would be a much better addition (Score:2)
Sure ... (Score:2)
Indeed, Linux is C's most outstanding accomplishment.
If you ignore all the versions of Unix that came before and since.
Re:Ugh, please, no (Score:5, Interesting)
"It's way too easy to write code you can't even understand yourself two weeks later"
Also true of Perl & many, many others - including C++
Re: (Score:2, Interesting)
Not like Scala, Ocaml, and Rust though. These are all multi-paradigm languages combining structured, functional, object-oriented, scripting, and other design patterns all in to one ball of complex garbage.
You can shoot yourself in the foot with Perl, C++, or C real easy but it always looks ugly. These multi-paradigm languages let you create beautiful elegant works of art... that are nearly impossible to read and understand by someone else or even yourself if you're away from it for a while.
Re:Ugh, please, no (Score:4, Interesting)
Re:Ugh, please, no (Score:5, Interesting)
Absolutely not.
Rust intends to do things like guaranteeing you can't double-free memory in any circumstances whatsoever, because it forces you to structure the code in such a way that you can't make it happen. Valgrind will only tell you nothing is being double-freed right now, but won't tell you there's an input that could make it happen.
Re: (Score:2)
But that already exists. Use C++, with smart pointers everywhere, and you'll never see a double-free.
The one and only thing that Rust brings is package management. And, as history has amply demonstrated, you probably don't want that as much as you think you do.
Re:Ugh, please, no (Score:5, Interesting)
C++ exists, but Linus doesn't want it in the kernel for various reasons. Rust has less weird features and gotchas so I suppose it's more to his liking.
C++ is also far more liberal. Yeah, you have smart pointers everywhere, but doing that is an explicit choice you opt into and you retain the ability to new/delete whenever you please, and to do operations on stuff without locking, and invoke undefined behavior easily. Rust is the other way, safety is the default, undefined behavior is avoided, and you have to explicitly opt out of this. Which means any Rust codebase can be trivially searched for "unsafe" blocks where anything could be going wrong, and the language's aim is that you should never need an unsafe anything except for specialized purposes like interfacing with non-Rust things.
I'm not sure if package management has anything to do with the kernel, this is kernel code, and that's special.
Re: (Score:2)
Re: (Score:2)
It's undefined behavior. Which means risking the nasal demons, especially in the modern times where compiler writers feel invoking UB is a license for coming up with some evil genie interpretation of your program.
Re: (Score:2)
At the time there was no difference between malloc/free and new/delete. Is there now ?
New calls constructors and delete calls destructors.
These days there is usually no reason to use either.
Re: (Score:2)
new/delete calls constructors/destructors.
Either way though there's very little need to use them these days.
Re: (Score:2)
And how do you create an object without calling new? ...
You are just silly
Re: (Score:2)
And how do you create an object without calling new
1. Declare it, so it's on the stack.
2. If you need an unknown bunch, have a container of objects.
3. If you need zero or one, use an optional
That covers 99% of use cases.
If you really need a pointer:
3. use a unique_ptr
4. If that doesn't cut it, for example in the presence of threads or unusual ownership use shared_ptr
About the only need for using new/delete is in some sort of custom container or related construct. That's fine, but if you're writing then more
Re: (Score:2)
There always was a difference between malloc/free and new/delete.
Handled by two completely separated libraries, you never could (at least not portable) delete a thing you malloc-ed.
The main difference - obviously - is that delete calls the destructor, if available, and malloc does not.
Also every class can define its own new/delete methods. And malloc does not call constructors.
Re: (Score:2)
Re: (Score:2)
But that already exists. Use C++, with smart pointers everywhere, and you'll never see a double-free.
Until you start to use a third party library, that does not use smart pointers everywhere.
C++ may be a fine language for those who truly understand all of it including its weird edge and corner cases, but I'm not either one of those people, so the combination of a managed, higher-level language, plus just a bit of C in just the places it's needed, has always worked well for me.
Re: Ugh, please, no (Score:2)
If you want to do something useful, i.e. comparable with what modern languages do with references, using smart pointers, you likely need a shared_ptr. There is a performance cost.
Re: (Score:2)
Re: (Score:2)
An input does not make some memory double freed.
Idiot.
Rust intends to do things like guaranteeing you can't double-free memory in any circumstances whatsoever,
That is a library thing, aka the malloc/free library, and not a language feature.
Idiot.
Re: (Score:2)
Sure can. See, in computing we have this thing called a "variable", which may be filled in by an input. And variables can be used in "if" statements. Valgrind only can test the path that is currently be executed. It can't tell you that a program could go down a different path if given a different input, which could cause something to go wrong.
So valgrind, while an extremely useful tool, is only telling you about what is going wrong in the present circumstances
Re: (Score:2)
Once again, the idiot is you.
Re: (Score:2)
One will write functional code, the other like C, the other with objects, etc...
No language frees you from the need to do code reviews. Also, if you can't cope with different styles... then brush up your skills. Otherwise you'll be unable to dig into second and third party libraries/modules to debug stuff.
In C there's only one way to do a loop: for (i=0; iNb; i++).
You can have basically anything in any of the three places. The reason that C++ has more than one way of doing a for-loop (excluding range-for)
Re: (Score:2)
You can do the same thing with while. :P
You could even challenge the reader with a hand made goto loop
Re: (Score:2)
You could even challenge the reader with a hand made goto loop :P
Sir! I am not a barbarian.
Re: (Score:2)
But you actually do know that a for loop in: Java, C#, C, JavaScript, Per, AWKl etc. p.p. all look the same?
Idiot ...
Re: Ugh, please, no (Score:2)
Yeah, those multi-paradigm languages are a nightmare to maintain, or even to work on as a team. One will write functional code, the other like C, the other with objects, etc... and in the end nobody can read anybody else's code.
Rust is multi-paradigm, but object oriented isn't one of those paradigms. Rust has no concept of either hierarchy or inheritance. Yes, you can treat things with an object mentality, but you can do the same in any language, including C. In fact, your code will be a lot easier to read if you do that.
The main thing Rust allows that some programmers will use and some won't is struct impl's and traits. I guarantee you that if you don't ever use those, your code will be much more verbose, harder to read, harder t
Re: (Score:2)
Re: (Score:2)
C doesn't provide collections in its library so comparing it to languages that do is like comparing apples to oranges. But if you did use a C collections lib the same issues exist as other languages - you need functions to insert / remove / read elements, iterators and a way to step through the collection, etc. All of these are potential sources for errors to happen as is the sheer burden of writing a loop that sets up and calls these things.
Most languages recogni
Re: (Score:2)
Bad coders write bad code in every language.
Blaming "multi paradigm" (and mixing it up with "design patterns") indicates you belong to that bunch of bad coders.
Re:Ugh, please, no (Score:5, Interesting)
"Rust produces bloated binaries"
Not really. By default, Rust binaries are statically linked, with debugging data and capable of exiting nicely on a crash. Switch this off and they get a lot smaller. Use of `no_std` makes them smaller still
"Rust produces slow binaries; slow bloated C/C++ code that has Rust's features to"
Again, not really. The key features of Rust (memory safety, type safety and thread safety) are all enforced at compile time and are not apparent in the binary.
"The Rust compiler, written in Rust, is a prime example"
The Rust front end is written in Rust. The bulk of compiler time is spent in LLVM which is written in C++. When and if the GCC port comes of age, that will similarly be implemented in C.
"It is too easy to write code you can't even understand"
This one has some truth in it. Rust is quite succinct and has well integrated macro's, both of which mean that it is possible to go too far to the point of terseness. The flip side is that the Rust community generally tends toward good documentation, and Rust has nicely integrated doc/doctest facilities that is a standard part of the tool chain.
"Best would be to try to recreate an existing well written C project or do a side-by-side development Rust/C"
There are some examples of this of course, but mostly people integrate Rust because it has good C interop rather than replace wholesale. The examples that do exist are quite different from the linux kernel which, of course, is a singular piece of software. That's why they are starting off small.
Your "not really" are too easy. (Score:4, Interesting)
"Rust produces bloated binaries"
Not really. By default, Rust binaries are statically linked, with debugging data and capable of exiting nicely on a crash. Switch this off and they get a lot smaller. Use of `no_std` makes them smaller still
But not "small". So "yes, really."
"Rust produces slow binaries; slow bloated C/C++ code that has Rust's features to"
Again, not really. The key features of Rust (memory safety, type safety and thread safety) are all enforced at compile time and are not apparent in the binary.
That makes the code "not slower" in that respect (only), not "faster". So again, "yes, really."
"The Rust compiler, written in Rust, is a prime example"
The Rust front end is written in Rust. The bulk of compiler time is spent in LLVM which is written in C++. When and if the GCC port comes of age, that will similarly be implemented in C.
Were it otherwise, that would make the rust compiler a large project written in rust.
Notice that since it isn't, requiring rust in the kernel makes bootstrapping a full linux system capable of recompiling itself require bootstrapping C (doable), C++ (for LLVM, a superset of the work required for C), rust (yet more work) and LLVM (how many man-hours?).
So no matter how you spin it, this is bad for portability. Even rewriting the entire kernel in rust will not noticeably reduce the work required for porting since even if you succeed in removing the last shreds of C, you're still stuck with rust, LLVM, and thus C++.
Unless you rewrite LLVM in rust. And why aren't they starting with that, hm?
This is actually a big huge important question that points at the rust bunch their motivation. They want to be important, even indispensable, moreso than that their toy be useful to anyone else.
There are some examples of this of course, but mostly people integrate Rust because it has good C interop rather than replace wholesale. The examples that do exist are quite different from the linux kernel which, of course, is a singular piece of software.
Apart from random toy projects, I'm mainly seeing large existing codebases that are deemed ripe for "improving" by throwing another compiler toolchain at it. The interop is an excuse, not a reason.
That's why they are starting off small.
They're not. They're trying to insert themselves everywhere so as to become indispensable. Meaning, too burdensome to get rid of.
This is related to why they're big on strict codes of conduct, too: It's all about the evangelisation of an idea, with the language as the vehicle to promote the idea. That the language often doesn't deliver on the promise can, even must be, be ignored and shouted down, since the idea is all that matters.
This observation meshes well with, basically the entirely of your argument: You too are prone to ignoring the inconveniences of reality for the sake of the idea.
Getting the language rust stuck anywhere and everywhere into other people's craw^Wprojects sideways is fishing for validation, IOW, identity politics poured hot code action. Seen in that light, their behaviour is true to form.
(Also, use quote tags, will you.)
Re: (Score:3)
"Rust produces bloated binaries"
Not really. By default, Rust binaries are statically linked, with debugging data and capable of exiting nicely on a crash. Switch this off and they get a lot smaller. Use of `no_std` makes them smaller still
But not "small". So "yes, really."
About the same size as C/GCC depending on lots of things, of course.
"Rust produces slow binaries; slow bloated C/C++ code that has Rust's features to"
Again, not really. The key features of Rust (memory safety, type safety and thread safety) are all enforced at compile time and are not apparent in the binary.
That makes the code "not slower" in that respect (only), not "faster". So again, "yes, really."
I was replying to "slow" not "not faster". But before we get into a pile of double negatives, rust has been built to be fast. Comparisons with Java or Python in this regard are not really good ones. You can always argue over how successful they have been, of course, but the overall argument that Rust is performance encumbered because of it's memor
Re: (Score:3)
Hold on, first the claim is it's a proper and better replacement for C, now you're saying it's a different tool from C. Which is it? You can't have it both ways.
I don't know whether it is better or whether it will take over. This will take a long time to find out. I used Rust in my last project because it seemed quite nice. It still does.
Then you're not thinking. If I want the system to compile itself on the machine it runs on then every tool needed to build the system must run on that machine, too.
If you're going to make exceptions then you cannot build the complete system and have to limp along, risking running into stupid roadblocks that would have been avoided if the build environment on the machine was a first-class citizen among the "supported" platforms.
If you use a machine which makes use of parts of the kernel that are only available in Rust, then you will need Rust to recompile it, otherwise you won't. At the moment those bits are small. The intention is that they will grow which will, indeed, increase the requirements on the toolchain. But there is lot between that point and w
Re:Your "not really" are too easy. (Score:4, Interesting)
This is actually a big huge important question that points at the rust bunch their motivation. They want to be important, even indispensable, moreso than that their toy be useful to anyone else.
That is blatantly obvious. And it is one of the main reasons I do not trust them one bit. We already have another bunch of assholes that did that: The systemd cabal. At the moment they are still relatively easy to circumvent, at least if you know what you are doing. But it gets harder and they are doing damage with their bloated mess.
Re: (Score:2)
It's blatantly obvious that you yourself are incompetent and your knowledge is obsolete therefore you are afraid of anything new that will expose your learning disability.
Re: (Score:2)
This is quite a nice blog post about trying to write a 64K intro demo in Rust. In the post he gets a trivial Windows app running requiring under 4k of binary.
https://www.codeslow.com/2019/... [codeslow.com]
Re: Ugh, please, no (Score:2)
"I looked at Java once 20 years ago and didn't like it, trust me. "
Re: (Score:2)
I last used Java in production probably about 15 years ago, and in those days, I was a pretty strong advocate. But then Oracle. :( And now for that reason alone, I won't touch it.
Also, I hate type erasure. It makes Java generics nearly unusable for a lot of the work that I do. And I don't believe that has ever been fixed.
Modern C# on .NET Core is open-source, cross-platform, and has been more or less my go-to language for most of my work since its inception. You might say, "but Microsoft," and yes, it'
Re: Ugh, please, no (Score:2)
Also, I hate type erasure. It makes Java generics nearly unusable for a lot of the work that I do. And I don't believe that has ever been fixed.
Nope, it hasn't. And it's painful. Apparently the Java maintainers still think it's a good idea in its current form. Although technically Rust has type erasure, unlike Java, it's just an implementation detail and you'll never need to code around it, or even know that it exists.
Re: (Score:2)
Although technically Rust has type erasure, unlike Java, it's just an implementation detail and you'll never need to code around it, or even know that it exists.
In Java it is also just an implementation detail.
Ordinary developers do most likely not even know about it.
I never had a project where type erasure was an issue. (However I did not agree with it, when it was implemented - but now it is to late to change it, it would break to much code. The only option would be to invent a new "template syntax" that
Re: (Score:2)
It's definitely more than an implementation detail. I don't know about you, but I've been using Java almost as long as I've been using Rust, and I've done basically the same things in Rust that I've done in Java.
I've had a use case where I needed to create an interface method that would accept an undefined number of parameters (IIRC I was creating a string formatter implementation.) I don't recall the name for it, but it's the one where your method argument uses an ellipses. If you want to accept more than
Re: (Score:2)
Also, I hate type erasure. It makes Java generics nearly unusable for a lot of the work that I do. And I don't believe that has ever been fixed.
I'll agree with you that type erasure probably wasn't the best way of implementing generics, but it did allow old binaries to work with newer versions of the JVM.Technology has advanced a lot since Java was introduced in the 1990s, but it's hard to take advantage of it without breaking binary (or even source!) compatibility. Would Java survive if all existing code had to be rewritten?
Re: (Score:3, Insightful)
Cool story. On the other hand I'll follow what Linus says rather than some dweeb on the internet who can't even be bothered to stand behind his words enough to uncheck the "Post Anonymously" box.
Ain't nothing like burning all your credibility before anyone has even read a word of your post.
Re: (Score:2)
I think I already know who it is anyways: The Evil Atheist. These are his exact talking points, and he can never resist posting them in an article about Rust going into the linux kernel. I think he posts anonymously now because I (and others) routinely debunk the shit out of his arguments and make him look like the ass that he is.
Re: (Score:2)
Honestly at this point unless someone is posting sensitive information about their work, I have zero respect for seeing the words AC anywhere.
Honestly sometimes I make troll posts, sometimes I post stupid shit, and some of my opinions are abrasive, but they are mine and I associate them with me. If I had an opinion I didn't want associated with me, there's probably a good reason for why it's stupid ... like nearly all AC posts are.
I for one wouldn't be sad to see this feature disappear. AC posting gives jus
Re: (Score:2)
To post as non AC you have to make an account. ...
And that requires an email address
Plenty of people can not be arsed to make one, I did not make one for over ten years ...
Re: (Score:2)
Wow. You clearly haven't paid attention to Slashdot for the past 3 years. Try this: Log out and *try* to reply to this anonymously. You'll get the following:
"Sorry, anonymous posting has been turned off. Please register and log in."
100% of people posting here as AC do so with registered accounts. Loginless posting was disabled years ago.
Re: (Score:2)
Boo-fucking-hoo for you!
Why boo fucking hoo for me? I'm not the one burning my credibility and looking like an idiot. I'm just proposing a Slashdot change to save idiots like you from your own retardation.
Re:Ugh, please, no (Score:5, Insightful)
Rust is a very declarative language with a C-style notation and generally simpler than most C/C++ since the implementation and declaration are one and the same. I don't know why you think it's unreadable. I suppose if you were to get into lifetimes or futures there would be things to learn but mostly it's transferable knowledge since the backend compiler and memory model are the same.
What trips up people coming from C/C++ is that the compiler will beat the shit out of them until they write code that doesn't violate lifetime rules or other enforced checks. This can be frustrating because those other compilers don't even care, but that's the point trying to be solved. Half of kernel CVEs are for things ignored by the C compiler like NULL pointer exceptions, double frees, over/underflows etc. that the Rust compiler wouldn't even allow to be compiled, or could be caught at runtime in a meaningful way.
Re: (Score:2)
Re: (Score:2)
If it is who I think it is (The Evil Atheist) then yeah, that's what he regularly does. He probably posts anonymously because he's been made a fool of so many times now on this exact issue.
One time he gave me a link to supposed rust CVEs, and I think somewhere between a third and a half of them were actually C libraries, and only got tagged under Rust because some Rust code uses them. After I pointed this out he shut up real quick. Actually he shuts up real quick after a lot of his bullshit gets pointed out
Re: (Score:2)
I sincerely wish Linus would try writing a real project in Rust and see what happens.
Linux kernel is a real enough project for me!
As far as I'm concerned, Rust is better. It allows you to be much safer in the area of memory management errors. About 70% of security errors are related to memory management based on an MS study.
There are some Rust specific challenges since it is a variant of a linear type system. But programmers will eventually learn how to design for it instead of trying to work around it (i.e. cheat it).
Re: (Score:2)
Security problems have nothing to do with the language.
But with the programmer using said language.
Re: (Score:2)
Re: (Score:2)
Amazing how much wrong drivel comes out of your mouth.
Re: (Score:3)
Rust produces bloated slow binaries.
Our experience (Android OS) is that Rust binaries are slightly smaller and faster than C++ binaries doing equivalent work. It's possible that this is because the engineers who did the Rust rewrite understood the problem better and wrote more efficient code. But "second system effect" usually makes for slower programs, not faster ones, because the rewrite typically includes more features (which is true of the Android components that have been rewritten).
You can even compile Rust software on low to mid-range hardware because the compiler uses too much RAM and is too slow!
Sure, the compiler is slow, because (I suspect) of all
Re: (Score:2)
I dont see rust being ready for use until in part of GCC (13)
Funnily enough, I think it already is albeit using libgccjit. How complete that version is nor what the advantage or disadvantage over gcc-rust is, I don't know. Anyway there is quite a bit of work being done on it. Might take a year or two, but that's not a long time in a language space. Be really interesting to compare gcc-rust and LLVM also, in terms of compilation time, run time and error messages.