6 ms·
Every time I hear the term "lowest common denominator" applied to programmers, I reflect on the number of network-accessible remote exploits that provide root a
by ttfkam 5y ago
Every time I hear the term "lowest common denominator" applied to programmers, I reflect on the number of network-accessible remote exploits that provide root access via the Linux kernel over the past three decades.
And yet the folks maintaining the network stack in the Linux kernel are not anywhere near what I or almost anyone else would consider the lowest common denominator programmer.
Sometimes you just have to accept that ALL humans are inherently bad at this, only some are worse than others at various points in their lives. The security and reliability of the product of our output should not be so largely dependent upon our ability to get a full night's sleep, reasonable working hours, and lack of personal conflict. To be sure, we should all strive for those things, but perhaps the choice of tools is correct in prioritizing mitigation of difficulties and vulnerabilities from meatspace.
Sometimes that's a borrow checker. Other times it's a garbage collector. And every once in a while, we need to break out an unsafe block (or the entire C language) to get a job done.
Considering how much more expensive people are than software or hardware, the trade off for easier/simpler access is increasingly straightforward.
- deleted 5y ago[deleted]
- jkilpatr 5y agoWhile I strongly agree this doesn't seem to match the sentiment of the paper. Which is prioritizing a lower barrier to entry for new programmers at the cost of safety checks that help prevent humans from making mistakes at runtime. It seems to me if our conclusion is humans, no matter how skilled, are flawed, we should be willing to do absolutely anything to lower the barrier to entry except removing checks on correctness.
- bjourne 5y agoWhat makes you say that? What safety or correctness features do you think a garbage collector in Rust eschews? On the contrary, gc should make the language safer since it obviates the need for the "unsafe" escape hatch.
- jkilpatr 5y ago> A key tradeoff is that Bronze does not guarantee thread safety Data races are currently prevented by the borrow checker. Any GC in order to provide equivalent correctness would need to do so as well.
- dahfizz 5y agoIf you read the paper, they needed to throw out the thread safety from Rust's borrow checker in order to make the GC work. That is a massive surface area for bugs they are opening back up to make the language easier for beginners.
- bjourne 5y agoBecause their gc is a proof-of-concept created specifically for this research. It doesn't even deallocate memory. Most likely, they didn't have their students write any threaded code so thread-safety wasn't a concern. For a production ready tracing gc, of course they would add thread safety, it's not a big problem.
- dahfizz 5y agoNo, this is the fundamental tradeoff they made to make the Bronze'd Rust easy to use: > Rust permits only one mutable reference to a value at a time... With Bronze, mutation is permitted through all references to each garbage-collected object, with no extra effort. A key tradeoff is that Bronze does not guarantee thread safety; as in other garbage collected languages, it is the programmer’s responsibility to ensure safety. Allowing mutability anywhere is what fundamentally makes Bronze easier to learn, and more error-prone.
- bjourne 5y agoThe paper's author has already explained to you how thread safety can be achieved in a production-ready gc. This is not something that is particularly difficult to engineer and is quite orthogonal to whether one chooses to use tracing gc, ref counting or Rust-like borrow checking.