361–370 of 430 posts
now ahow me how rust can protect us against tech giants doing sauron moves on our software ecosystems?
Earlier quoted context omitted.
>if your code compiles, it usually runs just fine. This was the same argument for Java, which is memory safe, fairly strict in terms of ownership. The fact is, Rust addresses only one memory safe thing, and that is double free. If you don't understand why that is, you probably shouldn't talk about memory safety. The dividends never get there if you don't ever run into this. >And then there's the fact that the program…
> The fact is, Rust addresses only one memory safe thing, and that is double free. If you don't understand why that is, you probably shouldn't talk about memory safety. How does Rust not address use after free?
There is a reason why most vulnerabilities these days are either higher level logic bugs, or things that require code execution on the machine.
Earlier quoted context omitted.
> The fact is, Rust addresses only one memory safe thing, and that is double free. If you don't understand why that is, you probably shouldn't talk about memory safety. How does Rust not address use after free?
Not to mention out-of-bounds access, uninitialized memory, invalid type casting, and a ton of insidious sources of undefined behavior
Earlier quoted context omitted.
Rust makes sense in the case of Android, where the kernel and software is rolled by Google. In the same way that Java made sense for a lot of the backend services in 2010s despite its drawbacks before Node and Python got major improvements in speed and compute became cheaper. That however is a very niche case where Rust is applicable. The anti-rust people (like me) aren't saying that Rust is bad. We are just arguing…
There is this dumb belief stemming from lack of proper CS education that any code you write can just randomly have memory safety issues. This is effectively true in C and C++ though. Show me a nontrivial project in either of those languages that has never had a memory safety issue and I'll show you a project that doesn't look at quality. Even SQlite doesn't meet this bar, despite incredibly skilled programmers and an…
I mean, the linux kernel is a pretty good example. Static analyzers and things like valgrind exist for a reason.
Earlier quoted context omitted.
Rust makes sense in the case of Android, where the kernel and software is rolled by Google. In the same way that Java made sense for a lot of the backend services in 2010s despite its drawbacks before Node and Python got major improvements in speed and compute became cheaper. That however is a very niche case where Rust is applicable. The anti-rust people (like me) aren't saying that Rust is bad. We are just arguing…
> There is this dumb belief stemming from lack of proper CS education that any code you write can just randomly have memory safety issues. I sense a lack of statistical education here.
Earlier quoted context omitted.
Rust makes sense in the case of Android, where the kernel and software is rolled by Google. In the same way that Java made sense for a lot of the backend services in 2010s despite its drawbacks before Node and Python got major improvements in speed and compute became cheaper. That however is a very niche case where Rust is applicable. The anti-rust people (like me) aren't saying that Rust is bad. We are just arguing…
> There is this dumb belief stemming from lack of proper CS education that any code you write can just randomly have memory safety issues. lol. this take is hilarious in the face of the article you are commenting on. holy cognitive dissonance. > The downsides of Rust is that its ownership semantics are often cumbersome to write skill issue
Lol, this is actually very ironic considering Rust is handholding you because you don't have the skills to write memory safe code.
Like I said in my other posts, Rust makes sense in very niche situations. The article just proves that it works for the niche case where its applicable. That doesn't mean Rust automatically wins.
Earlier quoted context omitted.
>It's all nonsense, How is any of that wrong?
It isn’t wrong, it’s misguided. You can write the same code in a Turing machine, too.
Earlier quoted context omitted.
>It's all nonsense, How is any of that wrong?
1. You don't know what you're doing - everyone makes mistakes. 2. You can still write bugs in Rust but the point is you are far less likely to.
I mean if you don't know what you are doing you are going to make mistakes that go beyond memory safety. Look at Log4shell for example.
Earlier quoted context omitted.
The issue with most codebases is nobody thinks about starting out with acceptance testing system. The way it should work is that before even writing code, you design a modular acceptance system that runs full suite of tests or a subset based on what you are working on. This is essentially your contract for software. And on a modular level, it means that it scopes down the contracts to the individual sub systems. And…
Writing the tests before the code only really works if there's an interface that's fully defined and well specified in advance. There are definitely times where that is the case, but in my experience it usually doesn't work like that.
Earlier quoted context omitted.
> There is this dumb belief stemming from lack of proper CS education that any code you write can just randomly have memory safety issues. I sense a lack of statistical education here.
If you say that something can happen, then whether to use a tool to mitigiate it should also be qualified. The conversation around Rust is that bugs WILL happen, which is not true.