451–460 of 606 posts
I wonder if their efforts to leverage modern chip capabilities to address memory safety (e.g: ARM memory tagging) contributed to that drop of memory safety vulnerabilities
Earlier quoted context omitted.
Sure, but then there's things like HPC / offline graphics / simulation (VFX/CG), where performance is the end-all concern (or memory efficiency sometimes at the expense of CPU time), and security isn't a concern at all there, with lots of things like random index lookups into sparse arrays / grids, etc. I know for a fact that bound checks do make a bit of a difference there, as the data's random, so the branch predic…
"random index lookups into sparse arrays" is almost always an anti-pattern in HPC. Successful data structures are designed for streaming access and fine-grained parallelism, even when the problem domain seems irregular. Bounds checks sometimes matter (less in the logic than in inhibiting vectorization), but can sometimes be safely eliminated using existential lifetimes/branding or different control flow. Rust is star…
I do think Rust will make inroads, but more because of better WASM toolchain,so loading data into the browser is significantly easier than with JS (e.g. https://crates.io/crates/moc).
Rust apologists believe they are going to save the world. In order for them to do so, they have to uproot, destroy (deem it unsafe and insecure), and rewrite a lot of things they don't yet have influence over. A lot of people who are pushing back against Rust are doing so because they can sense this coercion, not because the language is ugly or "memory safety" issues aren't as significant as they are made out to be,…
Earlier quoted context omitted.
Surely this is true, but I still have the feeling that libraries in Rust tend to have more unsafe code than Java, Python, C# or others, maybe even more unsafe code than needed. Perhaps this is related to the problem domain.
You would definitely need to control for domain. A Rust library for some sort of mathematical modelling might well need no unsafe at all, while a Java library for controlling some hardware might soon turn into JNI talking to some C++ code and oops you're unsafe. In C# you need to reach for unsafe to do some of the stuff Rust can just do safely anyway. Did you know a C# struct with an array of 8 ints in it, doesn't ac…
https://learn.microsoft.com/en-us/dotnet/api/system.runtime....
In actual native code produced by RyuJit, you don't need to worry about cache lines for single instances, because the struct might not even exist at all, the Jit having mapped fields into CPU registers instead.
When it matters, like the struct being part of an array, use StructLayout.
I wonder if their efforts to leverage modern chip capabilities to address memory safety (e.g: ARM memory tagging) contributed to that drop of memory safety vulnerabilities
Looked this up as it's new to me. Seems interesting but not far enough, if you configure it to crash the system on an error for dev only, you aren't going to spot the hard to reach cases which are usually the target of these attacks, and having it set to crash on the release build is likely going to be seen as unacceptable. Something like Rust which can ahead of time verify that these issues aren't present is a bette…
Earlier quoted context omitted.
> Utterly unthinkable, isn't it? No. Ignaz Semmelweis faced it in the 1800s for daring to suggest (what we know know as germs) made people sick and hand washing could drastically reduce medical complications. He was able to prove it too. By the end was locked up in an asylum for his ‘crimes’. Want more recent? How many stories have you heard of instruments or gauze or whatever left in surgical patients? Of operating…
Semmelweis is ancient history. He was active at a time when regulations and "best practices" simply weren't a thing anywhere. Surgeons resisting checklists is new to me. Do you have a reference other than a TV show? My understanding until now was that checklists are extensively used in medicine.
Earlier quoted context omitted.
An example from an experiment to benchmark Rust and Java I did recently, where I sent files from one app to another: perf was good enough without tuning, with tuning I could triple the speed and final total time on both versions was comparable. Memory was much greater for Java (even with graalvm). The Rust version didn't suffer from any memory safety issues or race conditions when sending multiple files, but I did ha…
> Rust didn't protect me from that, and those are the kind of vulnerabilities that we'll continue seeing regardless of language. It didn't on its own, but it is worth noting that with type-safe languages, you can protect yourself from this by encoding that invariant into the type system. Using Rust as an example, take a &std::path::Path (or &camino::Utf8Path or whatever) in your public API; have custom InternalPathBu…
Earlier quoted context omitted.
> This isn't primarily about replacing existing software. There are plenty of engineers that argue for continuing to use memory-unsafe programming languages. > New projects written in C are being started every day. But it is mostly about existing software, even if its not about replacing existing software. I write C++ code every day. I hate it, and I'd rather not. But I use C++ libraries written by my teammates, and…
> > if the programmer is "smart enough". > Can't defend this, but tbh I've never heard it. Take a look at this comment: https://news.ycombinator.com/item?id=33824934 > Modern C++ has many memory safety features. If a company has learned that its people fail to use them, then bad for them. It is a somewhat common attitude in this type of thread.
Except the safety features are often a lot easier to use than the original C isms that tend to cause the most issues. So it is less an issue of smart and more one of bad habits. C strings instead of std::string, plain arrays instead of std::vector, implicit ownership instead of smart pointers, ... .