This author is very intelligent, well versed and wonderfully dry at the same time as being slightly amusing:
> For all of these references, I give a big "Thank You!!!" to my co-authors.
...
> This pointer is now a "zombie pointer" that has come back from the dead, or that has at least come to have a more entertaining form of invalidity.
...
> Furthermore, even given unanticipated universal acclamation of Rust within the Linux kernel community combined with equally unanticipated advances in C-to-Rust translation capabilities, a significant fraction of the existing tens of millions of lines of Linux-kernel C code will persist for some time to come.
and his parting words, not that he is negative or pessimistic about Rust but rather highlighting some unsolved challenges and their possible solutions:
> In short, choose wisely and be very careful what you wish for! ;-)
I’ve not used rust, and quite frankly I think a lot of the post is over my head, but I enjoyed the read nonetheless.
> I don't have any specific plans to turn this C proof-of-concept into a production-quality tool that would enable calling Rust from C, but if anyone wants to take it from here, I'd be happy to assist!
I laughed at this, I’d bet my bottom dollar it’s an attempted nerd snip!
> I personally cannot help but feel like the strong push for rust in the kernel is overstepping some sort of boundary.
Assuming you're not a kernel developer, I don't understand why you need the feel to be offended in their stead, as they don't really seem to mind at all.
> Zig, D, Ada
(i) not yet stable; (ii) torn apart between two runtimes, not really GC-free; (iii) has a... complicated toolchain story, and basically didn't exist in a free/libre aspect on PC until very recently – and didn't/doesn't compile on 90% of Linux targets.
> The only reason there is a push for Rust so much harder than anything else can only be explained by the community and their almost aggressive spirit of "if its not written in Rust, it should be".
No, the only reason there is a push for Rust in the kernel is because people are interested enough to write the code to get Rust in the kernel.
> it does rub me the wrong way and makes me stop and think a little bit when one particular language is held on such a gigantic pedestal.
Maybe you should stop and think a little bit on why kernel developers, arguably among the most competent ones on this subject, put Rust on what you perceive as a "gigantic pedestal".
> The problem with Rust GUI libraries is that Rust isn't really old enough to have mature ones yet.
Rust is between 14 and 18 years old now. Depending on who you ask. [0]
If anything that's a testimony to what bmitc wrote.
> Rust's ecosystem is also very sporadic. It seems everyone jumped on board in the gold rush (and still do), reinvent the wheel in some package to lay claim, and then abandon it when its 70% there once they get bored and/or realize rust doesn't magically solve programming.
> I think it is very cool that Rust has led to a renaissance of rewriting classic Unix tools to make them fit more with current use. Unix was never meant to stand still.
Technically it has not, even for the core tools they've been getting extended, usually incompatibly, in both GNU and BSD lineages. Though it's pretty funny how much the rust community has been taken up by providing alternatives and replacements for "classic" (POSIX) utilities.
> And most pertinently, this critique was written by someone who genuinely loves programming in Rust.
That is putting the bar impossible high. I would expect most of the criticism to come from people who hate to program in Rust, which it is fine as long as the criticism is well argued.
> I would like to see an example of a legitimate Linux Kernel module written in Rust that is in some form of use.
Seriously this.
I write an awful lot of kernel code. There's absolutely no way I'd try to convince folks to accept Rust code into the OS repository, where it will have to:
- Be maintained for decades
- Be ported to a litany of platforms, several of which may only have decent toolchains from the GCC department.
- Vend stable ABI
- Not require keeping a litany of compiler versions around just to keep older code building.
> with the amount of pro-Rust posts filling almost every discussion of C and C++ over the last 5 years or more, all over the web, the time that advocates spent arguing about why C users are ignorant and stubborn could have been spent contributing to a minimal kernel
Don't mistake a very small but very very vocal group of zealots for the Rust community at large
> the history of closures in Rust is a long and convoluted one, with many dead ends and failed experiments.
I desperately hope that someday, when all the dust settles, someone writes an account of this and other long and winding paths Rust has taken through its evolution, so people in the future can get the benefit of this wisdom. An account of dead ends could make for fascinating reading.
The trick would be putting in just the right amount of detail. Enough so the reader can truly understand the reasoning behind why things worked (or didn't) without being so dense as to be unreadable.
> We have the Rust Evangelism Strikeforce nudging us towards rewriting everything in Rust.
I really wish this would stop being repeated. At this point it's a meme that was rarely, if ever, actually accurate. People just repeat it because they've seen comments urging the use of Rust, and this leap is easy to make and justifies a bit more pushback.
It's not about "rewriting", it's about new projects. People are starting new projects that do the same thing as old ones all the time. What you actually see is a lot of Rust advocates trying to influence those people to use Rust instead of C or C++, so instead of yet another library implementation in C or C++, we have one in Rust.
If it's better than the prior implementation, it might be used. This part has nothing to do with language, and better implementations come along all the time and are adopted to some degree. For example, Nginx. I remember the days when your choice for an open source webserver that could scale was basically Apache (there were a few others, but generally weren't used for serious sites).
Misrepresenting this cycle is just spreading FUD that activates a constituency to circle wagons. It's not helping anyone (as we're seeing from both sides of the political spectrum, which have gone all-in on this tactic lately).
> I find it funny and think it's pretty telling that there are bold claims made that are only crossed out after the author is corrected
... What else would you expect? The author observed something, drew a mistaken conclusion, wrote it up, and then had the mistake pointed out, and so retracted. I can't imagine the author realised their claims were wrong before it was pointed out, so of course they're only going to cross them out after being corrected. Of course, it's rather unfortunate that an incorrect write-up is being upvoted to the top of HN but that's not the author's problem (other than the choice of the rather clickbaity title...).
For the specifics of this post, there's some subtle differences between how Rust and C++ behave that could easily explain how the author observed differing behaviour and thus jumped to the conclusion, as explored on /r/rust: https://www.reddit.com/r/rust/comments/63ijkw/rust_optimizat...
> For all of these references, I give a big "Thank You!!!" to my co-authors.
...
> This pointer is now a "zombie pointer" that has come back from the dead, or that has at least come to have a more entertaining form of invalidity.
...
> Furthermore, even given unanticipated universal acclamation of Rust within the Linux kernel community combined with equally unanticipated advances in C-to-Rust translation capabilities, a significant fraction of the existing tens of millions of lines of Linux-kernel C code will persist for some time to come.
and his parting words, not that he is negative or pessimistic about Rust but rather highlighting some unsolved challenges and their possible solutions:
> In short, choose wisely and be very careful what you wish for! ;-)
reply