Linus Torvalds Says Rust Closer for Linux Kernel Development, Calls C++ 'A Crap Language' (itwire.com) 270
Google's Android team supports Rust for developing the Android operating system. Now they're also helping evaluate Rust for Linux kernel development. Their hopes, among other things, are that "New code written in Rust has a reduced risk of memory safety bugs, data races and logic bugs overall," that "abstractions that are easier to reason about," and "More people get involved overall in developing the kernel, thanks to the usage of a modern language."
Linus Torvalds responded in a new interview with IT Wire (shared by Slashdot reader juul_advocate): The first patches for Rust support in the Linux kernel have been posted and the man behind the kernel says the fact that these are being discussed is much more important than a long post by Google about the language. Linus Torvalds told iTWire in response to queries that Rust support was "not there yet", adding that things were "getting to the point where maybe it might be mergeable for 5.14 or something like that..." Torvalds said that it was still early days for Rust support, "but at least it's in a 'this kind of works, there's an example, we can build on it'."
Asked about a suggestion by a commenter on the Linux Weekly News website, who said, during a discussion on the Google post, "The solution here is simple: just use C++ instead of Rust", Torvalds could not restrain himself from chortling. "LOL," was his response. "C++ solves _none_ of the C issues, and only makes things worse. It really is a crap language.
"For people who don't like C, go to a language that actually offers you something worthwhile. Like languages with memory safety and [which] can avoid some of the dangers of C, or languages that have internal GC [garbage collection] support and make memory management easier. C++ solves all the wrong problems, and anybody who says 'rewrite the kernel in C++' is too ignorant to even know that."
He said that when one spoke of the dangers of C, one was also speaking about part of what made C so powerful, "and allows you to implement all those low-level things efficiently".
Torvalds added that, while garbage collection is "a very good thing in most other situations," it's "generally not necessarily something you can do in a low-level system programming."
Linus Torvalds responded in a new interview with IT Wire (shared by Slashdot reader juul_advocate): The first patches for Rust support in the Linux kernel have been posted and the man behind the kernel says the fact that these are being discussed is much more important than a long post by Google about the language. Linus Torvalds told iTWire in response to queries that Rust support was "not there yet", adding that things were "getting to the point where maybe it might be mergeable for 5.14 or something like that..." Torvalds said that it was still early days for Rust support, "but at least it's in a 'this kind of works, there's an example, we can build on it'."
Asked about a suggestion by a commenter on the Linux Weekly News website, who said, during a discussion on the Google post, "The solution here is simple: just use C++ instead of Rust", Torvalds could not restrain himself from chortling. "LOL," was his response. "C++ solves _none_ of the C issues, and only makes things worse. It really is a crap language.
"For people who don't like C, go to a language that actually offers you something worthwhile. Like languages with memory safety and [which] can avoid some of the dangers of C, or languages that have internal GC [garbage collection] support and make memory management easier. C++ solves all the wrong problems, and anybody who says 'rewrite the kernel in C++' is too ignorant to even know that."
He said that when one spoke of the dangers of C, one was also speaking about part of what made C so powerful, "and allows you to implement all those low-level things efficiently".
Torvalds added that, while garbage collection is "a very good thing in most other situations," it's "generally not necessarily something you can do in a low-level system programming."
Spot on... (Score:5, Insightful)
"C++ solves _none_ of the C issues, and only makes things worse. It really is a crap language"
Linus is truly a treasure for succinctly sum things up. I would have left of the "crap language" because that will trigger the faithful.
Re: (Score:3)
Lol. This is going to be a fun comment section. You and Linus are both spot on though.
Re:Spot on... (Score:5, Funny)
When the area around Boston was first settled in the 1600s, the cows wore paths between the barn and their pastures. Later, the paths were widened to accommodate horse-drawn carts. As the town expanded, houses were built alongside the paths, and they became roads. Later, buildings were erected in the spaces between the roads.
So if you ever wonder why Boston's streets make no sense, it is because that is where cows walked 400 years ago.
C++ was designed the same way.
Rust has the advantage of a fresh start.
Re: (Score:2)
Sure but the problem with eschewing C++ for C is you're choosing 400 year old muddy cow paths over the paved roads in their place. Sure you could make a better layout in the future, but that doesn't make paved roads a lot better than mud tracks.
Re:Spot on... (Score:4, Insightful)
Those who don't understand C++ are condemned to reinvent it (poorly)
Re:Spot on... (Score:5, Interesting)
I don't think anyone could, should or would reinvent C++. It's a language that requires a special section in compiler courses. Good compiler courses have special sections entitled "this is what makes COBOL special" and "this is what makes C++ special". The section on COBOLs flaws is usually much shorter than C++'s flaws.
The design by committee approach to C++ pretty much guarantees no one wants to duplicate it, and no one can. A new C++ compiler is the work of a fairly significant development team.
These simple questions can be really tough to answer in C++:
a) Does this const pointer to const point to an immutable object (possibly in ROM?) or must it be in RAM?
b) Is function "x" re-entrant (can it be optimized to non re-entrant code)?
c) Does function "x" execute?
d) Will this line of code trigger a dynamic memory allocation?
On some architectures, particularly in the embedded world, being able to answer the above questions results in significant optimizations. In particular, determining if a const variable is actually immutable results in speed-ups. Similarly, if a linker can omit all functions that do not execute, significant file size optimizations can occur. Many real-time systems require no new memory allocations in critical blocks of code.
C++ is a very hard language, to understand, to use, to optimize, and to write compilers for.
If this is true, software engineering is doomed ...
Re:Spot on... (Score:4, Interesting)
The design by committee approach to C++
C++ has never been designed by committee. The committee is there purely for the standardization process.
a) Does this const pointer to const point to an immutable object (possibly in ROM?) or must it be in RAM?
b) Is function "x" re-entrant (can it be optimized to non re-entrant code)?
c) Does function "x" execute?
d) Will this line of code trigger a dynamic memory allocation?
Tell me one language that can answer that. For example, d). Let's say I have a line of code in C which is "do_this_thing()". Pray tell - what part of the C language can tell me whether do_this_thing() will trigger memory allocation?
In C, if a function is not declared static and is not used, any LINKER (or static analyzer) that can tell you a function is used will also be able to do the same for C++. And that's just for checking if a function is used. Whether something executes is yet an extra thing on top. Tell me what holy grail of a language can tell me whether function 'x' executes? If, in Rust, you pass a function as a callback to some other thing, how can you prove that callback will or won't be called?
C++ can be safe-ish (Score:3)
If you follow about 200 rules that nobody follows.
But when I am forced to use it, I would love to have a compiler warning that says "Set dangerous mode off". So when I write
output("The answer is " + x);
I do not get a weird memory error if x is an int, vs if x is a string.
Likewise taking the address of a local variable and other cute tricks.
References almost work well in C++, except that they don't. As a coding style they can be used for safe references, with pointers used for unsafe, but nobody does tha
Re:Spot on... (Score:5, Interesting)
If this is true, software engineering is doomed ...
Computer scientists love to hate C++, but there's one tiny problem, it's hugely successful for a variety of really good reasons. Failing to understand something which has proven successful and long lasting is almost certainly a recipe for failure.
Sometimes it's funny, like when Rob Pike made Go as a C++ replacement and C++ programmers largely ignored it because it wasn't very good and then wrote a whiny rant about how C++ programmers hated it because it was too awesome and they're all poopy-heads.
The only reason Rust is making any headway is because the designers actually new and understood C++ very well, and aimed to solve the actual problems C++ has, not the "lol teh C++ si teh sux000rZ" pseudo-problems from the peanut gallery.
Re: (Score:2)
This.
While Rust looks nice, there are other languages that have reinvented C++ before, like Java.
Basically the longer a language exists, the more C++'isms find their way into the core language before the language gets abandoned for something easier to maintain and understand. PHP, Python and Javascript are having this problem in spades.
Re: (Score:2)
It's not hard to re-invent a crappy language into a new crappy language.
If a language is hard to fully understand then maybe you shouldn't use it. That's why C still around - it's not that hard to understand while it's also offering some good performance.
For C++ it has inherited all the bad things from C as well as all the bad things from object oriented paradigms. The bastard puppy of a chihuahua and a great dane.
The biggest problem with C is the null terminated strings which is one of the core culprits in
Re:Spot on... (Score:4, Insightful)
Those who don't understand C++
So, pretty much everyone? :)
(As of C++20, I think the language has reached quantum-mechanics levels of nuance, so "if you think you understand how it works, that's a clear indication that you don't")
Re: (Score:3, Insightful)
Re: (Score:2)
Sure but the problem with eschewing C++ for C is you're choosing 400 year old muddy cow paths over the paved roads in their place.
I wasn't comparing C++ to C.
I was comparing C++ to Rust.
Give it time (Score:5, Insightful)
Rust has the advantage of a fresh start.
Just wait. Given enough time it will accumulate problems as it gets expanded to accommodate new programming techniques. Today's "fresh start" is tomorrow's "crap language".
Re: (Score:3)
Re: (Score:3)
No, I have no problem in the Boston area.
Now cities like New York and DC, I get lost all the time. Those grid patterns confuse me and takes much longer to get to where you are going. In Boston, you just point your car to where you want to go and drive, no need to do constant annoying right and left turns
Re: (Score:2)
Re:Spot on... (Score:4, Informative)
Or just Crap++.
For example, Boost's crc [boost.org] is a bloated 2,305 Lines of Code just to implement a CRC that could be written in a mere ~25 lines of C code.
Because the last time you actually needed to parameterize CRC to have CRC64 was NEVER. If you need stronger hashing you'll be using FNV or SHA variants. But's let use Template Metaprogramming to solve a "solution" in search of a problem. /s
While C++ has it share of problems, (cue that old C++ joke: C++ has 2 problems: 1. Its design, and 2. Its implementation), the bigger problem is people writing shit code by overengineering the simplest of problems [youtube.com] because they are busing drinking the OOP Kool-Aid (TM).
Re: (Score:2)
Re: (Score:2)
Re:Spot on... (Score:5, Insightful)
People don't use 64-bit CRC, but they do use 8- and 12- and 16- and 24-bit CRCs. They use CRCs with different initial shift register values, and that differ in whether you shift bits from the MSB or LSB of the next byte into the CRC register (big- or little-endian bytes).
The C++ code in Boost gets you support for all those variants plus more, efficiently implemented at runtime. Your 25 lines of C don't even get you an efficient, portable implementation, unless (and this would push the 25 line bound) you force the application to call an initialization function.
Re: (Score:2)
I'll bet the average developer could still easily beat 2305 LOC.
Re:Spot on... (Score:5, Informative)
I bet you're wrong. According to sloccount, there are 816 lines of compiled code in boost's crc.hpp, out of 2307 total lines on my system -- most of the rest are comments, some are blanks.
The features to implement are:
As additional coding-style constraints, curly brackets must be on their own line. So must the return type, "inline" modifier, and parentheses around parameter lists for functions defined at file scope. Lines must be less than 80 characters long.
Re: (Score:3)
It seems so silly. I'm hearing two sides, only one of which is defensible. You say, "look at the greatness of my bloated monstrosity! Look how general it is! See all of the great features!" Everyone else is saying "Dude, just use a 10 line function specific to your application. It'll be smaller and faster."
Are you the author or something? Why do you care so much about this?
Re: (Score:3, Insightful)
C++ is crap for system/embedded programming because all the useful stuff that makes it easy and readable in C has been deprecated, mostly because it was deemed too dangerous.
C++ is crap for application programming because the benefits over much easier, better designed languages are non-existent most of time. Yeah, it's a bit faster in some cases, but it usually doesn't make any meaningful difference.
Whenever you come across something written in C++ you get this feeling of dread because you know that it's al
Re:Spot on... (Score:4)
Some of the best crap I've written has been in C++.
Re:Spot on... (Score:4, Insightful)
A good programmer writes good code in every language, a poor programmer writes bad code in all of them.
Re: (Score:2)
Very little has been deprecated in C++. It's very good for embedded systems, you get the control you need from the C heritage, combined with much more powerful options for automation.
As for bad code... It's not like there isn't a metric ton of terrible C code out there. Blaming C++ for bad code is like blaming a table saw for cutting off someone's arm.
Re: (Score:2)
l stuff that makes it easy and readable in C has been deprecated
Like what? The last 2 embedded projects I worked on were C++. For embedded purposes, it is basically C with better type checking.
Re: (Score:3)
Re: (Score:3)
I think it's unfortunate that so many people's experience with OOP is C++. It's an awful OOP system, in all the same ways that C++ is awful. Java makes things a bit more sane, but also makes it mandatory, which is also bad.
Re: Spot on... (Score:2)
I'm sure implementing a template for a generalized CRC algorithm is fun and very satisfying. But so very unnecessary, like most of the output of C++ developers.
Re:Spot on... (Score:5, Insightful)
There is a class of programmer that "clicks" with the OOP concepts of inversion of control, dependency injection, and always coding to an interface. This approach feels so correct to them that they become almost religious in their devotion to it. They believe it is the one-size-fits-all solution to every programming problem, and consider anyone who disagrees with them to simply be less intelligent than themselves (because no rational person could possibly disagree).
I have worked with such people. They quadruple the codebase, significantly increase development time, and introduce more bugs by doing so, all the while insisting that this will make the code easier to maintain in the long run. But it actually doesn't; it just means that there is that much more code that must be refactored as new features come along.
They point at the ease with which layers can now be swapped-out as a total win. But in practice 90% of the interfaces have only one implementation. There is nothing to switch anything to because there just isn't any need. And future development isn't simplified by finding just the right layer to adjust; the changes are almost always cross-cutting so you have to refactor all those interfaces and layers top-to-bottom, each time, to get things working.
It just doesn't work out in practice the way they insist it will. At least, not often.
The last major benefit they harp on is the ability to test in isolation and use mock objects to keep the test cases simple. That's great if you want to have a lot of automated tests that pass in mocked-out unreal environments, but not so great if you want to actually find the bugs that come out once the code encounters the real world.
There probably are specific kinds of project that benefit from this approach. But there are many, many more that suffer rather than benefit from it. All the versatility that the code buys you just doesn't deliver value, and all the layers it costs you just get in the way.
Re:Spot on... (Score:5, Interesting)
The nice thing about C and C++ is that if done right, it works, works well, with very few dependencies. If I wanted to write some utility that I would be confident would run on any Linux variant, I could just static link the output, and even though the binary would be bigger, it would run regardless of the state of the machine, provided a basic kernel and userland was present. Although the only real binary I statically link these days winds up being busybox, bash, and rsync (For Synology machines because the included rsync binary is half broken.)
I wonder how Rust compares for writing something similar, like a shell, or other executable, especially if statically linked to ensure as few dependencies on the box as possible.
Re:Spot on... (Score:5, Interesting)
I'm a long-time C++ programmer, but I don't exactly get "triggered" by whatever Linux says about C++. We've all long known he has a bug up his ass about C++, after all. I disagree that it's a "crap" language, but anyone who has worked with it can easily see it has a huge number of flaws. Ironically, many of those flaws are there because C++ strives to remain mostly compatible with C and legacy C++ code, which makes it easy to do the wrong thing even if there are more modern ways of solving common problems. But that long-term stability and backwards compatibility are both a strength and a weakness, of course.
It's easy to forget how ridiculously old the language is. Why replace one ancient language with another not-quite-as-ancient language? Sure, in C++ if you only use modern features and techniques, you can get much closer to memory safety (certainly much better than C), but never all the way there. It's essentially opt-in memory safety.
Rust, in contrast, forces you to specifically opt-out of memory safety, which ensures you only do it when absolutely necessary, ensuring a smaller footprint of unsafe code to review. It makes more sense, if you're going to switch languages, to use a more modern language that definitely solves memory safety, which some surveys have shown accounts for roughly 70% of security bugs.
The argument of "just don't make mistakes" or "use better libraries" are just not realistic. All humans make mistakes, and C has serious limitations as a language that still force the onus of safety on the programmer instead of the compiler.
Re:Spot on... (Score:4, Insightful)
Hands down the biggest weakness of C++ is also its strength. Using C as a guideline, it can do whatever it wants. And what it wants to do is everything.
If you code your C++ as "C with classes", that's great. If you hire a bunch of men who do the same, also great.
If you learned to think in pure OO space and you code that way, that's great. Again, if you hire a bunch of men who do the same, also great.
But put these guys on the same team and you have guys who have a C-with-extra-stuff language versus people with a completely different paradigm. The second group has more academic stuff to point to, the first group has a metastable nonstandard that everyone agreed with at first glance and it evolved unpredictably over time.
Some languages are too small to support this kind of thing. Others are too new, even though the language could go in that direction. But C++ is a whole host of programming styles.
Oh, and it gets worse, because as you include different libraries written in different ways (especially C libraries side by side with stuff like boost), you are including those libraries for their functionality and performance. The code you wrap those in will look even stranger.
I think someone should write "style guides" for the different types of C++ programming. The "C-with-classes" guys in particular need something written down, as they are, in my experience, the least able to make a coherent point defending their coding style.
Re: (Score:2)
No C++ is crap.
I used to write C++ until about 2001. Then I switched to C# and Java and now only Java. Ok do some Python, and Javascript, but I digress. Around 2005 or 2008? I decided to write some C++ code and there was this really weird bug. Namely I was returning a value and it would keep erasing itself and causing a GPF. I thought, did I declare the return value in the function stack? I looked and looked and could not figure it out. Well I did figure it out several days later.
Apparently between the time
Re:Spot on... (Score:5, Interesting)
> I disagree that it's a "crap" language, but anyone who has worked with it can easily see it has a huge number of flaws.
Hence, CRAP++
* iostreams is still a complete clusterfuck of bad performance and bad design [youtu.be] /s
* cout formatting is shit for performance and verbosity. Thankfully we have libs like fmtlib [github.com]
* hash maps performance [ankerl.com] is shit [github.io]. Thankfully we have abseil [abseil.io], parallel hash map [github.com], ska hash maps [probablydance.com], etc.
* modules might finally becoming. Welcome to the 1970's.
* When even a C++ committee member admits he writes in a sub-set of C++ himself [youtu.be] then the language itself is bloated.
* no standardized name mangling
* no standardized way to force inline
* no standardized way to specify function temperature
* no standardized error/warrning output diagnostic messages ala MS's Visual C++'s Compiler, Linker, etc. [microsoft.com] such as C#### Compile Errors [microsoft.com], and Compiler Warnings [microsoft.com]
* no standardized way to turn specific warnings on/off because the C++ committee has their head up their ass
* no standardized way to specify alignment
* no standardized way to turn off RTTI
* no standardized way to turn off exceptions
* no standardized way to specify LTO / PGO
* Non-standard extensions like __FUNCTION__ exist because no one in committee is interested in pragmatic solution such as standardizing COMMON solutions.
* etc.
> many of those flaws are there because C++ strives to remain mostly compatible with C and legacy C++ code
BULLSHIT.
* Performance, and
* Functionality
Have _nothing_ to do with C compatibility.
> The argument of "just don't make mistakes" or "use better libraries" are just not realistic.
As opposed to what? Use the shitty C++ default libs?
If your code is crashing then you didn't TEST it adequately enough.
Re:Spot on... (Score:5, Insightful)
I wish people wouldn't mod you down for this. People these days can't handle a bit of spirited debate.
While I disagree with your opinion / conclusions about C++, everything you listed is a genuine pain point in C++, which at least demonstrates you know the language well enough to legitimately bitch about it. Some are genuine language issues, while others are because C++ only defines a language standard, and doesn't provide a reference implementation like C#, Rust, Go, and others. You missed some important ones too, like the pain of cross-platform build tools and third-party library integration, which requires more third-party solutions like CMake or dependency management systems.
Just curious, what do you mean by "function temperature"? That's not a term I've heard of before, and searching turned up nothing relevant.
Re: Spot on... (Score:3)
> The source of safety is rooted in constraints not language. There is no reason similar constraints could not be enforced in C or any other language for that matter to achieve similar results. ...
> It requires development of specialized high level contractual languages to define and impose appropriate constraints on the programmer
You're proposing using TWO languages. C and another language to define all the safety. There's no need for that. One can put most of the constraints in the programming langu
Re: (Score:2)
You're proposing using TWO languages. C and another language to define all the safety. There's no need for that. One can put most of the constraints in the programming language - things like don't access array elements that don't exist.
A prime example of why using (only) an enforced-storage-safety language is inadequate for OS development is memory-mapped I/O. These are accessed as if they were a particular fixed-address region of memory - but they're actually registers in an I/O device, or a series of set
Re: (Score:3, Interesting)
Re:Spot on... (Score:5, Insightful)
I'm not sure how you read it, but the way I did, Linus is saying precisely that: you've got C, and you've got modern languages, and C++ can't win against that combination.
Re: (Score:2)
Actually, I like having a standard implementation of hash tables and strings (though C++ does that poorly compared to Vala or D).
It solves SOME of the problems with C.
Re: (Score:2, Interesting)
Spot on it completely wrong?
Linux is now built with C++, because the compiler writers who write C compilers realised that C++ was a much better language than C for complex programs.
Re:Spot on - Boehm GC Works (Score:3)
https://en.wikipedia.org/wiki/Boehm_garbage_collector
https://www.hboehm.info/gc/
https://www.gnu.org/software/guile/manual/html_node/Conservative-GC.html
Has Rust Cleaned up its libery collections? (Score:5, Interesting)
Or Cargo...
To be fair I haven't tried rust in a bunch of years. My issue wasn't as much around the language, but the set of libraries that came with it. At the time, a lot of them, seems to be poorly implemented and/or badly documented, with a lot competing libraries doing the same thing as each other.
I am a big fan, of using standard libraries that will have long term support, and very rarely using the third party, unless I really have too. Rust, when I was checking it, seemed way to basic on its own, and adding in the Libraries, seemed like a crap shoot on getting something that will be useful for the next 15 years of the product lifecycle.
Re: (Score:2)
Last year it still didn't have any decent GUI libraries, but Linus wouldn't be concerned about that. For me it meant it was unusable. (Either Wx or Qt would have been good enough...though it's not surprising that they didn't have Qt.)
Re: (Score:3)
It's better but not solved. There are now lots of high quality crates for many of the standard things you would want to do. But the metadata for working out which is which is not always there, and there are some missing gaps (notably, GUIs I guess).
The flip side is that you don't have to wait for some major release of Rust to get secondary library updates. In general, Rust updates and advances quite quickly and the improvement has been obvious over the last few years. And I think Rust will also avoid "stand
Re: (Score:3)
I'll use tilde next time.
Oh How a Weight Has Been Lifted (Score:2)
Is Linus up to date? (Score:4, Insightful)
Re: Is Linus up to date? (Score:2, Insightful)
I wonder about his competence in anything really. Anyone who almost exclusively dismisses other's ideas is a big time assowl in my book. I know quite a few academics and not once did I come across anyone dismissing anything the way this person does.
Re:Is Linus up to date? (Score:5, Interesting)
Linus has strong opinions, some of them debatable, but I think it helped get Linux where it is now.
I disagree with that statement in general. I think that C++ is perfectly fine for writing a kernel, but it is not fine for Linux. Linus designed Linux to be C++-less and it should stay C++-less. Rust is simply more in line with Linus ideas that drove the development of the Linux kernel.
And about the other post calling Linus an asshole. Linus fully assumes his role an asshole. After all, when asked why he called his version control system "git", he answered that like with Linux, he named the software after himself.
Re:Is Linus up to date? (Score:5, Interesting)
Rust is obviously "further removed from C", for once, it isn't called C-something, and it doesn't try to keep compatibility.
And that's a reason why Linus says that C++ solves nothing: you can still do all the unsafe stuff of C, you still get undefined behavior, etc... Modern C++ is safer in theory but nothing enforces that. You can still have raw pointers, aliasing, etc... C++ allows you to do a lot of things, but Linux can do without, as evidenced by its success.
One can imagine an advanced static analyzer that enforces modern C++ safe practices, but if you do that, you are not allowing C++ but a subset of it, so you might as well use another language entirely... and that language is Rust. One good thing about Rust is that it has an excellent static analyzer built in (the famous borrow checker) as well as a way to distinguish between safe and unsafe code, C and C++ don't have that, by taking a quick look at the reason for Rust support, that's the big reason for a Linux Rust support. Also, Rust seem to have an advantage when it comes to aliasing, which is a big problem with C and C++ when you want to optimize for modern architectures.
Again, I personally like C++ a lot, I don't know Rust much, it looks like a fine language but I never had the occasion to try it and I am a bit turned off by the community, but I totally understand Linus stance.
Re: Is Linus up to date? (Score:2)
A C++ project can enforce a lot with code reviews, something the Linux community prides itself on.
The real issue of Linux kernel moving to C++ is there isn't a critical mass of developers willing to learn the most recent standard and chase the updates forever.
Maybe Rust can sneak in through the back door, as long as too many devs don't already have an opinion on it. But this fascination ends the moment the LKML crowd realizes they must throw away decades of experience and earned reputation among their C usi
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
That's a microkernel though, which has a much more limited scope than a monolithic kernel like Linux or even a hybrid kernel like XNU. Taking XNU as example, L4 would be comparable only to its Mach component.
Still an interesting example though.
Re: (Score:2)
I wonder when was the last time Torvalds tried to write anything in C++? Given that there are several kernels written in C++, dismissing the idea with "LOL" doesn't really add anything to the conversation.
How many goes do you give a language? How many years? I wonder when was the last time Linus tried to write anything in PHP?
C++ has its place (Score:3)
Well, he might be right about C++ not being a good fit for the Linux kernel. Yes, the language... but he is known to have strong opinions.
Then again, C++ works well for other operating systems, like Windows, Mac OS, and even Android (core).
So this is all dependent on the project.
Re: (Score:2, Informative)
"Then again, C++ works well for other operating systems, like Windows, Mac OS, and even Android (core)."
As far as I am aware, the kernel for all three of these is written in C.
Re: (Score:2)
C++ not crap (Score:3, Insightful)
Which C++ is "crap"? 98? 03? 11? 14? 17? 20?
The great beauty of C++ is that it "is C". Can you do, in C, something you can't do in C++? Not that I'm aware of.
With each new iteration, C++ provides improved support for abstraction, and thereby, reduction of redundancy and preemption of bugs. All this, without sacrificing the fact that it still "is C" when you want it to be.
I'm intrigued by Rust, and see myself potentially migrating to it. However, C++ is, in no sense, "crap".
Re: (Score:3)
Re: (Score:2)
Comment removed (Score:5, Insightful)
Re: (Score:2)
More people because of using a modern lang? (Score:4, Interesting)
I've barely touched kernel-level development (not even developing a kernel, just a driver) but I assume the highest barrier to entry is not the language that was used up to now to write it (C) but the fact that developing a kernel is HARD and certainly something that requires quite a bit of knowledge.
I'm not saying Rust is not adequate for developing a kernel if saying that you need to know much more than it to be able to do it. Or maybe there're some parts that are not that hard and that a medium-level dev can do.
C++ is fine (Score:2)
It's just another tool, a tool is only as good as those that know use it. If people write buggy code then, yeah, maybe they should not use that tool. And I know people that shouldn't use knives because they cut their hand, I also know some people that can create artwork with knives safely. You can also put a guard on all knives and force people to use guarded knives, but again this has more to do with with the use of the tool.
Re: (Score:3)
People write buggy code.
Re: (Score:2)
And some more than others
Can't go back to C or C++ anymore (Score:5, Informative)
We are using it since then and honestly, that was the best technical decision ever. It has a *very* steep learning curve, especially for people not initially familiar with C or C++. However, it pays back big time. At that time it had somewhat lacking 3rd-party library support and tooling, this has been tremendously improved in the last few years. Also plugging in an external C module via FFI is a joy, and C++ is not too difficult either with a little bridge coding.
Writing software in Rust is really a pleasure. Cargo is excellent, cross-compilation is a joy, standard library provides a lot that C or C++ doesn't, async I/O is great via Tokio (or few other async runtimes), built-in testing support is a huge huge win, I can't stress it out enough how much pain and suffering we had writing unit tests in C++. And of course, memory and thread safety. It really works. Anyway, I don't see a compelling reason to start a new project using some older crap, unless you target some architecture which is not supported by LLVM (or, depending on the requirements, not in Tier 1 of the official Rust list). I worked with Tier 2 platforms without issues (e.g. Android and iOS) but I guess in many cases stronger guarantees are needed.
Re: (Score:3)
Just curious about your experience here. I'd agree with the steep learning curve especially with lifetimes (surprise, surprise). But, since I started rust (4 or 5 years ago), I've found life times easier and easier (particularly because of non-lexical lifetimes I guess, but for other reasons).
I *think* the language has got easier in this way and suspect that the learning curve is rather flatter now. But, of course, it could just be because I am better at Rust and, of course, I can't learn it again. What are
Re: (Score:2)
Some Features Useful (Score:2)
My first introduction to object oriented programming was with operating systems written in C. The OS uses a lot of objects. File systems, device drivers, etc. all are set up where you register a struct that includes a list of function pointers for various features.
Now the question is whether having the programming language recognize objects as their own thing helps make a better operating system? Does it make it easier for programmers? Does it help to make the code more stable? Does it make the code mo
Re: (Score:2)
OOP is mostly about two things:
1) Polymorphism (same as the function pointers used in the Kernel's I/O handling interfaces that different modules fill with different functions).
2) Creating unnecessary special syntax for the first parameter of a function.
Lots of people seem to think that 2 is really important and provides some kind of a super duper magic that makes code clearer.
D anyone? (Score:2)
Rust dependency good; Python dependency bad (Score:3)
I am old enough to remember when adding Python as a dependency merely for configuration purposes was the end of civilization.
Now it's okay to add another language for kernel development itself?
Re: (Score:3)
The problem I had with Python dependency was when my project wasn't written in Python. Some dude wanted our build system to use it. It's bad enough C had "make" in the first place. A whole language with libraries and things, just to build? That was my problem. BTW, If Jonathan Blow ever releases Jai, it addresses this issue. There is no "make" in Jai. You build software with a script that's in the same syntax as the compiled language. There is nothing special about running the same language at compi
Who cares about Linus? It's the market that counts (Score:2)
Senior C++ programmers earn a lot money and respect in the industry, Rust programmers, not so much. Maybe it'll change in the future, maybe not.
Admittedly, to me, Rust just seems like C but with better, compiler supported version of unique/shared pointers and better defaults (having to specify "mut" is pretty cool).
What makes Rust a better fit for Linux than C++? (Score:2)
So I don't know Rust, so fill me in: What makes Rust easier to integrate into a large C project than C++? It is trivial to add C++ to most existing C projects. Every other language I've integrated with C required me to re-declare my method signatures in a way that is compatible with that language, and had some level of interop trickiness involved. Can I just #include a .h file and call that from Rust? Or is it merely that C++ simply does not offer enough benefit over C, but that Rust does, so Linus is w
JavaScript (Score:4, Funny)
Just use JavaScript, make the kernel run off node.js.
Rust# (Score:2)
Impossible to write large safe programs with C++ (Score:2)
C++ is a junk language and its because of the idiocy of its rabid fans. They are really the same people that say if you are writing a "real" application you should write it in C/C++, not some safe language. This is not even what Richard Stallman wanted who was a proponent of people using Guile to write apps. If you ask why C++ does not have a concise way to have memory safety they say "We don't want memory safety because it makes things too slow, Dont use those memory safe features and WE WONT put it in our
Re: (Score:3)
I always love the argument where the C++ fans say you should get a better programmer if you can't deal with C++. So we did, two experts, only do C++, snicker behind your back and talk condescending when you mention a "safer" language. 20+ years of experience.
And yes, they really were experts. These guys did excellent work helping us extract code from another project and turning it into a DLL suitable for use into a large budget game (200+ developers involved, the type of code base that takes ages to down
Re: (Score:3)
Oh well, next time, here Xlang expert programmers and you'll be guaranteed that there'll be no bugs because in Xlang, it is impossible to write bugs.
C++ not crap, just unsafe (Score:2)
Re: (Score:2)
The true meaning of Linus's words (Score:5, Insightful)
By itself, C++ is not a crap language, of course. But it IS a crap language for projects with HUGE NUMBER of contributors, such as Linux, though. Or, one can say, for any "non-cathedral" projects. While C is a semantically simple language, C++ extends it (I know that C++ is not a strict superset of C, don't worry) by adding not only a large number of features and a large number of non-trivial to grasp abstract concepts, but it offers several programming "styles", meaning actually several "ways to do things". The most modern of these "styles" involve writing superficially concise, elegant, "RAD-like" code, which can be very hard to even understand by a non-pro C++ programmer, very hard to verify its correctness, and consequently, hard to maintain. Allowing C++ in Linux would "elitize" the project, it would men that the proverbial "thousands of eyes" that gaze at the code would be reduced to hundreds or even tens. This would defeat one of the main strong points of the whole project.
tl;dr C is language for the "masses". Even a hobbyist can learn to understand and write good C code. None of these statements is true for C++.
Re: (Score:2)
Re: (Score:3)
There is no conflict between a code of conduct and GPL or any other FSF licence, so I don't know where you are getting this. It's not different from the requirement that most GNU projects have, for example, for copyright assignment. You can use the code, you can fork the code, you can develop the code without copyright assignment and that's all fine. But you can't contribute to the Gnu project.
It's similar with Rust. You can use Rust, you can develop it, fork it, do what ever you like. But you can't go onto
Re: (Score:2)
There is no conflict between a code of conduct and GPL or any other FSF licence, so I don't know where you are getting this.
? I'm confused what you mean by that. I never implied such a conflict.
You can use the code
And therefore the Linux project would have no problems using Rust tools for developing kernel, CoCs or not. So the "they will demand Linux use their CoC" part makes zero sense.
Re: More rust SJW bullshit (Score:2)
Back in the 90s, the internet was full of "1337 cliques" who just loved to jump on the "noob", and scare away anyone trying to get into C (or Linux, or anything else for that matter). If your e-mail ended with @aol.com, you were the "dead man walking".
For all of the faults of the 'net today, it's nice to see that "1337" has died the death it so much deserved. From what you said, it sounds like they won't tolerate any "1337" in those forums.
Re: (Score:2)
Your dates are broken. Linux already has a code of conduct rather similar to Rusts and has since 2018.
https://itsfoss.com/linux-code... [itsfoss.com]
Rust is getting interest here because it's technically a very interesting language.
Re: (Score:2)
And yet you keep coming here. Again and again. With multiple fake accounts. For years on end.
Stop blaming bizx or slashdot for the fact that you're just a fucking worthless incel basement-dwelling loser with no life. That is your fault, and no-one else's.
Re: (Score:2, Offtopic)
I thought Torvalds said he was was going to "clean up his act". Didn't last long, did it?
I sure as hell hope it didn't last long.
Re: (Score:2)
Are you worried C++ might get its feelings hurt?
Re: (Score:2)