Linus Torvalds On Community, Rust and Linux's Longevity (thenewstack.io) 33
An anonymous reader writes: This week saw the annual check-in with Linux creator Linus Torvalds at the Open Source Summit North America, this year held in Seattle (as well as virtually). Torvalds took the stage for the event's traditional half-hour of questions from Dirk Hohndel, an early Linux contributor (now also the chief open source officer and vice president at VMware) in an afternoon keynote session.... And the theme of community seemed to keep coming up — notably about what that community has ultimately taught Linus Torvalds. (For example, while Torvalds said he'd originally planned on naming the operating system Freax, "I am eternally grateful for two other people for having more taste than I did.")
But even then Linux was a project that "I probably would've left behind," Torvalds remembered, "if it was only up to me." Torvalds credits the larger community for its interest (and patches) "that just kept the motivation going. And here we are 30 years later, and it's still what keeps the motivation going. Because as far as I'm concerned, it's been done for 29 of those 30 years, and every single feature ever since has been about things that other people needed or wanted or were interested in."
Torvalds also says "I'm very proud of the fact that there's actually a fair number of people still involved with the kernel that came in in 1991 — I mean, literally 30 years ago.... I think that's a testament to how good the community, on the whole, has been, and how much fun it's been."
And Torvalds says you can see that sense of fun in discussions about writing some Linux kernel modules using Rust. "From a technical angle, does that make sense?" Torvalds asked. "Who knows. That's not the point. The point is for a project to stay interesting — and to stay fun — you have to play with it....
"Probably next year, we'll start seeing some first intrepid modules being written in Rust, and maybe being integrated in the mainline kernel."
"I really love C," Torvalds said at one point. "I think C is a great language, and C is, to me, is really a way to control the hardware at a fairly low level..." Yet Torvalds also saw Hohndel's analogy that it can be like juggling chainsaws. As a long-time watcher of C, Torvalds knows that C's subtle type interactions "are not always logical" and "are pitfalls for pretty much anybody. And they're easy to overlook, and in the kernel that's not always a good thing." Torvalds called Rust "the first language I saw which looked like this might actually be a solution"
But even then Linux was a project that "I probably would've left behind," Torvalds remembered, "if it was only up to me." Torvalds credits the larger community for its interest (and patches) "that just kept the motivation going. And here we are 30 years later, and it's still what keeps the motivation going. Because as far as I'm concerned, it's been done for 29 of those 30 years, and every single feature ever since has been about things that other people needed or wanted or were interested in."
Torvalds also says "I'm very proud of the fact that there's actually a fair number of people still involved with the kernel that came in in 1991 — I mean, literally 30 years ago.... I think that's a testament to how good the community, on the whole, has been, and how much fun it's been."
And Torvalds says you can see that sense of fun in discussions about writing some Linux kernel modules using Rust. "From a technical angle, does that make sense?" Torvalds asked. "Who knows. That's not the point. The point is for a project to stay interesting — and to stay fun — you have to play with it....
"Probably next year, we'll start seeing some first intrepid modules being written in Rust, and maybe being integrated in the mainline kernel."
"I really love C," Torvalds said at one point. "I think C is a great language, and C is, to me, is really a way to control the hardware at a fairly low level..." Yet Torvalds also saw Hohndel's analogy that it can be like juggling chainsaws. As a long-time watcher of C, Torvalds knows that C's subtle type interactions "are not always logical" and "are pitfalls for pretty much anybody. And they're easy to overlook, and in the kernel that's not always a good thing." Torvalds called Rust "the first language I saw which looked like this might actually be a solution"
Scratch...ing an itch. (Score:1)
And Torvalds says you can see that sense of fun in discussions about writing some Linux kernel modules using Rust. "From a technical angle, does that make sense?" Torvalds asked. "Who knows. That's not the point. The point is for a project to stay interesting — and to stay fun — you have to play with it....
Start coding everything in Scratch. [mit.edu]
ok (Score:3)
"From a technical angle, does that make sense?" Torvalds asked. "Who knows. That's not the point. The point is for a project to stay interesting — and to stay fun — you have to play with it....
Hope he decides that it makes sense from a technical angle before he goes too far with it.
Rust will probably discredit itself (Score:4, Interesting)
As soon as it is used in a project with a really long perspective, its lack of a stable spec will become a severe defect.
Comment removed (Score:4, Insightful)
Re:Rust will probably discredit itself (Score:5, Insightful)
As it is, you might be surprised how difficult it is to compile many C programs right now that work under one version of GCC, but not the next.
C is my main language, so of course I know this isn't true at all. Once in a few years you might encounter code that needs a newer version of GCC than you have. That's rare even if you're using a stable longterm OS release.
But if something works on one version and not the next that usually means you have a bug in your Makefile.
Re: (Score:2)
Indeed. I have encountered that exactly once and it was a compiler bug in GCC. Have been using C for about 35 years now and GCC for 25.
Re: (Score:1)
The point is, we're just speculating about things to discredit either Rust's compiler or GCC.
Re: (Score:2)
You can expect serious third party attempts to build Rust compilers
I doubt it. The only way that would happen is if Rust becomes an ANSI, ECMA or ISO standard. And ironically Rust is only possible because the C++ standard is an ISO and so it was still economically viable to create Clang on top of LLVM.
Take a look at a language like Go. No one really uses GCC's implementation of Go, and it will always play catchup to Google's whims. Whether it's Perl, Python, or whatever single-vendor language, all of which are used in the real world, none of the competing implementation
Re: (Score:2)
More likely as soon as it's used in a project like that it'll have a stable spec.
That would be better. But I do not see that happening. We will find out.
Re: (Score:3)
Yes, they will essentially have a "Linux kernel dialect" if Rust folks cannot stabilize in time.
This happens with other languages all the time. Before C++99, G++ and Visual Studio had incompatible dialects. Before moving onto Swift, Apple more or less took over Objective-C++. Before "Hack", Facebook held one of the major implementation of PHP (HHVM).
If you are a big enough "client" of a language, you will get to steer its future.
Re:Rust will probably discredit itself (Score:4, Interesting)
Re: (Score:3)
I guess we will find out. I have a nagging suspicion that Linus is just giving the Rust people enough rope to hang themselves. Good strategy.
Re: (Score:2)
Re: (Score:3, Informative)
Why would you imagine his dislike of C++ is irrational?
Re: (Score:2)
Re: (Score:2, Insightful)
Because I've read all his criticisms and most of them are misguided.
They are not. The one "misguided" here is you.
Re: (Score:2)
No one claims C++ is a perfect language. But there's a lot of FUD about it, repeated by Linus sycophants, which doesn't take into account the compromises that C++ makes to bring higher level features to C.
Any fool can create a new language from scratch.
Re: (Score:2)
I think in an earlier post Linus had some thoughts that C would become like cobol with few knowledgeable people around to maintain it. So, the logical thing is to go as memory safe as possible and begin some Rust experiments. Seems sensible.
Re: (Score:2)
I think in an earlier post Linus had some thoughts that C would become like cobol with few knowledgeable people around to maintain it. So, the logical thing is to go as memory safe as possible and begin some Rust experiments. Seems sensible.
For TIOBE number 1? Not likely. COBOL is at position 28.
Re: (Score:3)
Linux does not have "irrational hatred" for C++. Anybody smart that actually looks closely at C++ and understands its design notices that it is a slapped-together heap of crap. I don't think he has any "hate" for C++ at all. Some things are just bad, but even those will have nil-whit defenders that think they are great. C++ is a nice example of that.
Re: (Score:2)
IMO:
Each feature was added because someone wanted and needed it, and, at least in recent times, convinced a committee that it was a good idea.
However, each feature, and its interactions with all the other features, made it a more difficult language to learn and to use well.
It may be true that modern C++ is more efficient, practical, safe, and easier to write, than say C++98.
But we do not only write code. We read it. And to read C++, especially if it was developed without strict coding standards th
Re: (Score:2)
But the FUD is overblown. Millions of C++ programmers handle the language just fine.
Re: (Score:2)
Delusional theory.
Re:Rust will probably discredit itself (Score:5, Informative)
Rust already has a forward compatibility mechanism, along with "editions" which mean breaking changes can be introduced in a managed way. Code from two different editions are still binary compatible, so a mass co-ordinated upgrade (python2->3!) is not needed.
So, I think what you have said, is already there, just in a managed way. Most people are, I think, of the latest edition (2018) but you can code against the older edition. And within the current edition, you can keep on the most recent release, or stay with older ones, or code against nightly.
In short, Rust's version and stability guarantees are quite nuanced. Who knows, perhaps they will be enough.
Re: (Score:2)
Not really. If Linux kernel does merge Rust support then you can bet there will also be a merger between the rust dev team and kernel devs, and Rust will acquire new functionality specifically to support kernel development. There is no way Linus will trust the future of kernel development to an arrangement that does not build in this guaranteed support.
Re: (Score:2)
Why would the Rust dev team merge with the Linux kernel team? It hasn't happened with either the gcc team or the clang team.
It also seems a little arrogant to suggest that the Rust developers would be happy to make their project subservient to another, even if it is Linux. Sure, if good functionality does arise from the Linux module application, it will get incorporated, but I doubt they'll compromise their design philosophy just to keep Linus Torvalds happy.
Re: (Score:2)
Compiling the Linux kernel correctly is a principal QA criteria for both GCC and Clang. GCC never merged with Linux kernel (although many of the principal developers of each worked under the same roof for many years) however the level of technical interaction is high, so the teams are effectively merged as much as any open source projects are. The same will happen with Rust, and Rust will benefit from it by being exposed to new requirements, new solutions, and some of the brightest minds in the industry.
Re: (Score:2)
If you on the other hand push Rust into the kernel to find weak spots in Rust and fix them, it would soon be too late to try.
Re: (Score:2)
What stable spec? There's API breaking changes in the kernel from time to time. Who the hell views Linux as a stable product?
There is nothing stable anymore in the software world.
Re: (Score:1)
Stable in terms of compiler ABI, not software API.
C works, but it isn't great for everything (Score:2)
I know Linus likes C, and it does seem to be just the job when you want to control hardware, without writing assembler. So compared to assembler, C is great. But when I try to write something that is not embedded stuff, but just general data processing, C is not so great.
Memory management using malloc() and free() is a pain. There are memory errors around every corner. You have to use void* for anything that might be variant types, which is fraught with danger. These things generally don't occur with embedd
He's done with Linux. (Score:1)
Then it would have been very interesting to hear what Torvalds has to say about using Rust in the kernel.
I mean, he already said it:
"that just kept the motivation going. And here we are 30 years later, and it's still what keeps the motivation going. Because as far as I'm concerned, it's been done for 29 of those 30 years, and every single feature ever since has been about things that other people needed or wanted or were interested in."
That is, he already did what he wanted, the way he wanted and as long as he wanted. It seems that with his goals achieved, he is more relaxed to accept some changes that 30 years ago would have been not even conceivable.