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, or whatever other arguments the stupid "c-niles" always use.
Memory Safe Languages in Android 13
371–380 of 606 posts
Re: Memory Safe Languages in Android 13
#372Earlier quoted context omitted.
It's even worse. The majority, not of all bugs, but all vulnerabilities (of all severities) do come from memory safety bugs. TFA: "For more than a decade, memory safety vulnerabilities have consistently represented more than 65% of vulnerabilities across products, and across the industry." On top of that , memory safety vulnerabilities are disproportionately high severity: "Memory safety vulnerabilities disproportion…
> NOTE: down to 36% from 65% because of moving from C++ to Rust and other memory safe languages Imagine if in any other field, a process or technology were developed that cuts the number of high-severity issues in half. For example, a modification to the standard anesthesia protocols that demonstrably reduces anesthesia-related fatalities by 50% in clinical practice. And now imagine, in reaction to this revolutionary…
> 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 on the wrong part or person?
People are fallible. But checklists help a ton. We know that for sure. Why is aviation obsessed with following them? Because they work to increase safety.
Surgeons have resisted them. I don’t know the current state of it, but they were making that exact “good surgeons don’t need it” argument. I remember it being a plot point on an episode of a medical drama (ER? Or maybe Grey’s Anatomy).
There are probably tons of other examples in other fields.
Re: Memory Safe Languages in Android 13
#373Earlier quoted context omitted.
Google is one of the biggest C++ shops out there, and also authors and maintains many of the static analysis tools and safety features you mention. If they’re saying that C++ can’t be saved, maybe they’re worth listening to.
> If they’re saying that C++ can’t be saved, maybe they’re worth listening to. It might be true, but it also sounds like an appeal to authority. I suspect there also might be voices that are being silenced or aren't given a similar platform to speak up and provide an alternative viewpoint on the matter within the same organisation, because . After all, there are greenfield projects that are being started in C++20 and…
An appeal to authority is a fallacy because it doesn’t actually mean anything. It’s false credibility.
If the authority comes along with a bunch of well researched and documented data from experiences in the real world… that seems worth listening to.
It’s no longer an appeal to authority. It’s just looking at evidence.
Re: Memory Safe Languages in Android 13
#374Earlier quoted context omitted.
C-nile developers have been making incorrect arguments for a while now. The reality is which almost everyone can see is that memory safe languages are pretty much always what you want to be using for new code. OS and security sensitive components are the prime targets for rewrites in more secure languages. Now Google has put this to the test and has the data to prove it. We should not allow the worlds technology secu…
> The reality is which almost everyone can see is that memory safe languages are pretty much always what you want to be using for new code. Nitpick, this is not quite true. Memory safe languages are what you should be using in contexts where security and reliability are critical. This is generally the case but there are some contexts where other concerns are genuinely more important. Of course when this is necessary…
writing exploits, for example, is an utter pain in today's safe languages :) C is unmatched in the sheer ease of manipulating raw bytes with some light structuring on top for convenience. I've tried writing exploits in Swift a handful of times but I always gave up after I found myself buried under a pile of UnsafeMutableRawBufferPointers.
Re: Memory Safe Languages in Android 13
#375Earlier quoted context omitted.
But the compiler doesn't need to care in that case because it's not bounds checking those pointers in the first place in C. So that's not going to give you slow C code from bounds checking that the optimizer failed to eliminate. Like yeah there's aliasing changes, but in "idiomatic" C/C++ how is that getting you bounds checking that's not being optimized away fairly consistently?
Wait, previously you were talking about bounds checks which can't be optimised out, now you seem to be saying in C you wouldn't bother writing any bounds checks, which is a quite different claim.
I think what they're saying is that C compilers don't care about aliasing here because it's not actually bounds checking the pointers, it's just a numeric comparison between two random arguments. It's much easier for an optimizing compiler to eliminate a duplicated boolean check between two numbers this way because passing numbers from one function to the next has no aliasing concerns.
Re: Memory Safe Languages in Android 13
#376Earlier quoted context omitted.
I think a distinction can be made in that you never really need to use unsafe operations in python or Java. In rust, you need unsafe. Just about every data structure in the stdlib uses unsafe. I think it's fair to call Rust a memory safe language. But I don't think it's on the same tier as a fully managed language like python.
> I think a distinction can be made in that you never really need to use unsafe operations in python or Java. You can't write any code at all in Python or Java without relying on unsafe operations. Both of them have their runtimes written in C/C++. So based off of this unusual line of reasoning, Rust is strictly more memory safe than either of those as it's at least possible to have a Rust program without any unsafe…
>You can't write any code at all in Python or Java without relying on unsafe operations. Both of them have their runtimes written in C/C++.
This isn't a meaningful distinction, in the end. Hardware is unsafe too. Real production CPUs have bugs in them which lead to cache lines becoming corrupted, address translations being wrong, branches going to the wrong place, etc. under extremely weird conditions. But, in the end, we don't really do much about it because we trust that it probably won't impact us since we assume the people who built the SoCs or those who wrote the standard library did a good enough job.
Re: Memory Safe Languages in Android 13
#377Earlier quoted context omitted.
As somebody who appreciates Lisp, I feel your pain. As somebody who also appreciates Rust, I'm curious, what is your baseline?
Good design theory. https://www.doverbooks.co.uk/point-and-line-to-plane Consider h::i::j::k versus h.i.j.k Two :’s is an extremely loud combination of visual elements compared to the subtle point. :: drags the eye away from the content and says “look at me oscillate” In addition, humans group similar visual elements together so a combination of anything::doesnt::matter::what::between::clumps it is impossible to esca…
> look at me oscillate
I'm curious, are you dyslexic? Seeing letters move is generally something that people with dyslexia complain about.
Re: Memory Safe Languages in Android 13
#378Earlier quoted context omitted.
Cool kids and students move to Rust, C++ doesn’t have influx of new developers hence more demand for existing C++ developers.
We haven't seen the same thing for PHP and other obsolete languages. Cleanup janny work isn't as respected or well paid as building cutting edge new things in modern tools.
I think the theory is that the payoff comes later. Ideally the system quietly continues working well for decades, but needs maintenance and improvements 30 years from now, by which time most of the existing C++ programmers have retired.
If this hasn't happened for PHP, maybe because there are fewer critical infra projects written in it. If it's just another web service, that can be rewritten (unless it's at the scale of Facebook). Whereas the tens of thousands of firmware code bases and other critical infra - we won't even think about them for decades as long as they continue to work (or appear to). Let's check back in 2038!
Re: Memory Safe Languages in Android 13
#379Earlier quoted context omitted.
> But if "security" isn't remotely a concern for a given project (like almost anything graphics / gaming related) Gaming platforms have gotten a lot less lenient over time, and with pretty much every game these days having online components, "security isn't remotely a concern" has become a lot less true.
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 starting to make inroads in HPC/scientific computing. The libraries have a ways to go for widespread end-to-end adoption, but to give a concrete example, a current project has drastically beaten OpenBLAS across a suite of matrix factorizations. It was developed over a few months by one person with much less arch-specific or unsafe code. (The library is on GitHub/crates.io, but the author isn't ready for a public announcement so I won't link it yet.) Expect to see lots more Rust in HPC over the next few years.
Re: Memory Safe Languages in Android 13
#380Earlier quoted context omitted.
> NOTE: down to 36% from 65% because of moving from C++ to Rust and other memory safe languages Imagine if in any other field, a process or technology were developed that cuts the number of high-severity issues in half. For example, a modification to the standard anesthesia protocols that demonstrably reduces anesthesia-related fatalities by 50% in clinical practice. And now imagine, in reaction to this revolutionary…
> 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.