9 ms·

Once you've made the decision to leave C for a systems programming project, why would one not just go over to Rust?

quacker 10y ago
Maybe easier integration with existing C libraries? They give an example of a tetris clone in Zig. This is how they include GLFW with Zig: https://github.com/andrewrk/tetris/blob/master/src/c.zig https://github.com/andrewrk/tetris/blob/master/src/c.zig and all other locations in the project just import this c.zig file. In contrast in Rust, I think you have to actually declare all the functions you want to use from a C library. For example: https://github.com/PistonDevelopers/glfw-rs/blob/master/src/ffi/mod.rs#L331 https://github.com/PistonDevelopers/glfw-rs/blob/master/src/....
- tomjakubowski 10y ago
  There are C library binding generators for Rust which do the boring work for you. It's not perfect, but rust-bindgen was pretty good last time I tried it (~15 months ago): https://github.com/Yamakaky/rust-bindgen https://github.com/Yamakaky/rust-bindgen
  - skissane 10y ago
    When a language has built-in support for easy binding to C, that's a positive. When other languages such as Rust offer that feature through external tools, that's not as good, since I need to evaluate which of those external tools to use (when there is more than one), and it is something else to download/install/learn and another step to add to the build process. So it looks to me like Zig handles this better than Rust does (of course, Rust has clear advantages over Zig in other areas: much more mature / widely used, and more advanced memory management.)
  - ycombinatorMan 10y ago
    not nearly as attractive as inline C or direct C imports
    - deleted 10y ago
      [deleted]
    - Ygg2 10y ago
      Pfft, pretty sure you could inline C in Rust. No one was brave enough to develop said compiler plugin.
      - Gankro 10y ago
        C++ close enough? https://github.com/mystor/rust-cpp https://github.com/mystor/rust-cpp
        Ygg2 10y ago
        Eh, C++ isn't really C :P I kid, it's really impressive work.
- kbenson 10y ago
  I think there exists, or work has been done on, a tool to auto generate that data for you. So not quite as simple, but possibly more fine grained control.
c3534l 10y ago
Yeah, I really hope Rust becomes the default C replacement. It's such a well-designed language, it's just very early in its development right now.
- aninteger 10y ago
  Rust seems very complex and C is more about simplicity (in the sense that K&R is a short read). Other languages with the same spirit of simplicity would be Tcl and perhaps Go. I just wish Go had more supported machine architectures.
  - ocschwar 10y ago
    My feeling is that one should use Python or Go to prototype a program, and then move to Rust to make it systems-ready.
andrewchambers 10y ago
Yes. One flavour of icecream is all we need. (I hope people can see the sarcasm)
- nickpsecurity 10y ago
  "My qbe C frontend is actually written in myrddin which is a lot like rust/ocaml. To be honest, C is not well suited to places where there is adversarial input such as servers, but when it comes to logical correctness of code I do not see amazing benefits from languages like ocaml." Did you mean two? Or did you come to new conclusions after that experience? Or did I misunderstand that entirely? ;)
  - andrewchambers 10y ago
    There ARE benefits to correctness from better languages, just not as amazing as people think. I'm just saying a vulnerability in C is just going to be an out of bounds exception in another language. both cases the code is not correct, one is just safer than the other when it comes to exploits. Keep making more languages, we can't know for sure if we don't try.
    - nickpsecurity 10y ago
      I can see where you're going but I don't think it's correct. There are clearly cases where an error will mess you up whether it goes as far as in C or not. Other times, the language or tooling prevents the error before runtime to ensure correctness. Are you aware of the benefits of Design-by-Contract (Ada/Eiffel), static proving (SPARK), or dependent types (ATS), though? The correctness criteria you can encode in them can straight-up prevent errors at interface or algorithmic expression levels. Three of these have been used for low-level code with two often in real-time and one for an 8-bitter. Depending on automation or interactive use involved, the errors caught at compile-time can increase pretty far past what a basic, low-level, type system can do. So, we already know we can knock out extra classes of errors with such languages. It was proven in theory and in the field. Using or improving them is just good engineering. We can also make more languages in trial-and-error discovery process to see if we find more benefits. Exceeding C's benefits, though, is already empirically proven to be worthwhile whether it's a Myrddin, a SPARK, or an ATS.
