15 ms·

It's interesting to me that there is not as much push back against Rust from the kernel. Linus (I guess everyone addresses him with his first name), has been ve

by dgb23 5y ago

It's interesting to me that there is not as much push back against Rust from the kernel. Linus (I guess everyone addresses him with his first name), has been very critical, even dismissive of systems programming languages other than C. But with Rust he has a more, I guess we could say passive approach. This might be a good indicator that Rust is doing something very respectable. On the other hand I'm slightly suspicious of this movement. Rustaceans are very, very eager to promote the language. It would be interesting to know how much this movement comes from within the Linux kernel community or if it is driven more by the Rust community. In any case the language seems to have potential of becoming a new mainstream systems programming language in a few years.

gpm 5y ago
This is a very weird comment, of course the people driving this have a long history with the kernel... It takes about 2 minutes of using git to find out that Miguel's (the main author) first commit to the kernel was back in 2006, and that he's the maintainer of multiple different drivers. The rust community is naturally happy to help out, but I can't even imagine us being able to drive this sort of work...
- cerved 5y ago
  What about it is so very weird? They cautiously raise some legitimate questions.
  - gpm 5y ago
    It has an undertone implying some sort of strange conspiracy amongst rust people. Generally to be suspicious of something means there is something nefarious going on. It has an implication that Linux is something that any enthusiastic group of outsiders could force their changes into. And that there are rust people would create such a group of outsiders. It has an implication that rust people and linux people are disjoint sets. It's generally taking this strange adversarial view to a collaborative endeavour. People aren't "rustaceans" or not, it's not a sports team. People are people, they generally program in a wide variety of languages, and use whatever they think is best given a certain context. I'm not sure if I've fully captured what seems "off" to me about the comment, but hopefully you get the gist. As for asking questions, that's a clear example of https://rationalwiki.org/wiki/Just_asking_questions https://rationalwiki.org/wiki/Just_asking_questions - but at the same time the general sentiment seems to be frequently reflected in internet comments. I don't think it's a malicious case of this, just how they chose to express their opinions.
    - dgb23 5y ago
      Poor choice of words on my part I guess. To clarify, I didn't mean suspicious in the sense of expecting malicious behavior, rather than in the sense of not being overly optimistic about this type of progress, because I think it is very hard to incorporate new tooling/languages despite their merits. In other words: it would be nice to see this being fruitful, because it would possibly a strong, positive signal for programming and programming languages in general, but I'm cautious or "suspicious" still.
      - gpm 5y ago
        Please don't take my above comment too harshly by the way, I know it could be read as a list of pretty hard criticism, it's really just trying to dive into why the tone seemed off when there isn't one smoking gun. It's a list of the comment could be read like this, not that the comment actually means this.
        generalizations 5y ago
        Just fyi, your comment does come off as fairly harsh.
        gpm 5y ago
        Thanks, I know, I wish i had at least included the language softening it in the original comment.
        dgb23 5y ago
        All good! English is not my first language, plus if we all had these conversations face to face, we wouldn’t have to guess the tone.
    - cerved 5y ago
      Honestly I think you're reading to much into this. You contributed some good points but dismissing the comment as very weird is a bit much
  - deleted 5y ago
    [deleted]
  - calcifer 5y ago
    There is not a single question in GP's comment, let alone a legitimate one.
- ojeda 5y ago
  To be fair, I was just a teenager back then and I was out of kernel development for quite a few years afterwards. But you are right, this is not coming from the Rust community itself. In fact, several independent groups have been thinking of using Rust in one way or another for kernel purposes, as early as... 2013 (!), e.g. from Taesoo Kim: https://github.com/tsgates/rust.ko/commit/58f0fb8fdf4063f5b24a09cbfeec81bf28a9d81b There were others: John Baublitz had a external kernel module going on, Samantha Miller also worked on enabling a FUSE-like API to write filesystems in Rust, etc. And, of course, Alex Gaynor & Geoffrey Thomas had the most mature Rust abstractions for external kernel modules. At the moment, in the project we have a mixture of people that come from a Rust or kernel background, which has been great. And most of us have used many languages in our work, not just Rust. Personally, most of my career has been around C++ and Python.
