News and Advice on the World's Latest Innovations:
The Rust in Linux debate is over. The implementation has begun. In an email conversation, Linux's creator Linus Torvalds, told me, "Unless something odd happens, it [Rust] will make it into 6.1."
The Rust programming language entering the Linux kernel has been coming for some time. At the 2020 Linux Plumbers Conference, developers started considering using the Rust language for new Linux inline code. Google, which supports Rust for developing Android -- itself a Linux distro -- began pushing for Rust in the Linux kernel in April 2021.
As Wedson Almeida Filho of Google's Android Team said at the time, "We feel that Rust is now ready to join C as a practical language for implementing the kernel. It can help us reduce the number of potential bugs and security vulnerabilities in privileged code while playing nicely with the core kernel and preserving its performance characteristics."
It took a while to convince the top Linux kernel developers of this. There were concerns about non-standard Rust extensions being needed to get it to work in Linux. For instance, with the new Rust Linux NVMe driver, over 70 extensions needed to be made to Rust to get it working. But, Torvalds had told me in an earlier interview, "We've been using exceptions to standard C for decades."
This was still an issue at the invitation-only Linux Kernel Maintainers Summit. But, in the end, it was decided that Rust is well enough supported in the Clang -- the C language family compiler front end -- to move forward. Besides, as Torvalds had said earlier, "Clang does work, so merging Rust would probably help and not hurt the kernel."
[...] Now, Torvalds warns in this first release, Rust will "just have the core infrastructure (i.e. no serious use case yet)." But, still, this is a major first step for Rust and Linux.
Related Stories
Arthur T Knackerbracket has processed the following story:
Mark Russinovich, the chief technology office (CTO) of Microsoft Azure, says developers should avoid using C or C++ programming languages in new projects and instead use Rust because of security and reliability concerns.
Rust, which hit version 1.0 in 2020 and was born at Mozilla, is now being used within the Android Open Source Project (AOSP), at Meta, at Amazon Web Services, at Microsoft for parts of Windows and Azure, in the Linux kernel, and in many other places.
Engineers value its "memory safety guarantees", which reduce the need to manually manage a program's memory and, in turn, cut the risk of memory-related security flaws burdening big projects written in "memory unsafe" C or C++, which includes Chrome, Android, the Linux kernel, and Windows.
Microsoft drove home this point in 2019 after revealing 70% of its patches in the past 12 years were fixes for memory safety bugs due largely to Windows being written mostly in C and C++. Google's Chrome team weighed in with its own findings in 2020, revealing that 70% of all serious security bugs in the Chrome codebase were memory management and safety bugs. It's written mostly in C++.
"Unless something odd happens, it [Rust] will make it into 6.1," wrote Torvalds, seemingly ending a long-running debate over Rust becoming a second language to C for the Linux kernel.
A long-standing coding choice has seen an unexpected rise in popularity, according to one tracker of programming languages:
Software-testing firm Tiobe, which maintains a monthly tracker of the popularity of the vast array of programming languages available to software developers, has picked C++ as its programming language of 2022.
Despite it being placed third in Tiobe's January 2023 index, the popularity of C++ rose faster than all other languages last year, up by 4.26% compared with January 2022, the company said.
Runners-up this year were C, the second most popular language, which grew in popularity by 3.82%, and Python, the top language, which grew by 2.78%. Having fallen from third, Java is now in fourth place, growing 1.55%.
[...] [Tiobe CEO Paul] Jensen also notes that C++ rival Rust entered the top 20 again (being ranked at number 26 one year ago), but says that "this time it seems to be for real", suggesting it could now hold a stable position in the top 20.
Rust's profile shot up during the past year after it was officially adopted for the Linux kernel version 6.1, clearing its way for drivers to be written in Rust.
Previously:
Ironically: It's Time to Stop Using C and C++ for New Projects, Says Microsoft Azure CTO
Why Rust is becoming the programming language of choice for many high-level developers:
Rust is revolutionizing high-performance Web service development with its memory safety, resource management, and speed. Initially used in operating systems and gaming engines, Rust now excels in web development, offering low-level control and high-level concurrency. Its advanced ownership model and robust type system eliminate memory errors at compile time, enhancing performance and reliability.
[...] Rust's popularity in the software development community continues to rise, with even the likes of Linus Torvalds giving the language his blessing, and announcing driver integration for major subsystems sometime in 2024.
So, it's clear Rust is 'one of the big boys' by now, but why exactly is it one of the most popular programming languages? Well, it's down to:
- Memory safety without garbage collection
- [...] Thread safety
- [...] Performance
- [...] Syntax innovations
- [...] Tooling and ecosystem
These capabilities make Rust a popular option for enterprise-level applications, providing sufficient speeds to execute processes like Workday staff augmentation, customizing existing ERP software, and other demanding backend tasks.
The article goes on to describe specific features that make Rust popular and also discusses the key challenges to Rust adoption, namely learning curve and complexity.
Previously:
- Microsoft Adopts Rust to Boost Windows Security and Performance
- How Rust Went From a Side Project to Currently the World's Most Popular Language
- Linus Torvalds: Rust Will Go Into Linux 6.1
- Memory Safe Programming Languages are on the Rise
(Score: 4, Insightful) by bzipitidoo on Tuesday September 20 2022, @06:57AM (17 children)
It always seemed strange that the Linux kernel development stuck to C and wouldn't even use C++. It is evidently extremely hard to migrate a tool chain even the relatively small distance from C to C++. But then perhaps C++'s function name mangling, to support templates and all, made it a non-starter for kernels.
Very impressive that another language has finally made it to this point. Sure hope this move can make libraries more portable.
(Score: 5, Insightful) by canopic jug on Tuesday September 20 2022, @07:26AM (2 children)
Very impressive that another language has finally made it to this point. Sure hope this move can make libraries more portable.
Culling and refactoring is needed more. Lately the kernel seems to be write-only and growing (bloating) by the hour. If that keeps up then it will eventually cross a threshold where it is too full of holes to deal with any more. Adding multiple languages to the mix just adds to that trouble and to the security-destroying problem of complexity [schneier.com]. There are also the social and legal problems that an additional language will bring with it. Those last two rather over lap.
There are many definitions of an open standardsd but there is a substantial amount of common aspects. Perhaps the primary shared characteristics of open standard definitions are as follows, with the key point here being about the maintenance:
If I understand correctly, at least C is an open standard. It is maintained by a not-for-profit organization with the ongoing development occuring on the basis of an open decision-making procedure. Specifically the American National Standards Institute (ANSI), ISO/IEC JTC 1/SC 22/WG 14 of the International Organization for Standardization (ISO), and the International Electrotechnical Commission (IEC) handle C.
There are a still a lot of questions about how Rust is maintained [rust-lang.org], especially since it is all on M$ GitHub at the moment. That is in spite of the sale itself and what M$ has been doing to GitHub since the sale. And given the fights over the CoC [rust-lang.org] and its subsequent abuse, further questions are raised about control, specifically, not just governance.
Money is not free speech. Elections should not be auctions.
(Score: 2) by janrinok on Tuesday September 20 2022, @07:34AM (1 child)
It is unfortunate that the link to the roadmap that you provided doesn't seem to have been updated since 2021. I hope this doesn't indicate the way things are going...
I am not interested in knowing who people are or where they live. My interest starts and stops at our servers.
(Score: 2) by coolgopher on Tuesday September 20 2022, @12:00PM
Embrace, Extend...
(Score: 3, Interesting) by janrinok on Tuesday September 20 2022, @07:29AM
It might also increase interest in Rust - I know that it was TMB's interest just before he left us. He used it to write several utilities for his own personal use and was keen to have it on his CV.
I am not interested in knowing who people are or where they live. My interest starts and stops at our servers.
(Score: 5, Informative) by RamiK on Tuesday September 20 2022, @07:44AM (5 children)
( https://itwire.com/business-it-news/open-source/rust-support-in-linux-may-be-possible-by-5-14-release-torvalds.html [itwire.com] )
compiling...
(Score: 3, Insightful) by PiMuNu on Tuesday September 20 2022, @05:23PM (4 children)
I don't know if I agree with all that stuff - but as someone who has coded in C++ for 20 odd years I think it is a bloated piece of ****.
(Score: 2) by RamiK on Tuesday September 20 2022, @06:58PM (3 children)
Bear in mind Torvalds wrote Subsurface in C++ and continues to contribute and use it so he's just as much of a "there's a C++ library for that" victim as the rest of us.
compiling...
(Score: 3, Informative) by PiMuNu on Wednesday September 21 2022, @11:47AM (2 children)
It's not the libraries, it's the sheer volume of keywords and cr*p in the core language. Just look at any style guide for a list of anti-features that are not to be used.
* Implicitly defined initialisers
* Different syntax for constructors with no arguments and constructors with arguments? WTF?
* Template syntax altogether is a nightmare
* and so on
(Score: 2) by RamiK on Wednesday September 21 2022, @01:02PM (1 child)
I meant that despite everything about C++ itself being crap, we're all victims of our dependence on existing C++ libraries and end up using it or stuff made in C++ regardless. e.g. the browser I'm typing in right now...
compiling...
(Score: 2) by PiMuNu on Wednesday September 21 2022, @04:53PM
Understood - and agreed...
(Score: 5, Interesting) by Rich on Tuesday September 20 2022, @09:44AM (1 child)
It's a relatively small distance from C++ to C (by adding 'extern "C"'), but it's near insurmountable the other way round. The only way to reliably deal with the entanglement of forwarding exceptions and handling pending destructors is the runtime of a matured C++ compiler. Then there's the issue of C++ not even guaranteeing where something is in memory (read up on when the "offsetof" operator is permitted). Finally, the way templates work leads to bloat you don't want to have in any code that needs to live in small caches for best performance.
To get clean interaction, you'd have to expose the inner workings of the C++ runtime in C. A massive upgrade to C's setjmp/longjmp for exceptions, including language support for what needs to be "volatile" in that context. For compact code suitable for a kernel, a completely rewritten C++ template library with a single code backend and just templates for type safety sugar on top would be the least. Either will get you a shitstorm from the respective camp for simply mentioning it.
(Score: 0) by Anonymous Coward on Wednesday September 21 2022, @05:03PM
Utter nonsense.
(Score: 2) by choose another one on Wednesday September 21 2022, @12:49PM (3 children)
Um, as I recall Linux (kernel) development _did_ use C++, back in the early days (just checked - yep 1992).
The intention of the switch, as I recall, was to benefit from C++ features like stronger type-checking. It failed - mainly, I suspect, because C++ support in gcc/g++ at the time was a crapshoot in a bug-fest. Even in late '90s I personally found it quite a shock to move to the MS/Windows world (for work/gotta-make-a-living reasons) and find that actually pretty much all the "that would be really neat if it worked" stuff in C++ that I was having to kludge around in Linux land, actually _did_ work properly in Visual C++. FOSS compilers remained well behind until gcc/ecgs merge sometime around turn-of-the-century.
There were other more fundamental issues outside of that though, things that would have to be avoided because would not play nicely with the rest of the in-C-kernel - e.g. memory management, exceptions. Later in the '90s embedded folks developed embedded subsets of C++ for pretty much the same reasons.
Fast forward 20 years and C++ would be a non-starter I think, simply because of the sheer amount of code that would have to be converted or made at least C++ aware - you can put some C code inside C++ (C libraries are used all the time) and the problems from doing that are known and can be managed (it's what C++ was designed to do) but using some C++ inside C code framework will all go horribly wrong (exceptions, memory management etc). I can easily see that it might be far less work to allow another completely different language to be used in places - C++ is just too close to the internals of C.
(Score: 3, Interesting) by bzipitidoo on Wednesday September 21 2022, @02:30PM (2 children)
C++ in the kernel that long ago? Didn't know that!
> FOSS compilers remained well behind
Did you ever use the Borland C++ compiler? Way more broken than g++. One of Borland C++'s worst bugs was its inability to correctly use more than 64k data in the x86 segmented memory model. As long as you kept to piddly little beginning CS assignments, you were okay, but try to work with more than 64k of data, watch out. Had that problem up through version 4.5, and as I recall it still wasn't fixed in 5.x. That was what pushed me to FOSS.
> There were other more fundamental issues
Yeah, compiler issues shouldn't be reason to trash a language, unless the language is the cause of those issues.
I find C++ basically a gateway drug. Every time I've started a project in C, I find myself wishing I could use this and that convenience that works in C++, and end up switching. At first, the code is just C with structures renamed to classes because it's a whole lot easier to point to functions that way. No inheritance, no polymorphism, no templates, and no operator overloading. Still use stdio.h, because everyone knows that iostream has worse performance. (A curious thing about that is that iostream's performance is worse because it defaults to support of stdio. Turn that legacy support off, and ...) But then, you start wishing for such things as the nicer string handling of the STL, and associative arrays and such like, and so, those features, especially templates, creep in. Or at that point, you switch to a language that has native support for that stuff. Depends on several factors, with performance being a big one. I wrote a simple byte value counter in Perl 6 (now called Raku), turned the program loose on a 100M file, and it took 20 minutes. The same program in C took 2 seconds. We're further than ever from One Language To Rule Them All.
(Score: 0) by Anonymous Coward on Wednesday September 21 2022, @06:55PM (1 child)
Have you tried perl5?
#!/usr/bin/perl -w
use strict;
my $path=shift||'';
my $fh;
die "unable to open: $path: $!" unless open($fh,"<$path");
my $buf='';
my $bufsize=131072;
my $total=0;
while ( my $read = sysread($fh , $buf , $bufsize) )
{
$total+= $read;
}
print "$total\n";
time ./t.pl test.bin
100000000
real 0m0.009s
user 0m0.004s
sys 0m0.004s
And this is on a Linux VM running in virtualbox on a Windows 10 ryzen PC.
(Score: 2) by bzipitidoo on Wednesday September 21 2022, @11:49PM
The computer I tested it on had a HDD, not a SSD.
Here's the Perl6 code I banged out:
# histogram of bytes in a file.
use v6;
my @c;
my $i = 0;
loop ($i=255; $i>=0; $i--) {
@c[$i]=0;
}
my $count=0;
while defined $_ = $*IN.getc {
$count++;
$i = ord($_);
if ($i>255) { $i=255; }
@c[$i]++;
}
$i=0;
for @c {
print sprintf("%c %7d ",$i,$_);
$i++;
if ($i%8 == 0) { say ""; }
}
(Score: 0) by Anonymous Coward on Wednesday September 21 2022, @05:00PM
Um, what? name mangling wouldn't affect existing code.