6 ms·
> You aren't borrowing you are doing pointer manipulation, and presenting it with stuff that isn't its duty to check. Yeah exactly - you're sectioning off part
by skohan 4y ago
> You aren't borrowing you are doing pointer manipulation, and presenting it with stuff that isn't its duty to check.
Yeah exactly - you're sectioning off parts of the code and telling the borrow checker to trust you that it's ok.
You can't simultaneously argue that unsafe languages are categorically bad and also use unsafe rust as an argument against rust's limitations. Unsafe is either bad or it isn't.
> That said, miri should be able to check your unsafe for undefined behavior. https://pramode.in/2020/11/08/miri-detect-ub-rust/ https://pramode.in/2020/11/08/miri-detect-ub-rust/
Static analysis tools outside of the language would also be the way you would check for UB and unsafe behavior in languages like C and Zig.
> Yes. It is a small downside, with a huge upside.
Depending on use-case. Again if your whole programming domain is about memory layouts and the management of allocations, you might want to choose a tool with explicit memory management.
> You'd need to offer hard proof that code you wrote in alternative way, wouldn't have those issues.
Again Rust is only one way to prove those errors don't exist. And for a lot of use cases absolute guarantees of memory safety might not be the greatest concern.
For instance, let's say I am making an HPC program for identifying pricing arbitrage in the market which generates 10 million dollars a day when it's operating. If it takes 10 days longer to implement in Rust, that cost me 100 million dollars. I am not going to care if it crashes twice a day because of an NPE I didn't catch.
> And that alternative way might still be expressible in Rust using some abstraction/unsafe.
Again, once you use unsafe Rust, why not just use an unsafe language?
> You mentioned how Python enabled more people to code. I'm willing to bet if only enabling to code then Excel and Access brought programming to more people, yet we don't see them in use, because maintaining is painful and hair tearingly frustrating.
What's your point? Python is not the easiest code to maintain in the world due to lack of static typing and a host of other issues, but it allows data scientists and others to produce billions of dollars worth of value around the world in ML, AI, and business intelligence operations. You could say they could write more correct, more maintainable programs in Rust, but that pool of practitioners just don't exist who are advanced data scientists and also Rust developers. It's a different tool for a different job.
> And performance is meh as well, but Python isn't winning any speed medals either.
And it doesn't matter because performance isn't relevant in most of the applications where it's used. Just another example of a tradeoff.
> I value code that has less footguns than more footguns.
You might value that but it doesn't mean it's an objective measure of a programming language for all people and all use cases.
> Rust showed we can eliminate several cases of footguns, so why add them back?
It's not "adding them back". Strict ownership enforcement is not a universally accepted advancement in programming languages which every new language gets measured against. It's an experiment Rust is running. It remains to be seen whether it's the right way to do programming.
> 3+ billion humans use spaces and punctuation as a error checking mechanism.
I don't even know what to say to this. Spaces and punctuation got accepted because they're more ergonomic and universally accepted by consensus as the better solution for making text readable. It's a better UX for reading.
Most system programmers do not program in rust. There's no consensus that it has chosen the right tradeoffs.
- Ygg2 4y ago> You can't simultaneously argue that unsafe languages are categorically bad and also use unsafe rust as an argument against rust's limitations. Unsafe is either bad or it isn't. I'm not arguing philosophically. I'm arguing from a safety viewpoint. A language that's 100% unsafe is worse than a language that's 1% unsafe. Saying it's not perfectly safe is sophistry. Nothing is perfectly safe, but you still don't hand out your sensitive bank information to random person on the Internet/street/etc. > Again, once you use unsafe Rust, why not just use an unsafe language? Assume data race happen. Would you prefer to audit 30k lines or 3? Unsafe language is unsafe everywhere. In Rust, you can limit your search to unsafe regions. > Static analysis tools outside of the language would also be the way you would check for UB and unsafe behavior in languages like C and Zig. Define outside language? Miri is maintained by rust-lang team. And Clippy and so on. Sure valgrind and so forth aren't, but their checks are somewhat complementary. > For instance, let's say I am making an HPC program for identifying pricing arbitrage in the market which generates 10 million dollars a day when it's operating. If it takes 10 days longer to implement in Rust, that cost me 100 million dollars. I am not going to care if it crashes twice a day because of an NPE I didn't catch. Sure, but if your implementation has a data race error, that when triggered happens causing massive loss of funds. First you'll have to find the issue (good luck searching most of language and deps). Then you need to patch it to prevent future errors. And it can happen again. So maybe 3 days here, 5 days there, 4 days there, and so on. Granted it's a contrived example, but hey... If you want HPC and safety use Java/C#/Lisp, no Rust necessary. Point being - Strength of Rust isn't in speed of development, so much as in avoiding certain sets of bugs. And borrow checker isn't the only tool to achieve this. > Depending on use-case. On that I agree. If your game is one and done (no maintenance), no user content, no MP, basically worse that can happen is crash sure go ahead. Jams are in that way perfect candidates for small langs where speed of development is crucial. I'd argue most sold games aren't one and done. > I don't even know what to say to this. Spaces and punctuation got accepted because they're more ergonomic and universally accepted by consensus as the better solution for making text readable. Keep in mind that in Rome everything was written without spaces for hundreds of years. From their POV the spaces would be just unnecessary fluff. And there are still languages that have little to no spaces, so spaces aren't even universally accepted. See Chinese and Japanese. > Most system programmers do not program in rust. I don't understand, this wasn't specific about just systems language? Going from C# to Zig is a safety downgrade (but a possible performance uplift). And GC langs have been used in OS implementations. > There's no consensus that it has chosen the right tradeoffs. Sure, but consensus is a matter of current status and it's not set in stone. Status quo is C, which has null - a trillion dollar mistake (adjusted for inflation and software spread :P) > What's your point? Python is not the easiest code to maintain... My point that we use Python won in ML because allowing people to achieve value isn't the only important aspect. There are many aspects. Sure you get to pick your own, but I've seen too many CVEs caused by memory unsafety. But safety and reducing footguns should be ideals for any language to strive. Reintroducing footguns? What's next? Return of GOTO Spaghetti monster.