- gerdesj 5y ago
  "first commit to the kernel was back in 2006" That's not my definition of long history! My first Linux kernel was just pre 2.0 and I used make config. Actually I used make config for quite a while before it got out of hand and I started keeping copies of the config to work from instead of doing it from scratch each time I did an upgrade. I'm not the sharpest tool ...
  - Dylan16807 5y ago
    > That's not my definition of long history! It's long in comparison to Rust!
    - gerdesj 5y ago
      Quite. There's a term, often used by engineers (Chartered, obviously): "time served". C is time served - it might be a bit weird and start dribbling for no reason but it quite literally runs a huge part of the world. Rust is not time served and it needs to grow up. Initial signs are positive. We are at the cooing stage over a pretty child that may either be the Messiah (a Naughty Boy) or decide to throw its poo at its parents and stick to licking windows. Time will tell.
      - gerdesj 5y ago
        I don't really give a shit about internet points ...
underdeserver 5y ago
> Linus (I guess everyone addresses him with his first name), has been very critical, even dismissive of systems programming languages other than C. But with Rust he has a more, I guess we could say passive approach. This might be a good indicator that Rust is doing something very respectable. Or that Linus is going through something very respectable.
- diragon 5y ago
  He still tells people off when they're being stupid. One instance of this happened a few weeks ago when an antivaxer said something on the mailing list.
  - topranks 5y ago
    He tends to temper himself a lot more though. Doesn’t seem quite as aggressive even for instance in that message. Which is good, although I wouldn’t have minded a bit of old school Linus for the anti vaxers.
