6 ms·

I also believe that this is a little bit hype driven but not quite. I've been talking with a Linux dev at a conference in Cluj and he said that people nowadays

I also believe that this is a little bit hype driven but not quite. I've been talking with a Linux dev at a conference in Cluj and he said that people nowadays are not interested in Linux development as he was in high-school because there's so much more out there and way easier to enter (web, mobile, game dev etc.). A new language like Rust can reinvigorate the Linux ecosystem + the benefits of safety and other language features. Zig could have been an alternative but unfortunately it's still under development and quite far from a 1.0. But, in my opinion, once you fragment the ecosystem with Rust, adding a third language like Zig should not be a problem. So, yeah, the train still hasn't left the station.

lmilcin 5y ago
Honestly, I think this particular argument is bogus. From my point of view what counts is actual kernel development. If you are going to develop kernel because it uses cool new language but you would not if it was still C, you are probably not the right person. Now, I think Rust has potential to be good kernel language, I am mostly concerned with toolchain, ability for people to read the code with comprehension, ensure correct code, etc.
- johnnycerberus 5y ago
  It is a little bit bogus, I did not say that I stand by it or that I think that this is the WAY. I'm not even a Linux developer or a kernel dev, though I've done embedded programming at the beginning of my career. Just that if we won't take risks, we will never know whether the approach of Rust or Zig or just plain-old C would prove to be THE approach to systems programming. Besides fragmentation, how else can you harm what we already have? I believe the ecosystems fix themselves, if you offer to the developer three choices (in our case C, Zig, Rust), we will see how things pan out and we will have a clearer picture. Java did not become the language of Fortune 500 companies out of sheer luck, people simply chose it more often than its counterparts because the feedback was positive. I expect the same in systems programming.
- accountofme 5y ago
  a couple of things: 1. rust is easier to read than c/c++ 2. The toolchain is llvm based and much nicer to use than c/c++. Hell your build scripts are also rust 3. Given the choice to develop in c or rust I would choose rust 4. In my own experience I have found rust to be simpler to Deal with correctness than c/c++ (I have been both a rust and c++ developer)
  - lmilcin 5y ago
    > 1. rust is easier to read than c/c++ Rust may or may not be easier to read than C++, depends on your experience. But it is not true it is easier to read than C. C is objectively much smaller, simpler language than Rust. > 4. In my own experience I have found rust to be simpler to Deal with correctness than c/c++ That is the whole point of Rust. And also to do this with minimum runtime overhead.
    - moltonel3x 5y ago
      Being a smaller simpler language doesn't make it easier to read or write. Go is an even "simpler" language than C, but you quickly suffer from boilerplate-blindness when reviewing it. Being able to write good abstractions can make a huge difference. Having lifetimes, or the use of the semantically-correct integer type checked by the compiler reduces the cognitive load on the writer and reviewer.
    - ClumsyPilot 5y ago
      >"is objectively much smaller, simpler language than Rust." Brainfuck is an even smaller, simpler language, it has only 4 characters!
    - estebank 5y ago
      C is a smaller language on some axes. That's not necessarily a good thing. Looking at the following function definition, can you figure out how to use it safely? int foo(char* text, char* out, char* s, char* x); If you were to have the same signature in Rust, it would look more like the following: fn foo( text: String, out &mut String, s: &str, x: &mut str, ) -> i32; Now it is clearer that foo is responsible for getting rid of the allocation corresponding to text, which is on the heap. out can be modified and potentially reallocated. s is read only and it won't be deallocated by foo. x might be mutated in-place by foo, but it won't be deallocated. Having a more "complex" way to represent in the typesystem something that C only bothers to call "a pointer" makes things better: safer, easier to skim, explore and understand an API, and allows the compiler to catch API misuses.
