Rust Developer words and actions do not align

Posted Feb 1, 2025 12:24 UTC (Sat) by ma4ris8 (subscriber, #170509)
In reply to: Rust Developer words and actions do not align by NYKevin
Parent article: Resistance to Rust abstractions for DMA mapping

From inability to win, it is possible to look into the problems at hand.

One Finnish inventor, holding 162 patents, was interviewed yesterday in TV.
He was asked, what was his secret? He told that he must have more problems,
compared to others. We have here emphasized problems, thus this is a place for new innovations.
I didn't find the inventor's name yet, and couldn't double check the facts.

Three cases come to mind; tooling, architecture and mental side:

1. Changing C API: does it have to break Rust compilation? Decouple C and Rust API changes.
One depends on the other. If C struct gets a new field, make it a Rust warning, not compile error.
Then Rust is checked, and warning goes away. Thus child API should not block
parent layer API development.

2. Robust way of grepping both C and Rust codebases. Find and see all function callers easily.
Enable easily add C function argument, and do the same into Rust API.
Either convert into a compile warning, or make it easy to adapt Rust code for the change.

3. Mental side: learn to listen. I feel lack of the skill, and need to learn it better.

Rust Developer words and actions do not align

Posted Feb 1, 2025 13:29 UTC (Sat) by mb (subscriber, #50428) [Link] (4 responses)

That's not really how Rust-C-bindings work.

The Rust side of the binding needs to be sound beyond what the C type system provides.
This is where "unsafe" blocks come into play. They are misnamed. They should be called "manually-checked-for-safety-soundness" blocks.
Every time something at the C side API semantics changes the corresponding Rust unsafe blocks have to be checked whether some assumptions are broken.
Rust-C-bindings usually (have to) depend on the C side giving certain guarantees to the Rust code that are not expressible in the C type system.

Changing a struct might be Ok or might not be Ok. But one can only be sure after checking of the Rust code. Grepping the source code doesn't really help to do that. Knowledge about Rust is required to do that.
If the C developer does not have that knowledge, it's actually better if she does not touch the unsafe blocks. It's very easy to introduce bugs there.

This is what the R4L people will do.
C-only developer breaks the API and provides details about the new semantics to the R4L people and they will fix the binding. These things have to be written down anyway for the C consumers of the API.

Rust Developer words and actions do not align

Posted Feb 1, 2025 22:22 UTC (Sat) by dralley (subscriber, #143766) [Link]

> "Every time something at the C side API semantics changes the corresponding Rust unsafe blocks have to be checked whether some assumptions are broken."

Which also has to be done for every C caller of that API. Some of those callers may even require subsystem-specific knowledge to change, at which point you're working in collaboration with another developer no differently than you might need to work with an R4L developer.

Rust Developer words and actions do not align

Posted Feb 2, 2025 10:01 UTC (Sun) by ma4ris8 (subscriber, #170509) [Link] (2 responses)

Rust is sound, like music. There are unsafe blocks,
which call libraries. Soundness need to be maintained.
Ok, so the underlying library change (C library version bump up in user space)
need to be checked.

Sometimes in music there are irregularities,
keeping audience awake. While learning, sometimes those need to be manually checked using piano.
Perhaps from the author himself, herself, if unsure about note or word.

Still, learning a song can be done. No need to say to the composer:
don't do anything, until we have checked it.

So in this case, either lower level library is written in C or in Rust.

If it is possible to test and develop the lower level library independently
and practically via abstractions, without modifying upper level library,
then the maintenance of lower level library is more practical.

Lower level library author is aware of constraints, perhaps not all.
Author is used to test code by compiling and running it.

Some cases need tight co-change with Rust and C changes at the same merge request.
So minimizing this kind of tight coupling could
improve productivity. Documentation advances?
Remaining cases: better tooling could be considered.

My opinion is that Rust safety is becoming a baseline
for program robustness. C held that position before. It took it from assembly language.
Thus it is good to not lower that baseline either.

I don't know how to unblock the progress. Sometimes there need to wait a bit
and then retry, or meet face to face at a right time.
Shrinking productivity gaps, when identified: no need to wait for those.

Rust Developer words and actions do not align

Posted Feb 2, 2025 16:11 UTC (Sun) by Wol (subscriber, #4433) [Link] (1 responses)

> While learning, sometimes those need to be manually checked using piano.

Apologies for going off topic, but this embodies EVERYTHING that is WRONG with Western Music.

How do you check whether your didgeridoo music is okay on a piano? How do you even PLAY your Indian quarter-tone music on a piano? How do you tell whether you've got the balance right between the piercing trumpet, the sonorous flugel, and the rounded cornet on a piano?

The piano is the musical equivalent of BASIC - a lowest common denominator that everyone is forced to damage their mind with before they are allowed to move on ...

The piano has totally and utterly poisoned the concept of Music here in the West ...

Cheers,
Wol

Rust Developer words and actions do not align

Posted Feb 8, 2025 3:27 UTC (Sat) by ssokolow (guest, #94568) [Link]

To be fair to the piano, I don't think it originated that behaviour. As I understand it, the harpsichord occupied more or less the same niche before the piano was invented. That's why there's so much harpsichord music.