News for hackers. Stuff that matters.
Re:Why Rust mutexes look like they do by verdagon on Friday April 01, 2022 @09:44PM (#30885160)
> There are important language features missing from C (and C++) that make it impossible to implement a Rust-style mutex API with the same guarantees

I've done some experimenting here, and I think it is possible to add a borrow checker to a C or C++ -like language, like the author hints. It couldn't be like Rust's borrow checker, it would just need to be a borrow checker that operates on a "per region" basis, where everything inside the mutex is one region and everything outside is another.

I wrote a little bit about this idea for the Vale language in [0] and then realized shortly afterward that the idea can be used to add fearless concurrency to any existing language.

[0]: https://verdagon.dev/blog/seamless-fearless-structured-concu...

Re:Why Rust mutexes look like they do by hermanradtke on Saturday April 02, 2022 @01:38AM (#30886068)
It is definitely possible. What is not possible is convincing all your co-workers to use it or updating all the libraries you depend on to use it. Thus, the value prop becomes quite low.
Re:Why Rust mutexes look like they do by verdagon on Saturday April 02, 2022 @02:01AM (#30886152)
Perhaps, but maybe there's a better approach. I prefer having a new language which can build on and speak to other languages in their own paradigms. That's what Swift did for Obj-C and also the direction we're going with Vale's region borrow checker.
Re:Why Rust mutexes look like they do by hermanradtke on Saturday April 02, 2022 @01:08PM (#30889815)
C is the lingua franca of systems languages. Rust, nim and zig all seem very capable of wrapping C libraries while providing more safety.
Re:Why Rust mutexes look like they do by pjmlp on Saturday April 02, 2022 @02:50AM (#30886328)
That is why SecDevOps team turns on the static analysis on the CI/CD server, with the decision backed by the security guidelines.

Then they can suck it up or move elsewhere.