- lmm 5y ago
  > From my point of view what counts is actual kernel development. If you are going to develop kernel because it uses cool new language but you would not if it was still C, you are probably not the right person. Why's that? C is a tedious language that makes you do so much manual bookkeeping, I don't think I'd ever write it again (if I needed C for some reason I'd write a program to generate it for me rather than doing it myself). I think any decent developer would be put off by C to some extent. Sure, the people who really want to make a kernel may put up with it, but an arbitrary enthusiasm barrier is not the way to attract good contributors.
  - lmilcin 5y ago
    On the other hand C is simple language, there are no discussions about how to do something in C between people who know C. C is tedious but kernel programming isn't about spewing vast amount of code anyway. It is more important to be able to read it, understand it and ascertain it is correct. This is one of main reasons for why C++ is not there.
    - adwn 5y ago
      > C is simple language Except for, you know, all that Undefined Behavior stuff, which makes it practically impossible to write correct programs even for very skilled developers, or the lack of abstractions, which makes it hard to safely re-use advanced data structures. "C is a simplistic language" would be more accurate.
      - VLM 5y ago
        C encourages simplicity. Code is either clear and simple, or extremely obscure and safe, or kinda in between is complicated but not complicated enough such that its not safe. "Simplicate and add lightness" aerospace mentality people like C. At some point any project expected to do ever more complicated tasks, like a kernel, will be unable to use simple C and will have to take the hit of a more complicated language. Simple is good when matched to simple tasks; my microwave oven or TV should ideally never data network with the external world and never malloc memory and never do string processing. C makes an amazing toaster or car automatic transmission controller.
- kaba0 5y ago
  As a potential alternative thought process I would add that kernel development sort of uses their own flavor of C that you also have to learn. While in case of a language with better abstraction powers, you can actually read a function and knowing only the language but not the project, could potentially contribute — as opposed to C, where I have to know this cryptic macro, and that by convention this and that struct has to be embedded x bytes into another struct so that it can be used with the linked list utilities made. Also, simply by having god damn namespaces more readable names could be used at no downside.
- moltonel3x 5y ago
  > If you are going to develop kernel because it uses cool new language but you would not if it was still C, you are probably not the right person. You are taking this the wrong way around. It's not about people contributing to $PROJECT because it uses $COOL_TECH, it's about people being turned off from contributing to $PROJECT because of $MEH_TECH. If Linux was written entirely in assembly, we'd be having the same argument about the introduction of C.
  - pjmlp 5y ago
    Ironically UNIX was indeed written in Assembly, and C only came into the picture with V4. Also BCPL, the basis for B intepreter, was originally designed to Bootstrap CPL, not really as a daily use language.

lmilcin 5y ago

Honestly, I think this particular argument is bogus. From my point of view what counts is actual kernel development. If you are going to develop kernel because it uses cool new language but you would not if it was still C, you are probably not the right person. Now, I think Rust has potential to be good kernel language, I am mostly concerned with toolchain, ability for people to read the code with comprehension, ensure correct code, etc.