adwn 5y ago
> It would be interesting to know how much this movement comes from within the Linux kernel community or if it is driven more by the Rust community. You make it sound as if those are two non-overlapping sets. I don't think they could pull off this project without intimate knowledge of the Linux kernel.
geofft 5y ago
Linus has been critical of C, before, too (e.g. https://lkml.org/lkml/2018/6/5/769 https://lkml.org/lkml/2018/6/5/769). If you look at Linus's criticism of C++ (e.g., https://lkml.org/lkml/2004/1/20/20 https://lkml.org/lkml/2004/1/20/20), he criticizes a few specific things about the language - exception handling, implicit allocations, complex OO. Rust, as it happens, doesn't do any of that. Errors are passed back via return values (which is what the kernel already does), memory allocations are explicit by convention and "zero-cost abstractions" are favored, and the OO model doesn't have multiple inheritance or anything, just interfaces (which is also what the kernel already does, in C, using structs of function pointers). So I'm not surprised that he doesn't have similar harsh words for Rust. It solves a lot of the issues with C that have been causing practical problems for the kernel (apart from confusing aliasing rules and confusing overflow rules, there was also the problem a while back where a bunch of != NULL checks got optimized out), and it doesn't have the problems C++ has - in fact it tends to solve those use cases in a way similar to the kernel's existing approach. For my part, I've been involved a very tiny bit in Linux kernel development for well over a decade because I find systems programming cool, and I've also been involved a very tiny bit in Rust starting around 1.0 because I find systems programming cool. I started this project because I genuinely thought Rust would be a good choice, not because I was deeply involved with the Rust community and I wanted to evangelize it. (I looked up the IRC logs where Alex and I decided to start working on this, and the context was that Alex had run into some bug with buffer length handling in the kernel, he was considering sending in some patches to improve the C abstractions about this, and since PyCon was the following week I semi-jokingly asked if we should instead spend our sprints time writing support to ship kernel modules in Rust. Which we did.)
- jcelerier 5y ago
  > Rust, as it happens, doesn't do any of that. Rust does not allocate implicitly when you use Vec or String (or any other container) ? come on..
  - Ericson2314 5y ago
    https://github.com/rust-lang/rust/pull/84266 https://github.com/rust-lang/rust/pull/84266 We have been excising this with a new opt-out mechanism so there are no allocations behind your back but the same abstractions are notheless used as the rest of the Rust ecosystem.
kmeisthax 5y ago
I don't think it's merely the Rust Evangelism Strike Force; Linus is notoriously critical of this kind of hype. In fact, his most vocal hatred of a programming language has been targeted at C++. Those criticisms almost surely have some amount of "lived experience" associated with them - he's not the kind of person to just buy into the hype of a programming language and risk the entire kernel over it. Remember, this is the guy who used tarballs as a version control system up until Bitkeeper gave him free (as in beer) licenses to their DVCS. He didn't hate all version control, as much as he thought that was the case - he hated badly implemented version control, which was the standard at the time with things like CVS. That's why he ultimately wound up writing Git once the Bitkeeper deal became untenable. In this set of old e-mails from a decade and change ago[0] he specifically calls out STL/Boost being unstable and difficult to work with, C++ providing certain abstractions that have undocumented performance problems, exception handling, and hidden allocations. Of that list, I can think of several things Rust specifically solves relative to C++. - Rust traits make reasoning about generic code way easier than C++ templates. In C++, you just write your template, and then the template is resolved at the site of instantiation. If it's not a valid type to put in there, then the compiler tells you that you used the template wrong, but it's still your responsibility to figure out why. In Rust, however, generic types have to be constrained with traits; which list out exactly what a generic type requires. So if you misuse a generic type, the compiler can just say 'well, you need Add on parameter T here to call this', and the error will always be on the type you used, rather than some dependent generic type. - One of Rust's core goals is "zero-cost abstractions". It does this very well, but it also has some non-zero-cost abstractions. These I'd categorize as "transparent-and-predictable-cost abstractions". For example: Rust is known for it's borrow-checker, which provides compile-time verification of memory safety. However, these might not be the most flexible memory-management solution; so it also provides shared-ownership through reference counting. This does have an associated cost, but it's easy to reason about and clearly stated. They even provided both atomic and non-atomic reference counting options because the latter has less cost associated with it. - C++ uses an exception handling model built around stack unwinding, which requires that all code maintain a valid stack that the C++ runtime can unwind at all times. This can pose problems for kernels which almost certainly will be doing weird things with the stack that the compiler won't entirely understand. While Rust has exceptions (called panics) and supports C++ style unwinding, it also allows you to change the exception handling model to just terminating the program instead, which matches better with how the Linux kernel handles exceptions. - Rust also heavily discourages the use of exceptions relative to C++. Panicking is mostly reserved for error conditions that are actually exceptional (i.e. unexpected), while error conditions that are expected can be signaled using return types like Option and Result. There's even special language syntax (called Try, or the ? operator) which will automatically return if a value signals an error. The only thing I can't say Rust solves is hidden allocations, but it seems like the plan Linus has picked is to tame that beast with a Linux-specific core library, with as much as possible mapped to Linux's existing C abstractions. This probably will work out as this is the intended way to extend existing native code with Rust libraries. (It's how Mozilla integrated things like Servo into Firefox.) [0] http://harmful.cat-v.org/software/c++/linus http://harmful.cat-v.org/software/c++/linus
jldugger 5y ago
I'm not surprised really. The C language is pretty old, and pretty much none of the features in C++ make writing correct kernel code easier. That's not a mark against C++, it's just landed on a different niche: a high perf userspace application language for expert software engineers. Other high profile languages like Golang and Swift have a similar 'application engineer' focus that offer no meaningful improvements for kernel authors. So it's not surprising to me that Torvalds is critical of languages that don't cater to his use case. Nor why he's less vocal about Rust. The allure of Rust is inbuilt support for multithreading, protection against data races, and an efficient memory management system.
- ncmncm 5y ago
  Fine, but it is completely false that C++ offers nothing useful for kernel coding. You can see, for example, SerenityOS kernel making good use of modern features. Any feature useful for coding libraries is equally useful for kernel coding, because the overwhelming majority of kernel code is identical to what goes in libraries, and much of it is, explicitly, library code.
  - pjmlp 5y ago
    People keep forgeting that ARM, Microsoft, Apple and Google OSes use drivers written in C++.
