12 ms·

I was already secretly imagining a future where Rust will completely replace C as the low level language for everything. Even the Linux kernel rewritten in it e

by DCKing 12y ago

I was already secretly imagining a future where Rust will completely replace C as the low level language for everything. Even the Linux kernel rewritten in it eventually. It'd be a much better world with no #ifdefs, strong type safety and memory safety depending on compilers instead of fallible programmers. But I was expecting it would take a while before people had the ambition to start doing these things, even when it comes to the smaller ambition of rewriting the GNU coreutils. Rust is a great language already, but it's not a stable language yet. I wonder if my imagination will become reality eventually. There's really good buzz around Rust now, and it's not even 'production ready'.

nly 12y ago
Total language displacement is a pretty rare event, and technical superiority isn't even a prerequisite. And I happen to like having a preprocessor.
- DCKing 12y ago
  Yes, it's far too early to tell. The good thing to take away is that, at the moment, the answer to "is Rust a viable threat to C/C++?" does not seem to be a categorical no. The same cannot be said for other languages in the area, such as Pascal, D, Ada, Nimrod and even Go, although all of these languages have their use. Any adoption of Rust in areas where people otherwise use C/C++ is an improvement I think. It doesn't have to be total displacement, and that will never happen.
  - pjmlp 12y ago
    Any systems programming language can displace C. You just need a successful OS vendor pushing the said language as only means to target their OS.
    - DCKing 12y ago
      I think the reason many people are rooting for Rust is because it's got comprehensively better features than competing languages. I'm not talking just about memory safety, but also its adoption of functional language features. I'm of the opinion that immutability-by-default, pattern matching, first-class functions and real macros combined with no garbage collection are a Very Good Thing™ for this type of language (and I'm not the only one). So yeah, I disagree that any systems programming language can displace C. Other system languages simply don't come with the same amount of improvements that Rust offers.
      - pjmlp 12y ago
        > So yeah, I disagree that any systems programming language can displace C. Other system languages simply don't come with the same amount of improvements that Rust offers. So, given my premise, how do you target super-cool-everyone-wants-it-os that only offers new-cool-language as their system programming language in the OS SDK? Are you going to write a C compiler in new-cool-language to be able to keep on using C?
        dllthomas 12y ago
        Why not cross compile?
        pjmlp 12y ago
        You could as well. In case case the C runtime has to be implemented on top of the new-cool-language ABI, as it is the only way the vendor supports creating software for their system. What I am describing is not that different from thirty years ago when C was a UNIX only language, and other OS had other languages as their systems programming language.
        MaulingMonkey 12y ago
        > super-cool-everyone-wants-it-os that only offers new-cool-language I'd suggest that these are fundamentally incompatible statements. "Only offers new-cool-language" is another way of saying "it's a pain in the ass to port to - you have to rewrite your whole app!" if you're coming from anywhere that's ever touched not-quite-as-cool-language.
  - fithisux 12y ago
    D is a viable alternative to C++, period, not necessarily to C. I believe a rewrite of Xorg in D would be googd. The only problem with all these languages is that you cannot e.g. create a dll in Ada and generate appropriate headers to use it in C, even more in Go. In this respect I feel that this is the real problem here. The biggest obstacle is the C++ legacy code.
    - DCKing 12y ago
      D is absolutely a viable alternative to C++ and probably C. There's no argument there. D is not a viable threat to C/C++ (this is what I said!), as noone is really thinking that D will actively displace the use of C/C++ in many projects in the future. The same goes for all the other languages I mention. In my perception there's a buzz around Rust that indicates it might be viewed differently.
    - kvark 12y ago
      Can you use D without GC? How would it look like? If very restricted, then I don't see it as a viable C++ alternative. I'm ok with GC on a web server, but coreutils are better without it.
      - Shorel 12y ago
        It is possible to allocate objects in the stack (objects without polymorphism, defined with the struct keyword). No use of heap and GC in that case at all. It's not that different to using C++ objects in the stack. If by no GC you mean to use heap allocated objects with manually managed destructors, then I think the answer is no.
        kvark 12y ago
        I'm looking at "http://dlang.org/garbage.html" http://dlang.org/garbage.html" section "D Operations That Involve the Garbage Collector", and there are some pretty interesting things on the list that require GC: all dynamic arrays, associative arrays, closures, asserts. Can you even read a file without these?
