3 ms·

The real issue how strong and stable does his C api need to be? If I maintain a (code level) api used in a single codebase I typically have a lot of flexibilit

by lokar 2y ago

The real issue how strong and stable does his C api need to be? If I maintain a (code level) api used in a single codebase I typically have a lot of flexibility. I can make “breaking” changes as long as I fix all the uses as the same time. This is really big advantage. If the codebase has multiple languages using my api I will need to make changes in these other languages if I want to do this. This is a very real cost to me. It will tend to force me to have a really stable api with no breaking changes since I won’t realistically be able to fix them all myself.

drpossum 2y ago
I fail to see how this is a relevant question and "the real issue" with respect to Rust. How is this situation any different from a pure C kernel? There are already protocols on how this gets handled - maintain backwards compatibility and notify other maintainers of your changes, anticipated migration requirements, and any deprecations. To which the responsibility falls on the other maintainers C, Rust, or otherwise.
- lokar 2y ago
  In practice (in general, not Linux specifically), you can make it all much faster and simpler by sending out the fixes for your change to impacted users. The ability to do this makes it much easier to change your api.
  - drpossum 2y ago
    Except we are talking about Linux specifically, the "users" here in your analogy are people working in the collective kernel code, and there is a unique culture and set of practices around maintaining this because it's not some REST API where if something breaks you just shove a bug fix out for your part.
    - lokar 2y ago
      Certainly APIs exposed to userspace can’t ever break. But if a change can be completely hidden by fixing everything all at once (as a trivial example, renaming something) that should be ok, no?
Ukv 2y ago
> If the codebase has multiple languages using my api I will need to make changes in these other languages if I want to do this. This is a very real cost to me. Current policy, at least in theory, is that the C interfaces can change as before and it's on the Rust maintainers to fix any issues on their side. From Linus's response: > So when you change the C interfaces, the Rust people will have to deal with the fallout, and will have to fix the Rust bindings. That's kind of the promise here: there's that "wall of protection" around C developers that don't want to deal with Rust issues in the promise that they don't have to deal with Rust.

by lokar 2y ago

drpossum 2y ago

I fail to see how this is a relevant question and "the real issue" with respect to Rust. How is this situation any different from a pure C kernel? There are already protocols on how this gets handled - maintain backwards compatibility and notify other maintainers of your changes, anticipated migration requirements, and any deprecations. To which the responsibility falls on the other maintainers C, Rust, or otherwise.

lokar 2y ago
In practice (in general, not Linux specifically), you can make it all much faster and simpler by sending out the fixes for your change to impacted users. The ability to do this makes it much easier to change your api.
- drpossum 2y ago
  Except we are talking about Linux specifically, the "users" here in your analogy are people working in the collective kernel code, and there is a unique culture and set of practices around maintaining this because it's not some REST API where if something breaks you just shove a bug fix out for your part.
  - lokar 2y ago
    Certainly APIs exposed to userspace can’t ever break. But if a change can be completely hidden by fixing everything all at once (as a trivial example, renaming something) that should be ok, no?

Ukv 2y ago

> If the codebase has multiple languages using my api I will need to make changes in these other languages if I want to do this. This is a very real cost to me. Current policy, at least in theory, is that the C interfaces can change as before and it's on the Rust maintainers to fix any issues on their side. From Linus's response: > So when you change the C interfaces, the Rust people will have to deal with the fallout, and will have to fix the Rust bindings. That's kind of the promise here: there's that "wall of protection" around C developers that don't want to deal with Rust issues in the promise that they don't have to deal with Rust.