> a C API offers setBit(&gpioCtx, bitPosition, 1)

You can almost certainly do the same in Rust in an unsafe block.

You will be happier and more productive unless you get bitten by the lack of locking, reference counting and mandatory initialisation. Which is actually quite likely.

> locking, reference counting and mandatory initialisation

Don’t need any of this crap for a garage door opener. Most firmware is incredibly simple.

    pthread_mutex_lock(&mutex);
    setBit(&gpioCtx, bitPosition, 1);
    pthread_mutex_unlock(&mutex);

Compiled with -Wall is fine and infinitely more readable that the Rust puke above, but you probably won’t need the lock or the warnings in your typical embedded project. The main issue with Rust appears to be that it invites masturbators that invent problem scenarios in their head and then overengineer every std lib API and crate available for consumption. Setting a bit on a dev board should simple. It should not be a chained mess full of operator soup.

People should be far more willing to use unsafe than they currently are.

You can also write it more simply in Rust as other responses showed, there's no need for the flame war.

>You can also write it more simply in Rust

But this is never done, because the language attracts people who overengineer. The original commenter was following a beginner’s tutorial in Embedded Rust. They didn’t just unluckily stumble upon something esoteric with too many layers of safety for the functionality they were aiming to achieve. This is how people in the Rust Foundation actually use their language, and it’s how they teach people to use it.

This is how people who absolutely need to access their hardware gated by a mutex ands critical section do it… it’s worse in C.

>it's worse in C

    pthread_mutex_lock(&mutex);
    setBit(&gpioCtx, bitPosition, 1);
    pthread_mutex_unlock(&mutex);

It's not.

That's a terrible API. If you forget to unlock it, have fun pulling your hair out while debugging. Rust makes it so that you can't forget.

lol

POSIX threads are far more battle-proven than any threading API in Rust. All of the underlying multi-threading on the system you made your comment from is using pthreads. It works fine in reality, despite all the pearl clutching.

>Rust makes it so that you can't forget.

And the tradeoff is an unreadable, puke-inducing one-liner. You can do a (readable) scoped lock with a macro in C (GCC defines the __attribute__ cleanup) or RAII-style with destructors in C++.

"Works fine" is an interesting choice of words for the absolute tire fire of a tech stack that modern tech currently depends on.

You should probably see a doctor about your hyperemesis.

Agree to disagree.

It is done all the time. You can take anything out of context and punch a strawman but that's not interesting.

The context of this exact discussion is the defense of the ugly Rust code above by Rust aficionados who see nothing wrong with it. That code came from the Embedded Rust working group in their learning material for Rust beginners.

I'm not taking anything out of context. That code is hideous. It's terse. It uses controls and defenses that aren't needed for most embedded applications. It turned a beginner away from the language. When I provided much simpler C code as an alternative, Rust aficionados started to cry about unneeded mutexes, unneeded ref counting, the inability of programmers to remember to call free or mutex_unlock, etc. etc.

Your response is an unrelated rant. Here's your claim:

> But [writing it more simply] is never done

You're not saying anything interesting, you're just making grandiose false claims to start a flame war. Approach it from a good-faith perspective, please.