- hendzen 12y ago
  Having a preprocessor is nice. Having a real macro system is nicer.
  - DSMan195276 12y ago
    I consider them to serve different purposes. For stuff like the Linux Kernel, the preprocessor is great because it can be used with any number of different types of files the Linux Kernel has in it's source. The Kernel configuration basically just becomes a bunch of #define's, and you can access that information from C, assembly, linker scripts, etc...
    - mercurial 12y ago
      How is this nicer than a configuration file template?
- baq 12y ago
  the nice thing about cpp is that you can use it on any file.
  - lomnakkus 12y ago
    ... unless the file contents happen to clash with CPP syntax.
Dewie 12y ago
Developing a lot of relatively small programs seems like a good way to get experience with the language, find issues with it, report them, etc.
userbinator 12y ago
I hope that never happens, because I think such a world would be extremely dystopian. Strong safety guarantees sound very beneficial at first ("safe" anything in general tends to evoke that response), but as shocking as it may seem, a lot of the freedom we have today is a result of using "unsafe" languages like C: iOS jailbreaks, Android rooting, homebrew on game consoles, and many other examples of freeing one's devices from restrictions imposed by the original manufacturer and giving control back to the user depend on this. These bugs and vulnerabilities, although they can be exploited maliciously, are in some ways like an escape hatch from the tyranny of corporate control. If strongly safe languages become the norm, all these would disappear and our computing experience become even more locked-down and restricted. The thought of them being used for DRM is scary (I remember reading an academic paper that suggeted this as one of their applications, and that's one of the thing that provoked me into really starting to think about this.) Even open-source software where safer languages appear most beneficial can be used against the user. Ultimately is a security vs. freedom tradeoff, and I think we've sacrificed too much of the latter already.
- DCKing 12y ago
  I'm baffled by that opinion. The fact that memory-unsafe software keeps on being produced in C/C++ is a good thing? The capabilities of criminals to run local (or remote!) root exploits on many devices is offset by the fact that some hackers can tinker with them? Freedom should be achieved in different ways. Please don't make freedom and security contradictions.
  - userbinator 12y ago
    Yes, it's definitely controversial but I think a little bit of insecurity is a good thing but not too much -- the question is how much. Consider that had the NSA been far more secure in their processes, the whole Snowden thing may have never happened... which is somewhat ironic. > Freedom should be achieved in different ways. Please don't make freedom and security contradictions. In an ideal world, they wouldn't be. Unfortunately that's not how it is in reality.
    - 12y ago
gkya 12y ago
The best advantage of writing libraries in C is that it allows the library to be usable via FFIs in many other languages. Also, C is extensively standardised, widely used and thus greatly test-covered. This is a nice property of the language, as the programmers can be sure that as long as they follow the standards, they'll find a compiler to compile the programs they write. I have not used Rust for more that «Hello world!», but I know that I'd regret sooner or later, if I wrote a multi-million line project in a language that is not somehow standardised. Also, memory safety is hard to enforce, I reckon, while controlling the memory hardware, which is what an operating system like Linux* has to do. Rust can be used, but still, there are many unsafe things that OS has to do, like moving and assigning pages, managing which programs use which pages, swapping, etc.; which, I reckon, requires knowledge and usage of physical memory addresses and access to individual bytes. Rust may be an appropriate and advantageous language to use for the non-core parts of a microkernel, though. * I acknowledge that Linux is not an operating system per se.
- DCKing 12y ago
  Rust has memory safety by default. However, it can do memory unsafe things in special blocks[1]. So it can do everything low level that C can, including controlling memory hardware [2]. It does unsafe things only in special blocks that can be specifically audited. That's part of why I find it so promising. C has no memory safety by default. So if you want to audit your C program for memory safety problems, those problems can be anywhere. Even if that C program/component doesn't actually need such low level access in the first place! [1]: http://static.rust-lang.org/doc/master/rust.html#unsafety http://static.rust-lang.org/doc/master/rust.html#unsafety [2]: Here's a list of (hobby) kernels written in Rust: https://github.com/mozilla/rust/wiki/Operating-system-development https://github.com/mozilla/rust/wiki/Operating-system-develo...
  - gkya 12y ago
    Everytime I say something negative about Rust, the counterarguments push me to learn the language. I'll definitely check out the kernels page, thanks a lot for that. With your comments I have to concur. I have also read a comment on name-mangling somewhere on this thread, probably one that you've written. If C can be replaced with Rust for most-if-not-all applications in future, it is a step forwards IMO.
