Hacker News Reader

Comment by kettro | Hacker News Reader

Great post, especially for the embedded crowd. I'm looking to start using Rust in FW development but hit a couple pain points.

* First, bit field descriptors is a huge pain - where, in C, you would define an enum for the task, there isn't a real equal in vanilla Rust, other than a litany of constant variables. * Second, the over-reliance on nightly is a tough sell for - having inline asm gated makes it very hard. * Third, while format is great, it's also very heavyweight. Not having (AFAIK) variadic arguments is hard, and there isn't really an equal to printf.

I would love to be proven wrong, because I have an OS to write, and would love to use Rust.

View on HN

> First, bit field descriptors is a huge pain - where, in C, you would define an enum for the task, there isn't a real equal in vanilla Rust

“A litany of constants” is exactly what your c enum is though.

And you can define a "degenerate" Rust enum with explicit discriminant values:

    enum Foo {
        A = 1,
        B = 2,
        C = 4
    }

They are cast-able to integrals too:

    println!("{}", Foo::C as usize); // prints "4"

Doesn’t work so well for flags however.

> Second, the over-reliance on nightly is a tough sell for - having inline asm gated makes it very hard.

The alternative would be to simply not make the feature available at all until it is done and ready, with even higher risk (as it would have been exercised even less).

As is, if the feature is fine for you as-is you can use it, and if you can't or don't want to use nightly you can go and assist its shepherding to stable (https://github.com/rust-lang/rust/issues/72016)

> while format is great, it's also very heavyweight. Not having (AFAIK) variadic arguments is hard, and there isn't really an equal to printf.

There are no safe Rust-level variadics, but Rust can call C variadic functions, and under RFC 2137 (not stable yet I think) define them as well.

You can assign numeric values to enum variants in Rust too like so:

    enum Field {
        Foo = 0b11111111,
        Bar = 0b10101010,
    }

    fn main() {
        println!("{}", Field::Foo as u8);
        println!("{}", Field::Bar as u8);
    }

There is also the bitflags crate: https://docs.rs/bitflags/1.2.1/bitflags/

For lighter weight formatting there is https://github.com/japaric/ufmt

> You can assign numeric values to enum variants in Rust too

Is this (C-style enums) new?

I swear I looked for it a year or two back, found questions about it, with the answers "use constants".

These aren't really C style enums. These are still sum types.

C-style enums are sugar for defining an integer type alias and a bunch of constants without creating any new types or scope.

Rust enums, even with an assigned value, define a new type that can only be one of the defined values. So this type is not an integer and cannot have a bit pattern that isn't explicitly defined.

Rust calls this feature "C style enums," so while you're right there are differences, it's sort of a term of art in this context.

("style" is supposed to reflect that it's similar, but not the same thing.)

Yeah. I hate it ;).

I already have enough trouble trying to explain to new people the difference between C and Rust enums. The phrase "C style" just confuses things more, IMHO.

Admittedly this may be a failure of communication on my part.

That's fair :)

I don't think the name was super carefully considered, to be honest, it just kinda happened.

C enums in Rust can be declared as:

  enum Foo {
    A=0,
    B=1,
    C=3,
    _UNKNOWN(i32),
  }

However, this cannot be compiled by current Rust compiler.

EDIT: Found it in the changelog. This feature was added in Rust 0.8 (2013-09-26) "Explicit enum discriminants may be given as uints as in enum E { V = 0u }" https://github.com/rust-lang/rust/blob/master/RELEASES.md#ve...

They're referenced as a pre-existing feature in this Jan 2015 RFC [0], so they predate Rust 1.0. I don't know quite how old they are, but I suspect much older than that as this feature is necessary for interfacing with C which has been a high priority for Rust for a long time (particularly driven by the needs of the Servo project in the early years).

[0]: https://rust-lang.github.io/rfcs/0639-discriminant-intrinsic...

> Is this (C-style enums) new?

No.

> I swear I looked for it a year or two back, found questions about it, with the answers "use constants".

Possibly because they were asked / answered in the context of bit flags?

Even degenerate, rust enums are not compatible with C enums because they're still type-safe, you can't create any random value and say "that's a Foo", that'd be UB. So if you want bitflags, you need to use constants.

Thanks. I didn't want bitflags, this was just basically for an enumeration of channels/parameters e.g Foo=0, Bar=1, Baz=2. Ideally I'd like one that was numbered automatically and also offered a way of enumerating the possible values at runtime. I can't remember why I went back to constants in that case.

Another struggle I remember was just getting the max defined value. Again the Rust type is pretty Opaque because it hides the all-powerful discriminated union type. I love the Rust enum type, but I wish Rust also had a first-class dumb enum type, with all the C/C# niceties (bitflags, runtime enumeration, selection of backing field). This seems like quite a different from what the rust enum is.

You probably ran into this stuff not being built-in. You can add it on via a macro pretty easily, except that the "selection of backing field" is built in via the repr attribute. An example of this would be packages like https://docs.rs/enum_derive/0.1.7/enum_derive/

The other stuff isn't built in because it would add a bunch of code you may or may not want to your build, and it's easy enough to opt into. We also could solve that problem, in theory, a few ways, but there just hasn't been a ton of demand for it, so it hasn't been done.

With bitfields, there has been increasing demand lately, so we'll see.

I constantly run into the situation where you make 2 or more constants with a prefix. That always felt like a smell to me - but it might be because in C# it would be.

I'm talking about code that ends up looking like this: https://github.com/retep998/winapi-rs/blob/0.3/src/shared/nt...

You get type safety because you can define the type of constant rather than use some primitive, but there feels like something is something missing (nicer autocompletion, better auto generated documentation, and so on).

I would probably wrap constants with the same prefix in a module, but all that really does is make the naming feel nicer, I guess.

> * First, bit field descriptors is a huge pain - where, in C, you would define an enum for the task, there isn't a real equal in vanilla Rust, other than a litany of constant variables.

With my Rust language team hat on: we'd love to have native support for bitfields. I'd invite folks who are interested in that to propose a language MCP ("major change proposal"), which I'd expect to be approved, and then collaborate on a spec for them.

Josh are you able to answer my top-level comment about fixed point numbers?

Sure, done.

I probably said this many places before, but I rather leapfrog C and get {u,i}N for all n and #[repr(bitpacked)].

There are two separate problems that'd need solving to handle bitfields:

1) Having uN and possibly iN types, for general-purpose use.