johnnycerberus 5y ago
It is a little bit bogus, I did not say that I stand by it or that I think that this is the WAY. I'm not even a Linux developer or a kernel dev, though I've done embedded programming at the beginning of my career. Just that if we won't take risks, we will never know whether the approach of Rust or Zig or just plain-old C would prove to be THE approach to systems programming. Besides fragmentation, how else can you harm what we already have? I believe the ecosystems fix themselves, if you offer to the developer three choices (in our case C, Zig, Rust), we will see how things pan out and we will have a clearer picture. Java did not become the language of Fortune 500 companies out of sheer luck, people simply chose it more often than its counterparts because the feedback was positive. I expect the same in systems programming.
accountofme 5y ago
a couple of things: 1. rust is easier to read than c/c++ 2. The toolchain is llvm based and much nicer to use than c/c++. Hell your build scripts are also rust 3. Given the choice to develop in c or rust I would choose rust 4. In my own experience I have found rust to be simpler to Deal with correctness than c/c++ (I have been both a rust and c++ developer)
- lmilcin 5y ago
  > 1. rust is easier to read than c/c++ Rust may or may not be easier to read than C++, depends on your experience. But it is not true it is easier to read than C. C is objectively much smaller, simpler language than Rust. > 4. In my own experience I have found rust to be simpler to Deal with correctness than c/c++ That is the whole point of Rust. And also to do this with minimum runtime overhead.
  - moltonel3x 5y ago
    Being a smaller simpler language doesn't make it easier to read or write. Go is an even "simpler" language than C, but you quickly suffer from boilerplate-blindness when reviewing it. Being able to write good abstractions can make a huge difference. Having lifetimes, or the use of the semantically-correct integer type checked by the compiler reduces the cognitive load on the writer and reviewer.
  - ClumsyPilot 5y ago
    >"is objectively much smaller, simpler language than Rust." Brainfuck is an even smaller, simpler language, it has only 4 characters!
  - estebank 5y ago
    C is a smaller language on some axes. That's not necessarily a good thing. Looking at the following function definition, can you figure out how to use it safely? int foo(char* text, char* out, char* s, char* x); If you were to have the same signature in Rust, it would look more like the following: fn foo( text: String, out &mut String, s: &str, x: &mut str, ) -> i32; Now it is clearer that foo is responsible for getting rid of the allocation corresponding to text, which is on the heap. out can be modified and potentially reallocated. s is read only and it won't be deallocated by foo. x might be mutated in-place by foo, but it won't be deallocated. Having a more "complex" way to represent in the typesystem something that C only bothers to call "a pointer" makes things better: safer, easier to skim, explore and understand an API, and allows the compiler to catch API misuses.
lmm 5y ago
> From my point of view what counts is actual kernel development. If you are going to develop kernel because it uses cool new language but you would not if it was still C, you are probably not the right person. Why's that? C is a tedious language that makes you do so much manual bookkeeping, I don't think I'd ever write it again (if I needed C for some reason I'd write a program to generate it for me rather than doing it myself). I think any decent developer would be put off by C to some extent. Sure, the people who really want to make a kernel may put up with it, but an arbitrary enthusiasm barrier is not the way to attract good contributors.
- lmilcin 5y ago
  On the other hand C is simple language, there are no discussions about how to do something in C between people who know C. C is tedious but kernel programming isn't about spewing vast amount of code anyway. It is more important to be able to read it, understand it and ascertain it is correct. This is one of main reasons for why C++ is not there.
  - adwn 5y ago
    > C is simple language Except for, you know, all that Undefined Behavior stuff, which makes it practically impossible to write correct programs even for very skilled developers, or the lack of abstractions, which makes it hard to safely re-use advanced data structures. "C is a simplistic language" would be more accurate.
    - VLM 5y ago
      C encourages simplicity. Code is either clear and simple, or extremely obscure and safe, or kinda in between is complicated but not complicated enough such that its not safe. "Simplicate and add lightness" aerospace mentality people like C. At some point any project expected to do ever more complicated tasks, like a kernel, will be unable to use simple C and will have to take the hit of a more complicated language. Simple is good when matched to simple tasks; my microwave oven or TV should ideally never data network with the external world and never malloc memory and never do string processing. C makes an amazing toaster or car automatic transmission controller.
kaba0 5y ago
As a potential alternative thought process I would add that kernel development sort of uses their own flavor of C that you also have to learn. While in case of a language with better abstraction powers, you can actually read a function and knowing only the language but not the project, could potentially contribute — as opposed to C, where I have to know this cryptic macro, and that by convention this and that struct has to be embedded x bytes into another struct so that it can be used with the linked list utilities made. Also, simply by having god damn namespaces more readable names could be used at no downside.
moltonel3x 5y ago
> If you are going to develop kernel because it uses cool new language but you would not if it was still C, you are probably not the right person. You are taking this the wrong way around. It's not about people contributing to $PROJECT because it uses $COOL_TECH, it's about people being turned off from contributing to $PROJECT because of $MEH_TECH. If Linux was written entirely in assembly, we'd be having the same argument about the introduction of C.
- pjmlp 5y ago
  Ironically UNIX was indeed written in Assembly, and C only came into the picture with V4. Also BCPL, the basis for B intepreter, was originally designed to Bootstrap CPL, not really as a daily use language.