andrewflnr 12y ago
I don't think it makes sense to rewrite the Linux kernel in Rust. As long as we're dreaming, let's talk about a new OS without all the legacy cruft. Be sure to make it hard to lock the user out, so userbinator is happy too, but (again) as long as we're dreaming that's on the agenda too.

by DCKing 12y ago

nly 12y ago

Total language displacement is a pretty rare event, and technical superiority isn't even a prerequisite. And I happen to like having a preprocessor.

DCKing 12y ago
Yes, it's far too early to tell. The good thing to take away is that, at the moment, the answer to "is Rust a viable threat to C/C++?" does not seem to be a categorical no. The same cannot be said for other languages in the area, such as Pascal, D, Ada, Nimrod and even Go, although all of these languages have their use. Any adoption of Rust in areas where people otherwise use C/C++ is an improvement I think. It doesn't have to be total displacement, and that will never happen.
- pjmlp 12y ago
  Any systems programming language can displace C. You just need a successful OS vendor pushing the said language as only means to target their OS.
  - DCKing 12y ago
    I think the reason many people are rooting for Rust is because it's got comprehensively better features than competing languages. I'm not talking just about memory safety, but also its adoption of functional language features. I'm of the opinion that immutability-by-default, pattern matching, first-class functions and real macros combined with no garbage collection are a Very Good Thing™ for this type of language (and I'm not the only one). So yeah, I disagree that any systems programming language can displace C. Other system languages simply don't come with the same amount of improvements that Rust offers.
    - pjmlp 12y ago
      > So yeah, I disagree that any systems programming language can displace C. Other system languages simply don't come with the same amount of improvements that Rust offers. So, given my premise, how do you target super-cool-everyone-wants-it-os that only offers new-cool-language as their system programming language in the OS SDK? Are you going to write a C compiler in new-cool-language to be able to keep on using C?
      - dllthomas 12y ago
        Why not cross compile?
        pjmlp 12y ago
        You could as well. In case case the C runtime has to be implemented on top of the new-cool-language ABI, as it is the only way the vendor supports creating software for their system. What I am describing is not that different from thirty years ago when C was a UNIX only language, and other OS had other languages as their systems programming language.
      - MaulingMonkey 12y ago
        > super-cool-everyone-wants-it-os that only offers new-cool-language I'd suggest that these are fundamentally incompatible statements. "Only offers new-cool-language" is another way of saying "it's a pain in the ass to port to - you have to rewrite your whole app!" if you're coming from anywhere that's ever touched not-quite-as-cool-language.
- fithisux 12y ago
  D is a viable alternative to C++, period, not necessarily to C. I believe a rewrite of Xorg in D would be googd. The only problem with all these languages is that you cannot e.g. create a dll in Ada and generate appropriate headers to use it in C, even more in Go. In this respect I feel that this is the real problem here. The biggest obstacle is the C++ legacy code.
  - DCKing 12y ago
    D is absolutely a viable alternative to C++ and probably C. There's no argument there. D is not a viable threat to C/C++ (this is what I said!), as noone is really thinking that D will actively displace the use of C/C++ in many projects in the future. The same goes for all the other languages I mention. In my perception there's a buzz around Rust that indicates it might be viewed differently.
  - kvark 12y ago
    Can you use D without GC? How would it look like? If very restricted, then I don't see it as a viable C++ alternative. I'm ok with GC on a web server, but coreutils are better without it.
    - Shorel 12y ago
      It is possible to allocate objects in the stack (objects without polymorphism, defined with the struct keyword). No use of heap and GC in that case at all. It's not that different to using C++ objects in the stack. If by no GC you mean to use heap allocated objects with manually managed destructors, then I think the answer is no.
      - kvark 12y ago
        I'm looking at "http://dlang.org/garbage.html" http://dlang.org/garbage.html" section "D Operations That Involve the Garbage Collector", and there are some pretty interesting things on the list that require GC: all dynamic arrays, associative arrays, closures, asserts. Can you even read a file without these?
hendzen 12y ago
Having a preprocessor is nice. Having a real macro system is nicer.
- DSMan195276 12y ago
  I consider them to serve different purposes. For stuff like the Linux Kernel, the preprocessor is great because it can be used with any number of different types of files the Linux Kernel has in it's source. The Kernel configuration basically just becomes a bunch of #define's, and you can access that information from C, assembly, linker scripts, etc...
  - mercurial 12y ago
    How is this nicer than a configuration file template?
