[bayindirh]

Directly programming hardware with bit-banging, shifts, bitmasks and whatnot. Too cumbersome in ASM to do in large swaths, too low level for Rust or even for C++.

Plus for that kind of things you have "deterministic C" styles which guarantee things will be done your way, all day, every day.

For everyone answering: This is what I understood by chatting with people who write Rust in amateur and pro settings. It's not something of a "Rust is bad" bias or something. The general consensus was, C is closer to the hardware and allows handling of quirks of the hardware better, because you can do "seemingly dangerous" things which hardware needs to be done to initialize successfully. Older hardware is finicky, just remember that. Also, for anyone wondering. I'll start learning Rust the day gccrs becomes usable. I'm not a fan of LLVM, and have no problems with Rust.

[dralley]

> too low level for Rust or even for C++.

I'd love to hear a justification for why this is a thing. Doing bit-banging is no more difficult in Rust or C++ than in C.

[friendzis]

You probably mean "C compatible-ish subset of C++98"

[dartos]

Two reasons I can think of off the top of my head.

The assembly outputted from C compilers tend to be more predictable by virtue of C being a simpler language. This matters when writing drivers for exotic hardware.

Sometimes to do things like make a performant ring buffer (without vec dequeue) you need to use unsafe rust anyway, which IMO is just taking the complexity of the rust language without any of the benefit.

I don’t really think there’s any benefit to using C++ over rust except that it interfaces with C code more easily. IMO that’s not a deal maker.

[jcranmer]

> The assembly outputted from C compilers tend to be more predictable by virtue of C being a simpler language.

The usual outcome of this assumption is that a user complains to the compiler that it doesn't produce the expected assembly code, which the compiler ignores because they never guaranteed any particular assembly output.

This is especially true for the kinds of implicit assembly guarantees people want when working with exotic hardware. Compilers will happily merge loads and stores into larger load/stores, for example, so if you need to issue two adjacent byte loads as two byte loads and not one 16-bit load, then you should use inline assembly and not C code.

[dartos]

I’m not saying every C compiler is always perfectly predictable, but by virtue of it being a simpler language it should Always be more predictable than rust, barring arcane optimizations.

I do agree that if someone actually cares about the assembly they should be writing it by hand.

[Ygg2]

> I’m not saying every C compiler is always perfectly predictable

No C compiler is predictable. First, there is the compiler magic of optimization.

Then you have Undefined Behavior, which in C, that's almost a guarantee, you'll experience inconsistent behavior between compilers, targets, optimization levels and the phases of the moon.

In Rust, use .iter a lot to avoid bound checks, or if you want auto-vectorization use a lot of fixed length arrays, and look how LLVM auto-vectorizes it. It takes getting used to it, but hey, so does literally every language if you care about SOURCE -> ASSEMBLY translation.

[Ygg2]

> The assembly outputted from C compilers tend to be more predictable by virtue of C being a simpler language.

That doesn't seem to be true, not in the presence of UB, different platforms and optimization levels.

> Sometimes to do things like make a performant ring buffer (without vec dequeue) you need to use unsafe rust anyway, which IMO is just taking the complexity of the rust language without any of the benefit.

If you write a data structure in Rust, it's expected to wrap the unsafe fiddly bits into a safer shell and provide unsafe access as needed. Sure, the inner workings of Vec, VecDeque, and Ring Buffers are unsafe, but the API used to modify them isn't (modulo any unsafe methods that have their prerequisite for safe access stated).

The idea is to minimize the amount of unsafe, not completely eradicate it.

[pjmlp]

Autovectorizing code is hardly predictable, or when folks land in UB mines that optimizers glady take advantage of.

[hkwerf]

Why exactly would it be too low-level for Rust?

[metaltyphoon]

> too low level for Rust or even for C++.

This doesn’t make any sense to me, could you explain why?

[bfrog]

Rust does ok at this but typically works better with some tooling to make register and bit flag manipulation look more like normal rust functions. chiptool and svd2rust do this for microcontroller code using all rust. The only asm needed is going to be the bootup to setup enough to run rust (or C)

[jcranmer]

Honestly, if I need to do bit-banging, I'd go with Rust over C these days. Rust has a much richer set of bit primitives than C does.

[andrewaylett]

"C is closer to the hardware" [citation needed]

This might have been true 50 years ago, I am unconvinced it was true 25 years ago, it would take a lot to convince me it's true today.