DSMan195276 10y ago
I've thought alot about this before. Rust doesn't really have very great interoperability with C - most languages really don't, because the API for C programs revolves around functions, structs, macros, etc. Most languages can only really get part of that, and then the rest gets essentially a separate implementation in the language you're porting too - leading to a certain amount of manual duplication and intervention necessary (We don't call it porting when you use a C library in C). Design goals Rust has made compound the issue a bit more: For example, Rust uses the C++ ABI, not C. Rust can't generally use header files directly. The Rust<->C conversion loses a lot of information and can result in fairly messy code by Rust standards, etc. This makes combining Rust into already existing C code a hassle, as it is generally worse then even just trying to use C and C++ together which is already fairly annoying and error-prone. This is compounded by Rust's safety goals which generally require a different design to a problem then the "C-style" approach would be - IE. You're probably not going to get good Rust code by simply replacing a .c file with a Rust file, because the entire time you're going to have to make use of the unsafe C functions that your program includes. Perhaps the bottom line is that (for good reason) Rust is much more then just an improved C. And because of that, combining C and Rust is always going to feel like combining two separate systems together with a compatibility layer in-between - because that's really what it is - and that's just not very attractive. I know little about Zig (I'm reading about it for the first time now) and don't at all predict it to replace C. That said, I would love a language which has a focus on maintaining very good compatibility with C while fixing the various pieces of its design that are fixable within the bounds of the language. For example, I noticed it mentioned in the README that in Zig that pointers are nonnull by default, and can be made nullable by adding the 'maybe' attribute. This is a feature I would love in C, but really isn't there (gcc has a nonnull attribute, but it is really essentially useless and nothing like you'd want). Essentially, I would like a language where it feels like writing code for the same system, but in a different (better) syntax - where I can drop it into a project and it works together with the system like any other .c file (Though with a different compiler, obviously), but the code inside is much better then what you can do in standard C. I think that such a language could retain the reasons why people (like me) still like C, while fixing a lot of the uglier sides to the language that everybody is aware of but aren't going to get fixed any time soon. And perhaps most importantly, I think such a language is definitely possible (Though it may not be able to employ all the features you may want) - but I don't have the time nor probably the skills to really do it well besides list off the things it should fix and shouldn't fix. As for starting a project though, if you ignore difficulty to learn then I would agree with you: There's probably little reason not to just go for Rust if you're already willing to learn a new language. For most projects the issues I outlined above don't really matter assuming the entire project is written in Rust - besides the want for a language closer to C in design. That said, I readily concede that I have no idea if Rust's borrow-checking semantics could ever work without the extra features they added that take the design away from being 'C-like' - and considering that's one of the definitive features of Rust, is easily worth losing the 'C-like' detail if it is necessary. But when considering a project like the Linux Kernel, the GNU coreutils, git, GTK, and other various large projects where conversion to Rust is probably impossible without a complete rewrite, being able to use a 'better' C while still retaining the aspects that people like would probably be a nice step in the right direction. The chances of it happening are nil, but it would still be a step in the right direction.
daurnimator 10y ago
One of my biggest reasons is the lack of ability to handle OOM when using the standard library. see e.g. https://internals.rust-lang.org/t/could-we-support-unwinding-from-oom-at-least-for-collections/3673/17 https://internals.rust-lang.org/t/could-we-support-unwinding...
- whyever 10y ago
  How can you handle OOM if your process gets killed by the kernel for using to much memory?
  - daurnimator 10y ago
    By never going that far. Turn off overcommit; I advise to never run with it in production.
teacup50 10y ago
Among other things, systems programming projects generally require stability of language syntax, API, and ABI. In terms of ABI stability, Rust has none. In terms of API stability, they seem willing to drop features within a major release cycle or two. In terms of language stability, they seem to only guarantee stability within one major release (e.g. 1.x). Rewriting for the sake of language updates is a huge resource drain when you're talking about code bases with lifetimes that are likely to be longer than their authors'. For reference, just about every major shipping OS contains significant LoC dating back to the 70s or 80s.
- Gankro 10y ago
  > In terms of API stability, they seem willing to drop features within a major release cycle or two. I don't think any feature/api that was at one point marked as stable post 1.0 (when they started making any guarantees) has ever been removed. > In terms of language stability, they seem to only guarantee stability within one major release (e.g. 1.x). While it's true that 2.x has the rights to break everything, this is incredibly dishonest to state in a vacuum, because it's a well established point that 2.x should never exist. The devs want all code to work forever, and only a catastrophe would push them to pull the lever. They have of course reserved the right to require fixes in special cases -- e.g. fixing a bug in the type checker might break some code, and that's acceptable. Although even then they'll try to phase in the fix over a few releases. Every release is tested against the entire crates.io ecosystem to try to catch these regressions. You are absolutely correct on ABI stability, though.
  - teacup50 10y ago
    Given the litany of deprecation markers applied to existing APIs, one must presume the intention of removing them, no?
    - Manishearth 10y ago
      Not necessarily. I suspect even in the case of 2.0, most if not all of those apis will survive. Deprecation markers exist to encourage people to use newer, better APIs. I suspect that even if 2.0 happened, the only apis that would be removed would be ones that we're reasonably sure nobody uses (via crater), and even then there would be debate. And like Gankro said, 2.0 is a thing that's not supposed to happen in the first place.
Koshkin 10y ago
Rust? Maybe. But then, why not Go or Swift or Lisp? Personally, if I were to be expelled from C/C++ paradise, I would try Oberon - the only language I know that can compete with C in its simplicity and, despite normally being perceived as garbage-collected, the ability to serve as a truly systems programming language.
- mordocai 10y ago
  As far as vs Go or Swift or Lisp, Rust is much "closer to the hardware"(as discussed in other threads nothing is really close to the hardware anymore) than the other languages, go and most lisps use GC which causes problems in many systems language situations, and last I heard swift still has lackluster cross platform support. I don't really know anything about Oberon so can't speak to that. P.S. Personally, all my hobby projects are in lisp. I write applications though, not system stuff.
  - pjmlp 10y ago
    Oberon was used for writing a complete graphical workstation OS used during the mid-90 at the ETHZ in Switzerland. It was a language and OS, following the same spirit of Xerox PARC OSes.
  - nickpsecurity 10y ago
    The A2 Bluebottle OS is latest incarnation of Oberon OS with GUI and very responsive. Languages like Oberon can do unsafe stuff for low-level work like OS's. You just use manual, memory management and UNSAFE keyword. Rest that can be GC'd, bounds-checked, etc is by default.
- ziotom78 10y ago
  A few months ago, I considered Oberon as a viable alternative to C for my pet projects. Horace, after some time spent playing with it, I was scared by a fewserious limitations: (1) there is no support for UTF-8 strings, native strings are just sequences of ASCII characters, (2) lack of libraries and available bindings (e.g., SQLite, GSL, FFTW...), (3) scarcity of tools like package managers and Doxygen-like tools, (4) very few resources available on the web (Wirth's book is exceptional, but it does not cover use cases that are common in 2016.)

Maybe easier integration with existing C libraries? They give an example of a tetris clone in Zig. This is how they include GLFW with Zig: https://github.com/andrewrk/tetris/blob/master/src/c.zig https://github.com/andrewrk/tetris/blob/master/src/c.zig and all other locations in the project just import this c.zig file. In contrast in Rust, I think you have to actually declare all the functions you want to use from a C library. For example: https://github.com/PistonDevelopers/glfw-rs/blob/master/src/ffi/mod.rs#L331 https://github.com/PistonDevelopers/glfw-rs/blob/master/src/....

tomjakubowski 10y ago
There are C library binding generators for Rust which do the boring work for you. It's not perfect, but rust-bindgen was pretty good last time I tried it (~15 months ago): https://github.com/Yamakaky/rust-bindgen https://github.com/Yamakaky/rust-bindgen
- skissane 10y ago
  When a language has built-in support for easy binding to C, that's a positive. When other languages such as Rust offer that feature through external tools, that's not as good, since I need to evaluate which of those external tools to use (when there is more than one), and it is something else to download/install/learn and another step to add to the build process. So it looks to me like Zig handles this better than Rust does (of course, Rust has clear advantages over Zig in other areas: much more mature / widely used, and more advanced memory management.)
- ycombinatorMan 10y ago
  not nearly as attractive as inline C or direct C imports
  - deleted 10y ago
    [deleted]
  - Ygg2 10y ago
    Pfft, pretty sure you could inline C in Rust. No one was brave enough to develop said compiler plugin.
    - Gankro 10y ago
      C++ close enough? https://github.com/mystor/rust-cpp https://github.com/mystor/rust-cpp
      - Ygg2 10y ago
        Eh, C++ isn't really C :P I kid, it's really impressive work.
kbenson 10y ago
I think there exists, or work has been done on, a tool to auto generate that data for you. So not quite as simple, but possibly more fine grained control.

c3534l 10y ago

Yeah, I really hope Rust becomes the default C replacement. It's such a well-designed language, it's just very early in its development right now.

aninteger 10y ago
Rust seems very complex and C is more about simplicity (in the sense that K&R is a short read). Other languages with the same spirit of simplicity would be Tcl and perhaps Go. I just wish Go had more supported machine architectures.
- ocschwar 10y ago
  My feeling is that one should use Python or Go to prototype a program, and then move to Rust to make it systems-ready.

andrewchambers 10y ago

Yes. One flavour of icecream is all we need. (I hope people can see the sarcasm)

nickpsecurity 10y ago
"My qbe C frontend is actually written in myrddin which is a lot like rust/ocaml. To be honest, C is not well suited to places where there is adversarial input such as servers, but when it comes to logical correctness of code I do not see amazing benefits from languages like ocaml." Did you mean two? Or did you come to new conclusions after that experience? Or did I misunderstand that entirely? ;)
- andrewchambers 10y ago
  There ARE benefits to correctness from better languages, just not as amazing as people think. I'm just saying a vulnerability in C is just going to be an out of bounds exception in another language. both cases the code is not correct, one is just safer than the other when it comes to exploits. Keep making more languages, we can't know for sure if we don't try.
  - nickpsecurity 10y ago
    I can see where you're going but I don't think it's correct. There are clearly cases where an error will mess you up whether it goes as far as in C or not. Other times, the language or tooling prevents the error before runtime to ensure correctness. Are you aware of the benefits of Design-by-Contract (Ada/Eiffel), static proving (SPARK), or dependent types (ATS), though? The correctness criteria you can encode in them can straight-up prevent errors at interface or algorithmic expression levels. Three of these have been used for low-level code with two often in real-time and one for an 8-bitter. Depending on automation or interactive use involved, the errors caught at compile-time can increase pretty far past what a basic, low-level, type system can do. So, we already know we can knock out extra classes of errors with such languages. It was proven in theory and in the field. Using or improving them is just good engineering. We can also make more languages in trial-and-error discovery process to see if we find more benefits. Exceeding C's benefits, though, is already empirically proven to be worthwhile whether it's a Myrddin, a SPARK, or an ATS.

DSMan195276 10y ago

I've thought alot about this before. Rust doesn't really have very great interoperability with C - most languages really don't, because the API for C programs revolves around functions, structs, macros, etc. Most languages can only really get part of that, and then the rest gets essentially a separate implementation in the language you're porting too - leading to a certain amount of manual duplication and intervention necessary (We don't call it porting when you use a C library in C). Design goals Rust has made compound the issue a bit more: For example, Rust uses the C++ ABI, not C. Rust can't generally use header files directly. The Rust<->C conversion loses a lot of information and can result in fairly messy code by Rust standards, etc. This makes combining Rust into already existing C code a hassle, as it is generally worse then even just trying to use C and C++ together which is already fairly annoying and error-prone. This is compounded by Rust's safety goals which generally require a different design to a problem then the "C-style" approach would be - IE. You're probably not going to get good Rust code by simply replacing a .c file with a Rust file, because the entire time you're going to have to make use of the unsafe C functions that your program includes. Perhaps the bottom line is that (for good reason) Rust is much more then just an improved C. And because of that, combining C and Rust is always going to feel like combining two separate systems together with a compatibility layer in-between - because that's really what it is - and that's just not very attractive. I know little about Zig (I'm reading about it for the first time now) and don't at all predict it to replace C. That said, I would love a language which has a focus on maintaining very good compatibility with C while fixing the various pieces of its design that are fixable within the bounds of the language. For example, I noticed it mentioned in the README that in Zig that pointers are nonnull by default, and can be made nullable by adding the 'maybe' attribute. This is a feature I would love in C, but really isn't there (gcc has a nonnull attribute, but it is really essentially useless and nothing like you'd want). Essentially, I would like a language where it feels like writing code for the same system, but in a different (better) syntax - where I can drop it into a project and it works together with the system like any other .c file (Though with a different compiler, obviously), but the code inside is much better then what you can do in standard C. I think that such a language could retain the reasons why people (like me) still like C, while fixing a lot of the uglier sides to the language that everybody is aware of but aren't going to get fixed any time soon. And perhaps most importantly, I think such a language is definitely possible (Though it may not be able to employ all the features you may want) - but I don't have the time nor probably the skills to really do it well besides list off the things it should fix and shouldn't fix. As for starting a project though, if you ignore difficulty to learn then I would agree with you: There's probably little reason not to just go for Rust if you're already willing to learn a new language. For most projects the issues I outlined above don't really matter assuming the entire project is written in Rust - besides the want for a language closer to C in design. That said, I readily concede that I have no idea if Rust's borrow-checking semantics could ever work without the extra features they added that take the design away from being 'C-like' - and considering that's one of the definitive features of Rust, is easily worth losing the 'C-like' detail if it is necessary. But when considering a project like the Linux Kernel, the GNU coreutils, git, GTK, and other various large projects where conversion to Rust is probably impossible without a complete rewrite, being able to use a 'better' C while still retaining the aspects that people like would probably be a nice step in the right direction. The chances of it happening are nil, but it would still be a step in the right direction.

daurnimator 10y ago

One of my biggest reasons is the lack of ability to handle OOM when using the standard library. see e.g. https://internals.rust-lang.org/t/could-we-support-unwinding-from-oom-at-least-for-collections/3673/17 https://internals.rust-lang.org/t/could-we-support-unwinding...

whyever 10y ago
How can you handle OOM if your process gets killed by the kernel for using to much memory?
- daurnimator 10y ago
  By never going that far. Turn off overcommit; I advise to never run with it in production.

teacup50 10y ago

Among other things, systems programming projects generally require stability of language syntax, API, and ABI. In terms of ABI stability, Rust has none. In terms of API stability, they seem willing to drop features within a major release cycle or two. In terms of language stability, they seem to only guarantee stability within one major release (e.g. 1.x). Rewriting for the sake of language updates is a huge resource drain when you're talking about code bases with lifetimes that are likely to be longer than their authors'. For reference, just about every major shipping OS contains significant LoC dating back to the 70s or 80s.

Gankro 10y ago
> In terms of API stability, they seem willing to drop features within a major release cycle or two. I don't think any feature/api that was at one point marked as stable post 1.0 (when they started making any guarantees) has ever been removed. > In terms of language stability, they seem to only guarantee stability within one major release (e.g. 1.x). While it's true that 2.x has the rights to break everything, this is incredibly dishonest to state in a vacuum, because it's a well established point that 2.x should never exist. The devs want all code to work forever, and only a catastrophe would push them to pull the lever. They have of course reserved the right to require fixes in special cases -- e.g. fixing a bug in the type checker might break some code, and that's acceptable. Although even then they'll try to phase in the fix over a few releases. Every release is tested against the entire crates.io ecosystem to try to catch these regressions. You are absolutely correct on ABI stability, though.
- teacup50 10y ago
  Given the litany of deprecation markers applied to existing APIs, one must presume the intention of removing them, no?
  - Manishearth 10y ago
    Not necessarily. I suspect even in the case of 2.0, most if not all of those apis will survive. Deprecation markers exist to encourage people to use newer, better APIs. I suspect that even if 2.0 happened, the only apis that would be removed would be ones that we're reasonably sure nobody uses (via crater), and even then there would be debate. And like Gankro said, 2.0 is a thing that's not supposed to happen in the first place.

Koshkin 10y ago

Rust? Maybe. But then, why not Go or Swift or Lisp? Personally, if I were to be expelled from C/C++ paradise, I would try Oberon - the only language I know that can compete with C in its simplicity and, despite normally being perceived as garbage-collected, the ability to serve as a truly systems programming language.

mordocai 10y ago
As far as vs Go or Swift or Lisp, Rust is much "closer to the hardware"(as discussed in other threads nothing is really close to the hardware anymore) than the other languages, go and most lisps use GC which causes problems in many systems language situations, and last I heard swift still has lackluster cross platform support. I don't really know anything about Oberon so can't speak to that. P.S. Personally, all my hobby projects are in lisp. I write applications though, not system stuff.
- pjmlp 10y ago
  Oberon was used for writing a complete graphical workstation OS used during the mid-90 at the ETHZ in Switzerland. It was a language and OS, following the same spirit of Xerox PARC OSes.
- nickpsecurity 10y ago
  The A2 Bluebottle OS is latest incarnation of Oberon OS with GUI and very responsive. Languages like Oberon can do unsafe stuff for low-level work like OS's. You just use manual, memory management and UNSAFE keyword. Rest that can be GC'd, bounds-checked, etc is by default.
ziotom78 10y ago
A few months ago, I considered Oberon as a viable alternative to C for my pet projects. Horace, after some time spent playing with it, I was scared by a fewserious limitations: (1) there is no support for UTF-8 strings, native strings are just sequences of ASCII characters, (2) lack of libraries and available bindings (e.g., SQLite, GSL, FFTW...), (3) scarcity of tools like package managers and Doxygen-like tools, (4) very few resources available on the web (Wirth's book is exceptional, but it does not cover use cases that are common in 2016.)