6 ms·

> Low-level Operating Systems Sr. User Experience Researcher Wow, I didn't even know this job existed. IMO Rust as a C++ replacement is fine, Rust as a C repl

> Low-level Operating Systems Sr. User Experience Researcher Wow, I didn't even know this job existed. IMO Rust as a C++ replacement is fine, Rust as a C replacement has more trade-offs than I still care to make. C is still far simpler (you can still read K&R in one day and keep most of the language in your head), has faster compile times, and the pain points cough macros are still often pain points in Rust. I think the biggest thing is that systems programming still requires a language that gets out of the way so you can focus on very technical problem domains where what the hardware is actually doing really matters. Rust is a language designed to get in your way and force you to create type abstractions. Adding too many abstraction can be exceedingly dangerous in an environment where not having a full view of how memory and hardware registers are laid out leads to even worse errors than just buffer overflows. IMO Rust makes this type of programmer more difficult just as C++ does.

loudmax 3y ago
Are tracking memory allocation or variable types not pain points for large complicated programs?
- softirq 3y ago
  In my experience as a kernel programmer tracing allocations isn't the hard part, it's keeping the correct view of hardware state and the different type of mappings at play, be it an MMU or IOMMU device mapping, and register state. Use after free bugs and overflows do happen, but there are more and more tools that come out every year that can find these things in C code, some of them are even hardware based. IMO the code quality of the kernel is very high and the defect rate isn't greater than projects I've worked on that use garbage collection.
ljlolel 3y ago
Try Zig as a C replacement.
- softirq 3y ago
  I'm not really looking for a replacement for C, the ecosystem of system programming is still really C centric, it would take a large shift in the industry for me to justify investing in another language. I've dabbled with Rust only because early support was merged into Linux. IMO most languages are only marginal improvements over the previous generation that don't outweigh fighting against the entrenchment of expertise, documentation, and integration that come with established languages. It's also hard to be a true expert at a low level domain and multiple programming languages unless you're willing to give up all of your free time.
  - moonchrome 3y ago
    Marginal improvements add up.
    - softirq 3y ago
      I agree, at some point they do build up to the point that change is inevitable. There's usually a lot of false starts along the way (AI is a good example of this). No matter what it is, there's going to be a lot of fighting against entrenchment and a lot of us old timers simply have to retire for newer developers, whether they be Rust developers to come in and elicit change.
  - vpastore 3y ago
    [dead]
- dleslie 3y ago
  Does Zig run on everything C can, including weird devices?[0] If the answer is still No, then it can't replace C. 0: https://en.wikipedia.org/wiki/Small_Device_C_Compiler https://en.wikipedia.org/wiki/Small_Device_C_Compiler
  - kristoff_it 3y ago
    Zig has been able for a while now to compile to C code, which is part of our bootstrap procedure now, so you can compile that output with an appropriate C compiler and target whatever you want. We do have plans for adding backends for unconventional targets eventually.
dannymi 3y ago
>Adding too many abstraction can be exceedingly dangerous in an environment where not having a full view of how memory and hardware registers are laid out leads to even worse errors than just buffer overflows. svd2rust is pretty good for having safe abstractions for hardware registers. That said, as an example, no, the type system doesn't prevent you from deallocating your DMA buffer while the hardware is using it--I don't think it's reasonable to add that to the type system (and the type system right now doesn't know about DMA).
- the__alchemist 3y ago
  Garbage in, garbage out! Svd2rust is a great tool, but the patching process (YAMLs) is currently not user friendly due to silent failures. Root cause is hardware makers putting out bugged SVDs that need patching. I think re DMA buffer lifetimes, the easy approach is static buffers; they never drop.
bfrog 3y ago
You can and do use simple pointers in Rust, nothing prevents this. The abstractions can be more used like static interfaces you want to reuse. E.g. a byte stream interface, a regmap interface, etc.
- 59nadir 3y ago
  I think there have been a few posts pointing out that the ergonomics around using just pointers in Rust is lacking severely in comparison to languages like Zig and Odin.