baq 12y ago
the nice thing about cpp is that you can use it on any file.
- lomnakkus 12y ago
  ... unless the file contents happen to clash with CPP syntax.

Dewie 12y ago

Developing a lot of relatively small programs seems like a good way to get experience with the language, find issues with it, report them, etc.

userbinator 12y ago

I hope that never happens, because I think such a world would be extremely dystopian. Strong safety guarantees sound very beneficial at first ("safe" anything in general tends to evoke that response), but as shocking as it may seem, a lot of the freedom we have today is a result of using "unsafe" languages like C: iOS jailbreaks, Android rooting, homebrew on game consoles, and many other examples of freeing one's devices from restrictions imposed by the original manufacturer and giving control back to the user depend on this. These bugs and vulnerabilities, although they can be exploited maliciously, are in some ways like an escape hatch from the tyranny of corporate control. If strongly safe languages become the norm, all these would disappear and our computing experience become even more locked-down and restricted. The thought of them being used for DRM is scary (I remember reading an academic paper that suggeted this as one of their applications, and that's one of the thing that provoked me into really starting to think about this.) Even open-source software where safer languages appear most beneficial can be used against the user. Ultimately is a security vs. freedom tradeoff, and I think we've sacrificed too much of the latter already.

DCKing 12y ago
I'm baffled by that opinion. The fact that memory-unsafe software keeps on being produced in C/C++ is a good thing? The capabilities of criminals to run local (or remote!) root exploits on many devices is offset by the fact that some hackers can tinker with them? Freedom should be achieved in different ways. Please don't make freedom and security contradictions.
- userbinator 12y ago
  Yes, it's definitely controversial but I think a little bit of insecurity is a good thing but not too much -- the question is how much. Consider that had the NSA been far more secure in their processes, the whole Snowden thing may have never happened... which is somewhat ironic. > Freedom should be achieved in different ways. Please don't make freedom and security contradictions. In an ideal world, they wouldn't be. Unfortunately that's not how it is in reality.
  - 12y ago

gkya 12y ago

The best advantage of writing libraries in C is that it allows the library to be usable via FFIs in many other languages. Also, C is extensively standardised, widely used and thus greatly test-covered. This is a nice property of the language, as the programmers can be sure that as long as they follow the standards, they'll find a compiler to compile the programs they write. I have not used Rust for more that «Hello world!», but I know that I'd regret sooner or later, if I wrote a multi-million line project in a language that is not somehow standardised. Also, memory safety is hard to enforce, I reckon, while controlling the memory hardware, which is what an operating system like Linux* has to do. Rust can be used, but still, there are many unsafe things that OS has to do, like moving and assigning pages, managing which programs use which pages, swapping, etc.; which, I reckon, requires knowledge and usage of physical memory addresses and access to individual bytes. Rust may be an appropriate and advantageous language to use for the non-core parts of a microkernel, though. * I acknowledge that Linux is not an operating system per se.

DCKing 12y ago
Rust has memory safety by default. However, it can do memory unsafe things in special blocks[1]. So it can do everything low level that C can, including controlling memory hardware [2]. It does unsafe things only in special blocks that can be specifically audited. That's part of why I find it so promising. C has no memory safety by default. So if you want to audit your C program for memory safety problems, those problems can be anywhere. Even if that C program/component doesn't actually need such low level access in the first place! [1]: http://static.rust-lang.org/doc/master/rust.html#unsafety http://static.rust-lang.org/doc/master/rust.html#unsafety [2]: Here's a list of (hobby) kernels written in Rust: https://github.com/mozilla/rust/wiki/Operating-system-development https://github.com/mozilla/rust/wiki/Operating-system-develo...
- gkya 12y ago
  Everytime I say something negative about Rust, the counterarguments push me to learn the language. I'll definitely check out the kernels page, thanks a lot for that. With your comments I have to concur. I have also read a comment on name-mangling somewhere on this thread, probably one that you've written. If C can be replaced with Rust for most-if-not-all applications in future, it is a step forwards IMO.

andrewflnr 12y ago

I don't think it makes sense to rewrite the Linux kernel in Rust. As long as we're dreaming, let's talk about a new OS without all the legacy cruft. Be sure to make it hard to lock the user out, so userbinator is happy too, but (again) as long as we're dreaming that's on the agenda too.