this post was submitted on 29 Aug 2024
139 points (90.6% liked)

Linux

8066 readers
57 users here now

Welcome to c/linux!

Welcome to our thriving Linux community! Whether you're a seasoned Linux enthusiast or just starting your journey, we're excited to have you here. Explore, learn, and collaborate with like-minded individuals who share a passion for open-source software and the endless possibilities it offers. Together, let's dive into the world of Linux and embrace the power of freedom, customization, and innovation. Enjoy your stay and feel free to join the vibrant discussions that await you!

Rules:

  1. Stay on topic: Posts and discussions should be related to Linux, open source software, and related technologies.

  2. Be respectful: Treat fellow community members with respect and courtesy.

  3. Quality over quantity: Share informative and thought-provoking content.

  4. No spam or self-promotion: Avoid excessive self-promotion or spamming.

  5. No NSFW adult content

  6. Follow general lemmy guidelines.

founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] themusicman@lemmy.world 23 points 2 months ago

If rust code relies on a C API (as it necessarily does), then a breaking change to the API requires changing that rust code. This is common sense.

If a process is set up for deferring rust maintenance to a rust developer, this can only last as long as rust maintainers are willing to staff it.

If C developers are unwilling to accept any risk of needing to touch rust code in the future, then rust contributions should not have been allowed in the first place.

Allowing rust contributions and then imposing restrictions on what can be done with it? That's not reasonable.