the__alchemist 3y ago
I think this is often a function of Rust OSS libs vice the language itself. The embedded Rust community has created and promoted bad APIs. I think it's worth pointing this out and building other APIs, even though this doesn't endear you to the Rust community. I'm worried people will get the wrong idea about embedded Rust ergonomics and attribute these APIs to the language itself.
- adamnemecek 3y ago
  Can you talk more about this? I'm very curious.
  - steveklabnik 3y ago
    I do not have as strong of feelings as your parent, but: 1. A lot of the APIs make use of the typestate pattern, which is nice, but also very verbose, and might turn many people off. 2. The generated API documentation for the lower level crates relies on you knowing the feel for how it generates the various APIs. It can take some time to get used to, especially if you're used to the better documentation of the broader ecosystem. 3. A bunch of the ecosystem crates assume the "I am running one program in ring0" kind of thing, and not "I have an RTOS" sort of case. See the discussion in https://github.com/rust-embedded/cortex-m/issues/233 https://github.com/rust-embedded/cortex-m/issues/233 for example.
  - bsder 3y ago
    Well, for starters, allocators. The standard library is now making adjustments around that, but it's not mainstream and most people don't use them and they don't get the same level of attention as the happy path. However, Rust, the language has its issues on embedded. Rust's ownership model is directly at odds with lots of embedded. These bits inside a register are owned by the ADC and these bits inside a register are owned by the DAC is not a happy thing in Rust. Lack of arbitrary sized integers and how they slice. Cargo. Quite annoying to deal with cargo and an embedded toolchain. The Rust embedded guys have done really good work if you're on ARM. If you're not, good luck. That having been said, if you have to go implement something like Reference Counting in something not Rust, you will weep tears of blood debugging every single time your reference counts go wrong. Embedded is engineering. It has tradeoffs. That's life.
deleted 3y ago
[deleted]
kaba0 3y ago
C has beyond useless “macros”, they should not be compared with Rust’s, that are actually useful.
- jimbob45 3y ago
  While that’s true, preprocessors are pretty trivial to write these days if you want macros that the language doesn’t support. Racket excels at this.
  - sanxiyn 3y ago
    Which preprocessor do you recommend for writing C?
    - jimbob45 3y ago
      https://stackoverflow.com/a/3685576 https://stackoverflow.com/a/3685576 There’s one approach. I wouldn’t personally recommend using macros outside of include guards and file inclusion. Still, if you need more functionality, the methods exist.
    - bsder 3y ago
      None. Use an actual different language. Ada, Rust, Zig, D, Lisp/Scheme/Racket, Tcl, Forth, etc. ... something other than C. Don't preprocess C into a slightly broken other language that you wish it were. Use C as C, or use something else.
- foldr 3y ago
  C's macros are primitive and unsafe but by no means useless. Here's a somewhat silly example from embedded programming. I wanted to embed the bitmaps of a small set of characters for use on a bitmapped monochrome display. It was easy to define macros CHAR_GRID, _ and X such that e.g. const uint8_t zero[] = { CHAR_GRID( _,X,X,X,_, X,_,_,_,X, X,_,_,X,X, X,_,X,_,X, X,X,_,_,X, X,_,_,_,X, _,X,X,X,_ ) }; desugared to a column-major array of 5 bytes. #define CHAR_GRID(c1r1, c2r1, c3r1, c4r1, c5r1, \ c1r2, c2r2, c3r2, c4r2, c5r2, c1r3, c2r3, c3r3, c4r3, c5r3, c1r4, c2r4, c3r4, c4r4, c5r4, c1r5, c2r5, c3r5, c4r5, c5r5, c1r6, c2r6, c3r6, c4r6, c5r6, c1r7, c2r7, c3r7, c4r7, c5r7) \ c1r1 | (c1r2 << 1) | (c1r3 << 2) | (c1r4 << 3) | (c1r5 << 4) | (c1r6 << 5) | (c1r7 << 6), \ c2r1 | (c2r2 << 1) | (c2r3 << 2) | (c2r4 << 3) | (c2r5 << 4) | (c2r6 << 5) | (c2r7 << 6), \ c3r1 | (c3r2 << 1) | (c3r3 << 2) | (c3r4 << 3) | (c3r5 << 4) | (c3r6 << 5) | (c3r7 << 6), \ c4r1 | (c4r2 << 1) | (c4r3 << 2) | (c4r4 << 3) | (c4r5 << 4) | (c4r6 << 5) | (c4r7 << 6), \ c5r1 | (c5r2 << 1) | (c5r3 << 2) | (c5r4 << 3) | (c5r5 << 4) | (c5r6 << 5) | (c5r7 << 6)
