Who cares about memory safety when the entire platform is already an advertising shitshow full of spyware?
Memory Safe Languages in Android 13
301–310 of 606 posts
Re: Memory Safe Languages in Android 13
#302Earlier quoted context omitted.
There's been many, for example Ada/SPARK, D, Nim, Java, Kotlin, Swift.
- Ada: good example, has substantial uses in certain areas. However, certain things are quite difficult, e.g. compile-time checked pointers (a la Rust's borrow-checked references). - D, Nim: neither provide strong memory safety guarantees. D has a safe subset, but it's not default (see https://news.ycombinator.com/item?id=12391720 ). Nim allows you to turn checks off at runtime. Both Nim and D generally use a GC. - J…
> Ada: good example, but not usually used for low-level systems programming
Ada is used for low-level programming plenty.
> Nim allows you to turn checks off at runtime.
That's not relevant.
> Both Nim and D generally use a GC.
No, Nim now uses deterministic reference counting ARC and provides safety similar to Rust.
Re: Memory Safe Languages in Android 13
#303Earlier 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.
Programming languages are tools for a job. As the saying goes, a bad workman blames his tools. It's not worth taking anyone who blames defects on a programming language too seriously, whether it's Google or not. Modern C++ has many memory safety features. If a company has learned that its people fail to use them, then bad for them. Of course, there are languages that abstract memory safety to the point that they elim…
Modern C++ has many memory safety features. If a company has learned that its people fail to use them, then bad for them.
This recapitulates an argument at least as old as C89. You can probably find Usenet posts deploying it to argue against the adoption of strncpy, because if people don't know how to use sizeof and strlen, then bad for them.
Re: Memory Safe Languages in Android 13
#304Earlier 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.
Programming languages are tools for a job. As the saying goes, a bad workman blames his tools. It's not worth taking anyone who blames defects on a programming language too seriously, whether it's Google or not. Modern C++ has many memory safety features. If a company has learned that its people fail to use them, then bad for them. Of course, there are languages that abstract memory safety to the point that they elim…
A bad workman may blame his tools, but a good workman uses the right tool for the job. If a better tool exists, use it.
(And sure, it doesn't apply to every niche yet, but it sure applies to a lot of them)
Re: Memory Safe Languages in Android 13
#305Earlier 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…
> 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 escape the common pattern and the eye jumps between the ::’s. Therefore it takes double the cognitive load to read.
It is true that the colons take up more space and your example looks good on HN.
But this problem will be immediately solved by syntax coloring. It's just never going to come up.
Re: Memory Safe Languages in Android 13
#306Earlier quoted context omitted.
> Defenders of C/C++ frequently note that memory safety bugs aren't a significant percentage of the total bug count, and argue that this means it's not worth the hassle This says more about those C++ defenders.
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 is often misrepresented but these cases do exist.
Re: Memory Safe Languages in Android 13
#307Earlier quoted context omitted.
Programming languages are tools for a job. As the saying goes, a bad workman blames his tools. It's not worth taking anyone who blames defects on a programming language too seriously, whether it's Google or not. Modern C++ has many memory safety features. If a company has learned that its people fail to use them, then bad for them. Of course, there are languages that abstract memory safety to the point that they elim…
Modern C++ has many memory safety features. If a company has learned that its people fail to use them, then bad for them. This recapitulates an argument at least as old as C89. You can probably find Usenet posts deploying it to argue against the adoption of strncpy, because if people don't know how to use sizeof and strlen, then bad for them.
strncpy is bad for other reasons, mind you.
Re: Memory Safe Languages in Android 13
#308Earlier quoted context omitted.
> 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…
C++ is needlessly complex and puts too much of a cognitive burden on the developer. I just wasted a day of my life traced to an errant semicolon in a legacy cpp base. I've used the language for 20 years. It can't be saved.
No offense, but I haven’t heard if people wasting days in semicolons outside of memes and really junior developers. What was the issue?
Re: Memory Safe Languages in Android 13
#309Earlier 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.
Programming languages are tools for a job. As the saying goes, a bad workman blames his tools. It's not worth taking anyone who blames defects on a programming language too seriously, whether it's Google or not. Modern C++ has many memory safety features. If a company has learned that its people fail to use them, then bad for them. Of course, there are languages that abstract memory safety to the point that they elim…
> As the saying goes, a bad workman blames his tools.
And a good workman put his old/obsolete/dangerous/etc tool behind when something better show up.
The bad workman, instead, continue blaming his tools, when the problem is that he CONTINUE using bad tools, anyway!.
P.D: I learn about mechanical engineering. Get rid of bad tools fast is like key around that...
Re: Memory Safe Languages in Android 13
#310Earlier quoted context omitted.
Is there any practical programming language that is memory safe in its "entirety"? Python, for example, certainly is not. It has unsafe escape hatches (via ffi, at the very least). Yet, everyone I know of says and thinks of Python as a memory safe language. I do as well. > which makes it easier for developers to compartmentalize code to achieve memory-safety The problem here is that this is incomplete. Many many many…
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.
Maybe. I don't know. You'd have to collect some data.
> Perhaps this is related to the problem domain.
Yes, I included that possibility in my comment here: https://news.ycombinator.com/item?id=33821787