2) Placing such types at specific offsets within a struct.

C only handles the second of those: you can have an N-bit type, but when you extract it it comes out as the wider type you constrain it from. So, `unsigned field:5;` will get read as an `unsigned`, not a `u5`.

Rust could handle both, if appropriate sized types exist. (Const generics might be nice here, to parameterize on the type width.) (1) alone won't solve the problem, without some way to define how those types are packed into the struct.

>First, bit field descriptors is a huge pain - where, in C, you would define an enum for the task, there isn't a real equal in vanilla Rust, other than a litany of constant variables.

Have a look at the bitlags crate, I use it a lot for this purpose: https://docs.rs/bitflags/1.2.1/bitflags/

You still have to give the literal value of the field instead of using the auto-incrementing enum but that's how I do it in C as well, I find it too error-prone otherwise. And how do you deal with fields that take up multiple bits anyway?

>Second, the over-reliance on nightly is a tough sell for - having inline asm gated makes it very hard.

I agree 100%. I can understand them prioritizing higher level system programing and taking the time to do asm right, but it does make it a bit of a pain to do bare metal Rust at the moment.

>Third, while format is great, it's also very heavyweight. Not having (AFAIK) variadic arguments is hard, and there isn't really an equal to printf.

What do you have in mind here? format! is strongly typed and a lot more flexible than printf. You can't even print custom structs with printf... Actually even printing standard types like uint32_t and friends require macro soup to work portably.

Variadic arguments are pretty much a no-go for a strongly typed, static language since you would need a lot of trickery to get it to work safely under the hood (hence format! being a macro).

But what use case do you have for printf that can't be implemented with println!/format! and friends?

> But what use case do you have for printf that can't be implemented with println!/format! and friends?

I'm guessing they mean that the format! machinery is rather complex and brings in a lot of code. That it's also somewhat slow is a recurring concern .

Have none of the embedded folks created a specialised version of format! which is not generic, and basically only supports the types and styles which c's printf supports?

edit: there's ufmt though it seems somewhat inactive and I've no idea how good it is: https://github.com/japaric/ufmt

> Optimized for binary size and speed (rather than for compilation time)

> No dynamic dispatch in generated code

There's defmt which I think i think is even better (it implements basically the same thing as I have used in a commercial C++ embedded project for a few years, and was sorely missing any open source equivilent when I was first trying to implement it). formatting strings on an embedded device is pointless and wasteful. Heck, formatting log lines before they are displayed to the user is actively harmful to interpreting them! Defmt basically gives embedded projects structured logging and a substantial bandwidth, cpu, and space overhead gain.

https://ferrous-systems.com/blog/defmt/

defmt looks cool for logging but I'd think there are cases where you want to format strings somehow in order to present them to the user e.g. audio track information or whatnot.

Have a look at the recent defmt project announced by the Knurling-rs group:

https://defmt.ferrous-systems.com/

(And consider sponsoring them if this is of value to you: https://ferrous-systems.com/blog/knurling-one-month/.)

> because I have an OS to write

That sounds awesome. Personal project or commissioned?

Reply on news.ycombinator.com