whyever 3y ago
> you can still read K&R in one day and keep most of the language in your head Does this include all 193 cases of undefined behavior?
- tick_tock_tick 3y ago
  I've always been taught and memorized 197 are you forgetting some? Most from those lists are very easy since they are basically the same error played out slightly different.
- xscott 3y ago
  I know you're just trashing C UB because that's fashionable, but if you really think about it there are two popular options, and you can't have both at the same time: a) UB enables valuable optimizations and is important to keep (or even add) when performance matters b) UB makes the language unusable/insecure to anyone but genius level experts and should be avoided Whenever someone (including famous/relevant people like Dennis Ritchie [0], DJ Bernstein [1], or Linus Torvalds [2]) tries to suggest cleaning up, removing, or simply not adding new cases of undefined behavior in C/C++, the optimization experts come running from the other room screaming about how important it is that "signed integer overflow must be undefined" [3] or else things will run a percent more slowly (signed overflow being just one example of UB). Also there are people who suggest adding new UB to Rust [4]. So really, either Rust is significantly slower than C because Rust doesn't have the UB you're criticizing, or C could be a cleaner language without compromising on speed and the compiler writers and standards committees are wrong. You choose, but both options are considered heresy. [0] https://www.lysator.liu.se/c/dmr-on-noalias.html https://www.lysator.liu.se/c/dmr-on-noalias.html [1] https://groups.google.com/g/boring-crypto/c/48qa1kWignU https://groups.google.com/g/boring-crypto/c/48qa1kWignU [2] https://lkml.org/lkml/2018/6/5/769 https://lkml.org/lkml/2018/6/5/769 [3] https://youtu.be/yG1OZ69H_-o https://youtu.be/yG1OZ69H_-o [4] https://www.ralfj.de/blog/2021/11/24/ub-necessary.html https://www.ralfj.de/blog/2021/11/24/ub-necessary.html
  - chlorion 3y ago
    Rust does actually do the many of the same optimizations, and in unsafe rust this can and does lead to UB. An example of this, is aliasing mutable references. Rust has been designed to assume that two mutable refs will never alias, if you attempt to do this it is instant UB. My understanding is that even creating the aliasing reference is UB, even if you don't use it. Another example would be uninitialized values. In rust, the compiler assumes that values are always "valid" and initialized. Since you need to allocate memory before writing to it, you need some way to safely have uninit values, and this is what the MaybeUninit wrapper type is for. The wrapper allows you to safely have uninit values, and once you write to them you can tell the compiler that they are initialized, but if you tell the compiler before on accident, it is UB. References also are guaranteed to point to initialized and valid data, and can never be null, though my understanding is that there is some uncertainty about the exact rules of this with regards to uninitialized values and the exact semantics may change in the future. (There are also a lot more things that I don't know very much about!) All of these things are assumed to never happen, and optimizations are performed based on that assumption. The nice part about rust, is that it makes it impossible to represent invalid states using the type system! For aliasing, you can only have a single live mutable reference at any time, attempting to create a second one while another is live is a compile time error! For uninitialized values, you simply can't create uninitialized values at all in safe rust. My understanding is that the only way to create an uninitialized value is with the MaybeUninit type or by using raw pointers. So rust still has heaps of UB, but it doesn't allow you to do it by default, so you still get some of the optimizations you'd expect. I think there are some cases where rust is missing out on optimizations though, like with signed int overflow for example, and probably more that I don't know about!
