Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory Safe Languages in Android 13

security.googleblog.com

Post reply on HN
Print view View original

201–210 of 606 posts

Re: Memory Safe Languages in Android 13

#201

Post by masklinn »

phaylon wrote: post #195
masklinn wrote: post #183

Earlier quoted context omitted.

There is since that's what you declared. impl Foo { // static fn foo() {} } impl Foo { // instance, owned fn foo(self) {} } impl Foo { // instance, borrowed fn foo(&self) {} } impl Foo { // instance, boxed fn foo(self: Box ) {} } impl Foo { // instance, refcounted fn foo(self: Rc ) {} }

Small nitpick: Fortunately, `Rc` and `Arc` actually don't require the nightly feature.

Oh yeah you're right that's been stabilised, now that I'm thinking about it, it was probably something like `self: std::sync::MutexGuard` which told me to enable the feature

Re: Memory Safe Languages in Android 13

#202

Post by amalcon »

LAC-Tech wrote: post #33

For me the biggest features of rust are: - great standard library, especially all the iter methods. having 'obscure' stuff like `try_for_each` just makes me so happy as a dev - unit tests built into the lang - tooling is great - docs are top notch The memory safety aspect is... sometimes helpful, sometimes irritating. I prefer zig solution (BYO allocator, special one for testing that reports errors) over rusts, which…

Honestly, my favorite parts about rust are:

- It has the best parts of C (code generation is predictable, no mandatory extra thread for GC or similar, interoperates very well with C code)

- It also has some of the niceties that were popularized after C (type inference, an equivalent of unions that isn't terrible, macros that are not terrible, functional features)

- The thread safety stuff. Async has issues, but the core thread safety constructs (send, sync, mutex vs atomic, etc) are just so well designed that rust is by far my favorite language for writing synchronous, shared-memory threaded code. It's quite possible to mess it up, but it's far easier to keep that system in my head than any comparable one that I've used. Of course shared-nothing is even easier, and rust lets you do that too!

I don't use it for everything, but when I do encounter a thing rust is good at, it's just a treat.

Re: Memory Safe Languages in Android 13

#203

Post by yosefk »

berkut wrote: post #189
masklinn wrote: post #158

Earlier 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…

Everybody who works with Maya, Flash (now Adobe Animate) etc. knows that they crash all the time, and often corrupt files so you back them up every hour or so. Carmack insists, in a gaming context, to run heavyweight, high-false-positive-rate static analyzers because users don't like crashes.

When C++ dies (which in 20 years it will, and I wasn't that hopeful 20 years ago), people will look in the same bewilderment at excuses made for its insane behavior as they look now at mid-20th-century arguments against high-level languages (and assemblers before them - like Mel said, "you never know where it will put things so you'd have to use separate constants.")

Re: Memory Safe Languages in Android 13

#204

Post by nneonneo »

thesuperbigfrog wrote: post #175
nneonneo wrote: post #155

Earlier quoted context omitted.

- 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. Has substantial uses in certain areas. Ada is primarily used for low-level systems programming and embedded systems: https://learn.adacore.com/courses/intro-to-ada/chapters/intr... Substantial portions of the Ada standard deal with systems programming and low-level representation on hardware: http://www.ada-auth.org/standards/22rm/html/RM-C…

Thanks for the correction. I will update my comment accordingly.

Re: Memory Safe Languages in Android 13

#206

Post by hknmtt »

programming language developers always made compilers to just do that - compile the code. without actually checking the code for problems and allowed programmers to write faulty code. and now we have accepted these memory leaks and shooting oneself into one's foot as normal. so instead of investing time to make compilers output safe programs we had to wait for rust to come by and its "first time in history" compiler while it limits the programmers tremendously to do that along with the ugliest syntax ever invented. when a programmer looks at faulty code, the bug can be seen. sometimes easily, other time not as easy but it can be identified nevertheless. that means we, humans, can detect them. so why can't programs do the same while having way more computing power at their disposal for that particular task, along with language definition and type system? everyone keeps writing new languages and trying to reinvent the wheel in blue, red, purple color instead of solving the actual problem.

Re: Memory Safe Languages in Android 13

#207

Post by gnull »

lolinder wrote: post #116

Their notes about vulnerability severity are particularly interesting. 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 of switching to a new language. Google's data suggests that while this is true, almost all severe vulnerabilities are related to memory safety. Their switch to memory-safe languages…

> 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.

Re: Memory Safe Languages in Android 13

#208

Post by [deleted] »

masklinn wrote: post #170
joshuamorton wrote: post #119

Earlier quoted context omitted.

Yes. They found 250 bugs after analyzing the entirety of rust and all of it's packages. There are probably more memory safety bugs in the python standard library and top 50k packages.

The rust project itself also has an extremely aggressive CVE policy (which many find too aggressive): if unsoundness is found in an API it gets a CVE, no matter how convoluted, and how unlikely it is to get into that situation, with absolutely no guarantee of any code in the wild coming even close to the unsoundness. Essentially, the Rust standard is that more or less every line of the C++ standard is a CVE. Hell, th…

[deleted]

Re: Memory Safe Languages in Android 13

#209

Post by Taywee »

yosefk wrote: post #203
berkut wrote: post #189

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…

Everybody who works with Maya, Flash (now Adobe Animate) etc. knows that they crash all the time, and often corrupt files so you back them up every hour or so. Carmack insists, in a gaming context, to run heavyweight, high-false-positive-rate static analyzers because users don't like crashes. When C++ dies (which in 20 years it will, and I wasn't that hopeful 20 years ago), people will look in the same bewilderment a…

> which in 20 years it will, and I wasn't that hopeful 20 years ago

That's too optimistic. C++ would easily die in 20 years if it didn't already have 30+ years of still-active legacy that can't easily be converted or rewritten.

I've recently even had to start new projects in C++ because platforms I depend on demand it or because I have to interface with existing code and libraries that still only exist as C++. I'm not a fan of the language by any means, but I'll eat my shoe if it's "dead" in 20 years for anything except maybe greenfield development.

Re: Memory Safe Languages in Android 13

#210

Post by UncleMeat »

faitswulff wrote: post #205

No mention of Carbon among the new memory safe languages. I wonder what inside baseball is at play with language selection.

Carbon is not production ready yet. It doesn't even have a publicly available compiler (just an interpreter). Carbon is more about answering "what do we do with the billions of lines of C++ code we've got" than "what is the best way to add new code to a system."
Post reply on HN