alfalfasprout 5y ago
The biggest pushback was with C++. Why? Because when these discussions still started, C++ codebases tended to be a mess. It didn't help that C++11 was coming up and support was wildly inconsistent among compilers. Ultimately it was still possible to write unsafe code though. The landscape has now changed and Rust has now positioned itself as a language that actually does have very key advantages (in correctness and safety). While C++ has made large strides, its advantages now lie elsewhere (eg; drawing on a wealth of performant libraries-- something that the kernel has less of a sue of).
blub 5y ago
Trying to figure out how much technical merit vs. guerilla marketing hides behind a project's decision to use Rust is probably an impossible task. With Rust the two are intertwined, the language and the community have a certain militant attitude associated with them. Looking at the complexity of Rust versus C and the very limited benefits one would get out of adding a few drops of memory safety into a sea of C, one has to conclude that technical merit alone does not explain this decision. In any case, I don't think Linus will write another language rant after he had an epiphany about his "unprofessional" attitude. And if there's enough corporate support combined with some grassroots support, he's probably figured out that he'd lose that battle even if he were nice about it.
- kbenson 5y ago
  > the language and the community have a certain militant attitude associated with them. I'm not even sure what this means. What do you consider a militant attitude in this context? From what I've seen, most Rust evangelists (at least here) try to explain its benefits while acknowledging cases where it may not provide something better and is instead equivalent but different or slightly worse (it's not like any language can be better in every respect). > the very limited benefits one would get out of adding a few drops of memory safety into a sea of C, one has to conclude that technical merit alone does not explain this decision. I don't think that's a valid conclusion, but even if it is, you haven't explained it well enough. You haven't addressed how much more complex Rust is than C no how limited the benefits would be. You've provided a tiny bit more information than "it's not worth it", which I think is far from sufficient to support that position in a discussion that can have as much depth as is easily achieved here. > In any case, I don't think Linus will write another language rant after he had an epiphany about his "unprofessional" attitude. It's not like he's stopped calling being stupid for acting stupid or refrained from criticizing technologies he thinks deserves it. There are recent cases (mentioned in this discussion) that outline recent cases where he's done so. I'm not sure why you would assume he's all of a sudden deciding to keep his mouth shut about what would be valid concerns to bring forth if he had them, nothing to do with interpersonal communication problems he's had in the past.
  - 5y ago

by dgb23 5y ago

gpm 5y ago

This is a very weird comment, of course the people driving this have a long history with the kernel... It takes about 2 minutes of using git to find out that Miguel's (the main author) first commit to the kernel was back in 2006, and that he's the maintainer of multiple different drivers. The rust community is naturally happy to help out, but I can't even imagine us being able to drive this sort of work...

cerved 5y ago
What about it is so very weird? They cautiously raise some legitimate questions.
- gpm 5y ago
  It has an undertone implying some sort of strange conspiracy amongst rust people. Generally to be suspicious of something means there is something nefarious going on. It has an implication that Linux is something that any enthusiastic group of outsiders could force their changes into. And that there are rust people would create such a group of outsiders. It has an implication that rust people and linux people are disjoint sets. It's generally taking this strange adversarial view to a collaborative endeavour. People aren't "rustaceans" or not, it's not a sports team. People are people, they generally program in a wide variety of languages, and use whatever they think is best given a certain context. I'm not sure if I've fully captured what seems "off" to me about the comment, but hopefully you get the gist. As for asking questions, that's a clear example of https://rationalwiki.org/wiki/Just_asking_questions https://rationalwiki.org/wiki/Just_asking_questions - but at the same time the general sentiment seems to be frequently reflected in internet comments. I don't think it's a malicious case of this, just how they chose to express their opinions.
  - dgb23 5y ago
    Poor choice of words on my part I guess. To clarify, I didn't mean suspicious in the sense of expecting malicious behavior, rather than in the sense of not being overly optimistic about this type of progress, because I think it is very hard to incorporate new tooling/languages despite their merits. In other words: it would be nice to see this being fruitful, because it would possibly a strong, positive signal for programming and programming languages in general, but I'm cautious or "suspicious" still.
    - gpm 5y ago
      Please don't take my above comment too harshly by the way, I know it could be read as a list of pretty hard criticism, it's really just trying to dive into why the tone seemed off when there isn't one smoking gun. It's a list of the comment could be read like this, not that the comment actually means this.
      - generalizations 5y ago
        Just fyi, your comment does come off as fairly harsh.
        gpm 5y ago
        Thanks, I know, I wish i had at least included the language softening it in the original comment.
      - dgb23 5y ago
        All good! English is not my first language, plus if we all had these conversations face to face, we wouldn’t have to guess the tone.
  - cerved 5y ago
    Honestly I think you're reading to much into this. You contributed some good points but dismissing the comment as very weird is a bit much
- deleted 5y ago
  [deleted]
- calcifer 5y ago
  There is not a single question in GP's comment, let alone a legitimate one.
ojeda 5y ago
To be fair, I was just a teenager back then and I was out of kernel development for quite a few years afterwards. But you are right, this is not coming from the Rust community itself. In fact, several independent groups have been thinking of using Rust in one way or another for kernel purposes, as early as... 2013 (!), e.g. from Taesoo Kim: https://github.com/tsgates/rust.ko/commit/58f0fb8fdf4063f5b24a09cbfeec81bf28a9d81b There were others: John Baublitz had a external kernel module going on, Samantha Miller also worked on enabling a FUSE-like API to write filesystems in Rust, etc. And, of course, Alex Gaynor & Geoffrey Thomas had the most mature Rust abstractions for external kernel modules. At the moment, in the project we have a mixture of people that come from a Rust or kernel background, which has been great. And most of us have used many languages in our work, not just Rust. Personally, most of my career has been around C++ and Python.
gerdesj 5y ago
"first commit to the kernel was back in 2006" That's not my definition of long history! My first Linux kernel was just pre 2.0 and I used make config. Actually I used make config for quite a while before it got out of hand and I started keeping copies of the config to work from instead of doing it from scratch each time I did an upgrade. I'm not the sharpest tool ...
- Dylan16807 5y ago
  > That's not my definition of long history! It's long in comparison to Rust!
  - gerdesj 5y ago
    Quite. There's a term, often used by engineers (Chartered, obviously): "time served". C is time served - it might be a bit weird and start dribbling for no reason but it quite literally runs a huge part of the world. Rust is not time served and it needs to grow up. Initial signs are positive. We are at the cooing stage over a pretty child that may either be the Messiah (a Naughty Boy) or decide to throw its poo at its parents and stick to licking windows. Time will tell.
    - gerdesj 5y ago
      I don't really give a shit about internet points ...

underdeserver 5y ago

> Linus (I guess everyone addresses him with his first name), has been very critical, even dismissive of systems programming languages other than C. But with Rust he has a more, I guess we could say passive approach. This might be a good indicator that Rust is doing something very respectable. Or that Linus is going through something very respectable.

diragon 5y ago
He still tells people off when they're being stupid. One instance of this happened a few weeks ago when an antivaxer said something on the mailing list.
- topranks 5y ago
  He tends to temper himself a lot more though. Doesn’t seem quite as aggressive even for instance in that message. Which is good, although I wouldn’t have minded a bit of old school Linus for the anti vaxers.

adwn 5y ago

> It would be interesting to know how much this movement comes from within the Linux kernel community or if it is driven more by the Rust community. You make it sound as if those are two non-overlapping sets. I don't think they could pull off this project without intimate knowledge of the Linux kernel.

geofft 5y ago

Linus has been critical of C, before, too (e.g. https://lkml.org/lkml/2018/6/5/769 https://lkml.org/lkml/2018/6/5/769). If you look at Linus's criticism of C++ (e.g., https://lkml.org/lkml/2004/1/20/20 https://lkml.org/lkml/2004/1/20/20), he criticizes a few specific things about the language - exception handling, implicit allocations, complex OO. Rust, as it happens, doesn't do any of that. Errors are passed back via return values (which is what the kernel already does), memory allocations are explicit by convention and "zero-cost abstractions" are favored, and the OO model doesn't have multiple inheritance or anything, just interfaces (which is also what the kernel already does, in C, using structs of function pointers). So I'm not surprised that he doesn't have similar harsh words for Rust. It solves a lot of the issues with C that have been causing practical problems for the kernel (apart from confusing aliasing rules and confusing overflow rules, there was also the problem a while back where a bunch of != NULL checks got optimized out), and it doesn't have the problems C++ has - in fact it tends to solve those use cases in a way similar to the kernel's existing approach. For my part, I've been involved a very tiny bit in Linux kernel development for well over a decade because I find systems programming cool, and I've also been involved a very tiny bit in Rust starting around 1.0 because I find systems programming cool. I started this project because I genuinely thought Rust would be a good choice, not because I was deeply involved with the Rust community and I wanted to evangelize it. (I looked up the IRC logs where Alex and I decided to start working on this, and the context was that Alex had run into some bug with buffer length handling in the kernel, he was considering sending in some patches to improve the C abstractions about this, and since PyCon was the following week I semi-jokingly asked if we should instead spend our sprints time writing support to ship kernel modules in Rust. Which we did.)

jcelerier 5y ago
> Rust, as it happens, doesn't do any of that. Rust does not allocate implicitly when you use Vec or String (or any other container) ? come on..
- Ericson2314 5y ago
  https://github.com/rust-lang/rust/pull/84266 https://github.com/rust-lang/rust/pull/84266 We have been excising this with a new opt-out mechanism so there are no allocations behind your back but the same abstractions are notheless used as the rest of the Rust ecosystem.

kmeisthax 5y ago

I don't think it's merely the Rust Evangelism Strike Force; Linus is notoriously critical of this kind of hype. In fact, his most vocal hatred of a programming language has been targeted at C++. Those criticisms almost surely have some amount of "lived experience" associated with them - he's not the kind of person to just buy into the hype of a programming language and risk the entire kernel over it. Remember, this is the guy who used tarballs as a version control system up until Bitkeeper gave him free (as in beer) licenses to their DVCS. He didn't hate all version control, as much as he thought that was the case - he hated badly implemented version control, which was the standard at the time with things like CVS. That's why he ultimately wound up writing Git once the Bitkeeper deal became untenable. In this set of old e-mails from a decade and change ago[0] he specifically calls out STL/Boost being unstable and difficult to work with, C++ providing certain abstractions that have undocumented performance problems, exception handling, and hidden allocations. Of that list, I can think of several things Rust specifically solves relative to C++. - Rust traits make reasoning about generic code way easier than C++ templates. In C++, you just write your template, and then the template is resolved at the site of instantiation. If it's not a valid type to put in there, then the compiler tells you that you used the template wrong, but it's still your responsibility to figure out why. In Rust, however, generic types have to be constrained with traits; which list out exactly what a generic type requires. So if you misuse a generic type, the compiler can just say 'well, you need Add on parameter T here to call this', and the error will always be on the type you used, rather than some dependent generic type. - One of Rust's core goals is "zero-cost abstractions". It does this very well, but it also has some non-zero-cost abstractions. These I'd categorize as "transparent-and-predictable-cost abstractions". For example: Rust is known for it's borrow-checker, which provides compile-time verification of memory safety. However, these might not be the most flexible memory-management solution; so it also provides shared-ownership through reference counting. This does have an associated cost, but it's easy to reason about and clearly stated. They even provided both atomic and non-atomic reference counting options because the latter has less cost associated with it. - C++ uses an exception handling model built around stack unwinding, which requires that all code maintain a valid stack that the C++ runtime can unwind at all times. This can pose problems for kernels which almost certainly will be doing weird things with the stack that the compiler won't entirely understand. While Rust has exceptions (called panics) and supports C++ style unwinding, it also allows you to change the exception handling model to just terminating the program instead, which matches better with how the Linux kernel handles exceptions. - Rust also heavily discourages the use of exceptions relative to C++. Panicking is mostly reserved for error conditions that are actually exceptional (i.e. unexpected), while error conditions that are expected can be signaled using return types like Option and Result. There's even special language syntax (called Try, or the ? operator) which will automatically return if a value signals an error. The only thing I can't say Rust solves is hidden allocations, but it seems like the plan Linus has picked is to tame that beast with a Linux-specific core library, with as much as possible mapped to Linux's existing C abstractions. This probably will work out as this is the intended way to extend existing native code with Rust libraries. (It's how Mozilla integrated things like Servo into Firefox.) [0] http://harmful.cat-v.org/software/c++/linus http://harmful.cat-v.org/software/c++/linus

jldugger 5y ago

I'm not surprised really. The C language is pretty old, and pretty much none of the features in C++ make writing correct kernel code easier. That's not a mark against C++, it's just landed on a different niche: a high perf userspace application language for expert software engineers. Other high profile languages like Golang and Swift have a similar 'application engineer' focus that offer no meaningful improvements for kernel authors. So it's not surprising to me that Torvalds is critical of languages that don't cater to his use case. Nor why he's less vocal about Rust. The allure of Rust is inbuilt support for multithreading, protection against data races, and an efficient memory management system.

ncmncm 5y ago
Fine, but it is completely false that C++ offers nothing useful for kernel coding. You can see, for example, SerenityOS kernel making good use of modern features. Any feature useful for coding libraries is equally useful for kernel coding, because the overwhelming majority of kernel code is identical to what goes in libraries, and much of it is, explicitly, library code.
- pjmlp 5y ago
  People keep forgeting that ARM, Microsoft, Apple and Google OSes use drivers written in C++.

alfalfasprout 5y ago

The biggest pushback was with C++. Why? Because when these discussions still started, C++ codebases tended to be a mess. It didn't help that C++11 was coming up and support was wildly inconsistent among compilers. Ultimately it was still possible to write unsafe code though. The landscape has now changed and Rust has now positioned itself as a language that actually does have very key advantages (in correctness and safety). While C++ has made large strides, its advantages now lie elsewhere (eg; drawing on a wealth of performant libraries-- something that the kernel has less of a sue of).

blub 5y ago

Trying to figure out how much technical merit vs. guerilla marketing hides behind a project's decision to use Rust is probably an impossible task. With Rust the two are intertwined, the language and the community have a certain militant attitude associated with them. Looking at the complexity of Rust versus C and the very limited benefits one would get out of adding a few drops of memory safety into a sea of C, one has to conclude that technical merit alone does not explain this decision. In any case, I don't think Linus will write another language rant after he had an epiphany about his "unprofessional" attitude. And if there's enough corporate support combined with some grassroots support, he's probably figured out that he'd lose that battle even if he were nice about it.

kbenson 5y ago
> the language and the community have a certain militant attitude associated with them. I'm not even sure what this means. What do you consider a militant attitude in this context? From what I've seen, most Rust evangelists (at least here) try to explain its benefits while acknowledging cases where it may not provide something better and is instead equivalent but different or slightly worse (it's not like any language can be better in every respect). > the very limited benefits one would get out of adding a few drops of memory safety into a sea of C, one has to conclude that technical merit alone does not explain this decision. I don't think that's a valid conclusion, but even if it is, you haven't explained it well enough. You haven't addressed how much more complex Rust is than C no how limited the benefits would be. You've provided a tiny bit more information than "it's not worth it", which I think is far from sufficient to support that position in a discussion that can have as much depth as is easily achieved here. > In any case, I don't think Linus will write another language rant after he had an epiphany about his "unprofessional" attitude. It's not like he's stopped calling being stupid for acting stupid or refrained from criticizing technologies he thinks deserves it. There are recent cases (mentioned in this discussion) that outline recent cases where he's done so. I'm not sure why you would assume he's all of a sudden deciding to keep his mouth shut about what would be valid concerns to bring forth if he had them, nothing to do with interpersonal communication problems he's had in the past.
- 5y ago