Re:Rust solves the problem of incomplete Kernel Linux API docs
by misiek08 on Saturday August 31, 2024 @01:20PM
(#41410311)
For project like this one - it would be cumbersome, but proper Java is also solving the problem. Currently we write code without all throws definitions, because those are handled by Spring-like monsters or other libraries, but having method definied with LockedEx, NullPointerEx etc. is even more friendly as doc generation. Funny, but I don’t like Java that much, but it’s one of those languages also solving documentation problems here.
Yes I know it’s "faster-development" to have type instead of additional definition attributes, but I think the problem would be also solved.
Re:Rust solves the problem of incomplete Kernel Linux API docs
by dagmx on Saturday August 31, 2024 @12:49PM
(#41410101)
The posted link talks about how the types act as documentation, and in turn enforce it. I’d recommend reading the whole thread that someone else posted below.
Re:Rust solves the problem of incomplete Kernel Linux API docs
by layer8 on Saturday August 31, 2024 @01:07PM
(#41410232)
I was criticizing your incorrect inference “memory-safe language => better-enforced API contract”. The only thing memory-safe languages do in that context is to remove a single aspect from the universe of things that can be ambiguous in an API, and they also don’t cause anything else to be enforced. (Rust does more, but that’s because of properties beyond mere memory-safety.) In other words, “memory-safe language” doesn’t mean what you want it to mean.
Re:Rust solves the problem of incomplete Kernel Linux API docs
by dagmx on Saturday August 31, 2024 @01:59PM
(#41410574)
Jeez, there’s a whole comment above that explaining the context and caveating it with the needs of robust type system too.
If you’re pedantically holding on to one sentence as a gotcha, because I didn’t caveat everything, then fine. But seems a bit much to then say I’m forcing a definition just because you ignore the rest.
Many of the same problems — the mentioned underdocumented API assumptions — exist in memory-safe languages like Java and C#. Memory safety is just one among many aspects in interface contracts, and is actually often one of the better documented ones in non-memory-safe languages.
Type-based checking is of course very beneficial, but TFA specifically focuses on the documentation aspect, not on the enforcement, which are in principle orthogonal to each other. TFA draws attention to the fact that the enforcement here also entails better self-documentation. However, it’s limited to whatever aspects the type system enforces.