jenadine 3y ago
The "simplicity" of C is not a good thing. The Brainfuck language is even "simpler" and you can read the spec in 2 minutes. But that does not make it easier, because all the complexity is in the usage. The abstraction layer that one can build with rust allow the programmer to actually focus of the actual business logic instead of trying to get low level details right.
- softirq 3y ago
  I think you missed the part about systems programming. When you are programming real hardware, the focus is entirely on low level details. You need to know the commands being sent to the device, the device state, and the ownership of resources by the device (which Rust doesn't solve for) are correct. The innovation of Rust is the borrow checker, which is primarily of interest to systems programmers. If your primary interest is highly abstracted business logic, there are tools that don't require manual memory management or being pedantic about the different types of strings. You could just use Go, Java, Haskell, Python, etc.
  - davidhyde 3y ago
    > “and the ownership of resources by the device (which Rust doesn't solve for) are correct.” For embedded software, the underlying code basically reads and writes a bunch of registers. Unsafe memory access with side effects. The benefit of using rust here is that you can easily model these access patterns to make an api that cannot be abused. So the driver reads and writes addresses and the user code operates through the driver with all the benefits of ownership at hand to avoid race conditions and other foot-guns. So, in this way rust does indeed “solve for” ownership of devices. You can’t have two threads (or interrupt handlers) mutating the same device without satisfying the ownership rules.
    - foldr 3y ago
      >You can’t have two threads (or interrupt handlers) mutating the same device without satisfying the ownership rules. The trouble with this is that abstract 'devices' don't necessarily map neatly to the underlying hardware. Configuring peripherals on a typical microcontroller typically requires setting flags in a bunch of random registers which don't necessarily have neatly separated responsibilities. Take PWM as an example. Is there a PWM 'device'? Is there a PWM setting for each port, according to some abstract representation of ports? What about the timer used to generate the PWM output? Does the PWM device own the timer, or does the timer own the PWM device? Any such abstractions cause more problems than they solve. You really just need to think carefully about how you are manipulating the underlying hardware.
RcouF1uZ4gsC 3y ago
> I think the biggest thing is that systems programming still requires a language that gets out of the way so you can focus on very technical problem domains where what the hardware is actually doing really matters. Just the fact that Rust doesn’t do implicit integer conversions is by itself a huge win over C which has promotion rules that can easily trip you up when you are trying to exactly specify bits.
pjmlp 3y ago
> You can still read K&R in one day and keep most of the language in your head Except that isn't what most compilers expose, including the UB semantics. One is in for a sea of surprises when trying to write portable C code and using K&R C as language reference.
mlindner 3y ago
> you can still read K&R in one day and keep most of the language in your head People who say this somewhat perplex me. Yes you can get the syntax of the language down in a day, but that does little to stop you from running into your first Bus Error or Segmentation Fault within the first 30 minutes of trying to write any software, not to mention all the hidden errors/exploits you've put in your code that are only a platform switch or a compiler version change away from being found explosively. And you can completely forget trying to write a multithreaded C application, which basically confines you to very slow single-threaded code, completely tanking performance versus even the slowest dynamic language that supports multithreading, erasing any advantage for using C. This is not a personal attack but when I have to try to come up with an assumed background for people who say this it usually involves some assumptions that the person isn't keeping in touch with the "real world" of some sort. I have trouble rationalizing it otherwise. Thus I'll usually ask what their background is when they say this to try to make sense of things. The only places C is still the optimal choice is where C is already being used or in extreme platforms where there aren't good toolchains (various ASICs/rare 8bit microprocessors). There's zero reason to use it otherwise. > the pain points cough macros are still often pain points in Rust. Hygenic syntax checked macros are an entirely different animal than just string insertion/substition macros. I don't think this comparison is fair.

loudmax 3y ago

Are tracking memory allocation or variable types not pain points for large complicated programs?

softirq 3y ago
In my experience as a kernel programmer tracing allocations isn't the hard part, it's keeping the correct view of hardware state and the different type of mappings at play, be it an MMU or IOMMU device mapping, and register state. Use after free bugs and overflows do happen, but there are more and more tools that come out every year that can find these things in C code, some of them are even hardware based. IMO the code quality of the kernel is very high and the defect rate isn't greater than projects I've worked on that use garbage collection.

ljlolel 3y ago

Try Zig as a C replacement.

softirq 3y ago
I'm not really looking for a replacement for C, the ecosystem of system programming is still really C centric, it would take a large shift in the industry for me to justify investing in another language. I've dabbled with Rust only because early support was merged into Linux. IMO most languages are only marginal improvements over the previous generation that don't outweigh fighting against the entrenchment of expertise, documentation, and integration that come with established languages. It's also hard to be a true expert at a low level domain and multiple programming languages unless you're willing to give up all of your free time.
- moonchrome 3y ago
  Marginal improvements add up.
  - softirq 3y ago
    I agree, at some point they do build up to the point that change is inevitable. There's usually a lot of false starts along the way (AI is a good example of this). No matter what it is, there's going to be a lot of fighting against entrenchment and a lot of us old timers simply have to retire for newer developers, whether they be Rust developers to come in and elicit change.
- vpastore 3y ago
  [dead]
dleslie 3y ago
Does Zig run on everything C can, including weird devices?[0] If the answer is still No, then it can't replace C. 0: https://en.wikipedia.org/wiki/Small_Device_C_Compiler https://en.wikipedia.org/wiki/Small_Device_C_Compiler
- kristoff_it 3y ago
  Zig has been able for a while now to compile to C code, which is part of our bootstrap procedure now, so you can compile that output with an appropriate C compiler and target whatever you want. We do have plans for adding backends for unconventional targets eventually.

dannymi 3y ago

>Adding too many abstraction can be exceedingly dangerous in an environment where not having a full view of how memory and hardware registers are laid out leads to even worse errors than just buffer overflows. svd2rust is pretty good for having safe abstractions for hardware registers. That said, as an example, no, the type system doesn't prevent you from deallocating your DMA buffer while the hardware is using it--I don't think it's reasonable to add that to the type system (and the type system right now doesn't know about DMA).

the__alchemist 3y ago
Garbage in, garbage out! Svd2rust is a great tool, but the patching process (YAMLs) is currently not user friendly due to silent failures. Root cause is hardware makers putting out bugged SVDs that need patching. I think re DMA buffer lifetimes, the easy approach is static buffers; they never drop.

bfrog 3y ago

You can and do use simple pointers in Rust, nothing prevents this. The abstractions can be more used like static interfaces you want to reuse. E.g. a byte stream interface, a regmap interface, etc.

59nadir 3y ago
I think there have been a few posts pointing out that the ergonomics around using just pointers in Rust is lacking severely in comparison to languages like Zig and Odin.

the__alchemist 3y ago

I think this is often a function of Rust OSS libs vice the language itself. The embedded Rust community has created and promoted bad APIs. I think it's worth pointing this out and building other APIs, even though this doesn't endear you to the Rust community. I'm worried people will get the wrong idea about embedded Rust ergonomics and attribute these APIs to the language itself.

adamnemecek 3y ago
Can you talk more about this? I'm very curious.
- steveklabnik 3y ago
  I do not have as strong of feelings as your parent, but: 1. A lot of the APIs make use of the typestate pattern, which is nice, but also very verbose, and might turn many people off. 2. The generated API documentation for the lower level crates relies on you knowing the feel for how it generates the various APIs. It can take some time to get used to, especially if you're used to the better documentation of the broader ecosystem. 3. A bunch of the ecosystem crates assume the "I am running one program in ring0" kind of thing, and not "I have an RTOS" sort of case. See the discussion in https://github.com/rust-embedded/cortex-m/issues/233 https://github.com/rust-embedded/cortex-m/issues/233 for example.
- bsder 3y ago
  Well, for starters, allocators. The standard library is now making adjustments around that, but it's not mainstream and most people don't use them and they don't get the same level of attention as the happy path. However, Rust, the language has its issues on embedded. Rust's ownership model is directly at odds with lots of embedded. These bits inside a register are owned by the ADC and these bits inside a register are owned by the DAC is not a happy thing in Rust. Lack of arbitrary sized integers and how they slice. Cargo. Quite annoying to deal with cargo and an embedded toolchain. The Rust embedded guys have done really good work if you're on ARM. If you're not, good luck. That having been said, if you have to go implement something like Reference Counting in something not Rust, you will weep tears of blood debugging every single time your reference counts go wrong. Embedded is engineering. It has tradeoffs. That's life.

deleted 3y ago

[deleted]

kaba0 3y ago

C has beyond useless “macros”, they should not be compared with Rust’s, that are actually useful.

jimbob45 3y ago
While that’s true, preprocessors are pretty trivial to write these days if you want macros that the language doesn’t support. Racket excels at this.
- sanxiyn 3y ago
  Which preprocessor do you recommend for writing C?
  - jimbob45 3y ago
    https://stackoverflow.com/a/3685576 https://stackoverflow.com/a/3685576 There’s one approach. I wouldn’t personally recommend using macros outside of include guards and file inclusion. Still, if you need more functionality, the methods exist.
  - bsder 3y ago
    None. Use an actual different language. Ada, Rust, Zig, D, Lisp/Scheme/Racket, Tcl, Forth, etc. ... something other than C. Don't preprocess C into a slightly broken other language that you wish it were. Use C as C, or use something else.
foldr 3y ago
C's macros are primitive and unsafe but by no means useless. Here's a somewhat silly example from embedded programming. I wanted to embed the bitmaps of a small set of characters for use on a bitmapped monochrome display. It was easy to define macros CHAR_GRID, _ and X such that e.g. const uint8_t zero[] = { CHAR_GRID( _,X,X,X,_, X,_,_,_,X, X,_,_,X,X, X,_,X,_,X, X,X,_,_,X, X,_,_,_,X, _,X,X,X,_ ) }; desugared to a column-major array of 5 bytes. #define CHAR_GRID(c1r1, c2r1, c3r1, c4r1, c5r1, \ c1r2, c2r2, c3r2, c4r2, c5r2, c1r3, c2r3, c3r3, c4r3, c5r3, c1r4, c2r4, c3r4, c4r4, c5r4, c1r5, c2r5, c3r5, c4r5, c5r5, c1r6, c2r6, c3r6, c4r6, c5r6, c1r7, c2r7, c3r7, c4r7, c5r7) \ c1r1 | (c1r2 << 1) | (c1r3 << 2) | (c1r4 << 3) | (c1r5 << 4) | (c1r6 << 5) | (c1r7 << 6), \ c2r1 | (c2r2 << 1) | (c2r3 << 2) | (c2r4 << 3) | (c2r5 << 4) | (c2r6 << 5) | (c2r7 << 6), \ c3r1 | (c3r2 << 1) | (c3r3 << 2) | (c3r4 << 3) | (c3r5 << 4) | (c3r6 << 5) | (c3r7 << 6), \ c4r1 | (c4r2 << 1) | (c4r3 << 2) | (c4r4 << 3) | (c4r5 << 4) | (c4r6 << 5) | (c4r7 << 6), \ c5r1 | (c5r2 << 1) | (c5r3 << 2) | (c5r4 << 3) | (c5r5 << 4) | (c5r6 << 5) | (c5r7 << 6)

whyever 3y ago

> you can still read K&R in one day and keep most of the language in your head Does this include all 193 cases of undefined behavior?

tick_tock_tick 3y ago
I've always been taught and memorized 197 are you forgetting some? Most from those lists are very easy since they are basically the same error played out slightly different.
xscott 3y ago
I know you're just trashing C UB because that's fashionable, but if you really think about it there are two popular options, and you can't have both at the same time: a) UB enables valuable optimizations and is important to keep (or even add) when performance matters b) UB makes the language unusable/insecure to anyone but genius level experts and should be avoided Whenever someone (including famous/relevant people like Dennis Ritchie [0], DJ Bernstein [1], or Linus Torvalds [2]) tries to suggest cleaning up, removing, or simply not adding new cases of undefined behavior in C/C++, the optimization experts come running from the other room screaming about how important it is that "signed integer overflow must be undefined" [3] or else things will run a percent more slowly (signed overflow being just one example of UB). Also there are people who suggest adding new UB to Rust [4]. So really, either Rust is significantly slower than C because Rust doesn't have the UB you're criticizing, or C could be a cleaner language without compromising on speed and the compiler writers and standards committees are wrong. You choose, but both options are considered heresy. [0] https://www.lysator.liu.se/c/dmr-on-noalias.html https://www.lysator.liu.se/c/dmr-on-noalias.html [1] https://groups.google.com/g/boring-crypto/c/48qa1kWignU https://groups.google.com/g/boring-crypto/c/48qa1kWignU [2] https://lkml.org/lkml/2018/6/5/769 https://lkml.org/lkml/2018/6/5/769 [3] https://youtu.be/yG1OZ69H_-o https://youtu.be/yG1OZ69H_-o [4] https://www.ralfj.de/blog/2021/11/24/ub-necessary.html https://www.ralfj.de/blog/2021/11/24/ub-necessary.html
- chlorion 3y ago
  Rust does actually do the many of the same optimizations, and in unsafe rust this can and does lead to UB. An example of this, is aliasing mutable references. Rust has been designed to assume that two mutable refs will never alias, if you attempt to do this it is instant UB. My understanding is that even creating the aliasing reference is UB, even if you don't use it. Another example would be uninitialized values. In rust, the compiler assumes that values are always "valid" and initialized. Since you need to allocate memory before writing to it, you need some way to safely have uninit values, and this is what the MaybeUninit wrapper type is for. The wrapper allows you to safely have uninit values, and once you write to them you can tell the compiler that they are initialized, but if you tell the compiler before on accident, it is UB. References also are guaranteed to point to initialized and valid data, and can never be null, though my understanding is that there is some uncertainty about the exact rules of this with regards to uninitialized values and the exact semantics may change in the future. (There are also a lot more things that I don't know very much about!) All of these things are assumed to never happen, and optimizations are performed based on that assumption. The nice part about rust, is that it makes it impossible to represent invalid states using the type system! For aliasing, you can only have a single live mutable reference at any time, attempting to create a second one while another is live is a compile time error! For uninitialized values, you simply can't create uninitialized values at all in safe rust. My understanding is that the only way to create an uninitialized value is with the MaybeUninit type or by using raw pointers. So rust still has heaps of UB, but it doesn't allow you to do it by default, so you still get some of the optimizations you'd expect. I think there are some cases where rust is missing out on optimizations though, like with signed int overflow for example, and probably more that I don't know about!

