Comment by softirq

3 years ago

> 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.

59 comments

softirq

Reply
jenadine  3 years 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  3 years 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.

    • pkolaczk  3 years ago

      > 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.

      1. Rust doesn't force you to do manual memory management. Rust memory management is automatic by default and only if you really, really want to, you can do it manually.

      2. Memory is not the only resource. The GCs in languages you listed only solve the memory management problem, but regarding the other types of resources, their ergonomics are often worse than C - you have to remember to close the resources manually and you get virtually no help from the compiler.

      3. None of the listed languages address problems related to concurrency, e.g. data races. Ok, Haskell kinda avoids the problem by imposing other restrictions - by not allowing mutation / side effects ;)

      4. Rust offers way better tools for building high level abstractions than Go, Python and Java. It has set a very high bar with algebraic data types, pattern matching, traits/generics and macros.

      14 replies →

    • davidhyde  3 years 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.

      2 replies →

  • WiSaGaN  3 years ago

    Absolutely. I used to work in a C++ shop writing mission critical software. We would be far more concerned to let a newcomer to contribute on existing C++ codebase than on existing Rust codebase. The newcomer surely would have a harder time to make a pull request that compiles and passes tests in Rust than in C++, but that is a good thing for maintainers.

  • c_crank  3 years ago

    Several successor languages have kept the simple syntax of C while eliminating a large class of warts. Hindsight and not having to keep a wide reaching set of compiler standards let a language have simple syntax and not so many problems with UB.

whyever  3 years 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  3 years 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  3 years 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

    [1] https://groups.google.com/g/boring-crypto/c/48qa1kWignU

    [2] https://lkml.org/lkml/2018/6/5/769

    [3] https://youtu.be/yG1OZ69H_-o

    [4] https://www.ralfj.de/blog/2021/11/24/ub-necessary.html

    • chlorion  3 years 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!

      1 reply →

the__alchemist  3 years 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  3 years ago

    Can you talk more about this? I'm very curious.

    • bsder  3 years 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.

    • steveklabnik  3 years 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 for example.

    • kramerger  3 years ago

      Every time I play with embedded Rust I get this feeling that some of the people driving it are more into language esthetics and don't have experience in real-world embedded systems.

      For example, I see inefficient patterns that are common in frontend world but have no place in an embedded system being promoted as "proper" way of doing things.

      1 reply →

    • the__alchemist  3 years ago

      The other replies reflect my thoughts, so I don't have much to add. So, these are elaborations on those:

      It appears most of the peripheral support libs (eg those that use Embedded-HAL traits) are not designed with practical ends in mind; I've found it easier for all I2C/SPI etc devices I've used to start from scratch with a `setup` fn with datasheet references, than DMA transfers. So, you have these traits designed to abstract over busses etc; they sound nice in principle, but are (so far) not useful for writing firmware.

      I get a general sense that the OSS libs are designed with a "let's support this popular MCU/IC, and take advantage of Rust's type system and language features!" mindset. A bare minimum is done, it's tested on a dev board, then no further testing or work. There are flaws that show up immediately when designing a device with the lib in question.

      So, at least for the publicly-available things, they're designed in an abstract sense, instead of for a practical case.

dannymi  3 years 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  3 years 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.

kaba0  3 years ago

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

  • foldr  3 years 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)

mlindner  3 years 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.

bfrog  3 years 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  3 years 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.

RcouF1uZ4gsC  3 years 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  3 years 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.

loudmax  3 years ago

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

  • softirq  3 years 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  3 years ago

Try Zig as a C replacement.

  • softirq  3 years 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.