jenadine 3y ago

The "simplicity" of C is not a good thing. The Brainfuck language is even "simpler" and you can read the spec in 2 minutes. But that does not make it easier, because all the complexity is in the usage. The abstraction layer that one can build with rust allow the programmer to actually focus of the actual business logic instead of trying to get low level details right.

softirq 3y ago
I think you missed the part about systems programming. When you are programming real hardware, the focus is entirely on low level details. You need to know the commands being sent to the device, the device state, and the ownership of resources by the device (which Rust doesn't solve for) are correct. The innovation of Rust is the borrow checker, which is primarily of interest to systems programmers. If your primary interest is highly abstracted business logic, there are tools that don't require manual memory management or being pedantic about the different types of strings. You could just use Go, Java, Haskell, Python, etc.
- davidhyde 3y ago
  > “and the ownership of resources by the device (which Rust doesn't solve for) are correct.” For embedded software, the underlying code basically reads and writes a bunch of registers. Unsafe memory access with side effects. The benefit of using rust here is that you can easily model these access patterns to make an api that cannot be abused. So the driver reads and writes addresses and the user code operates through the driver with all the benefits of ownership at hand to avoid race conditions and other foot-guns. So, in this way rust does indeed “solve for” ownership of devices. You can’t have two threads (or interrupt handlers) mutating the same device without satisfying the ownership rules.
  - foldr 3y ago
    >You can’t have two threads (or interrupt handlers) mutating the same device without satisfying the ownership rules. The trouble with this is that abstract 'devices' don't necessarily map neatly to the underlying hardware. Configuring peripherals on a typical microcontroller typically requires setting flags in a bunch of random registers which don't necessarily have neatly separated responsibilities. Take PWM as an example. Is there a PWM 'device'? Is there a PWM setting for each port, according to some abstract representation of ports? What about the timer used to generate the PWM output? Does the PWM device own the timer, or does the timer own the PWM device? Any such abstractions cause more problems than they solve. You really just need to think carefully about how you are manipulating the underlying hardware.

RcouF1uZ4gsC 3y ago

> I think the biggest thing is that systems programming still requires a language that gets out of the way so you can focus on very technical problem domains where what the hardware is actually doing really matters. Just the fact that Rust doesn’t do implicit integer conversions is by itself a huge win over C which has promotion rules that can easily trip you up when you are trying to exactly specify bits.

pjmlp 3y ago

> You can still read K&R in one day and keep most of the language in your head Except that isn't what most compilers expose, including the UB semantics. One is in for a sea of surprises when trying to write portable C code and using K&R C as language reference.

mlindner 3y ago

> you can still read K&R in one day and keep most of the language in your head People who say this somewhat perplex me. Yes you can get the syntax of the language down in a day, but that does little to stop you from running into your first Bus Error or Segmentation Fault within the first 30 minutes of trying to write any software, not to mention all the hidden errors/exploits you've put in your code that are only a platform switch or a compiler version change away from being found explosively. And you can completely forget trying to write a multithreaded C application, which basically confines you to very slow single-threaded code, completely tanking performance versus even the slowest dynamic language that supports multithreading, erasing any advantage for using C. This is not a personal attack but when I have to try to come up with an assumed background for people who say this it usually involves some assumptions that the person isn't keeping in touch with the "real world" of some sort. I have trouble rationalizing it otherwise. Thus I'll usually ask what their background is when they say this to try to make sense of things. The only places C is still the optimal choice is where C is already being used or in extreme platforms where there aren't good toolchains (various ASICs/rare 8bit microprocessors). There's zero reason to use it otherwise. > the pain points cough macros are still often pain points in Rust. Hygenic syntax checked macros are an entirely different animal than just string insertion/substition macros. I don't think this comparison is fair.