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

481–490 of 606 posts

Re: Memory Safe Languages in Android 13

#481

Post by ilyt »

j16sdiz wrote: post #383
raggi wrote: post #338

Earlier quoted context omitted.

> We should not bury C++ prematurely before answering the question - "what else is as fast and efficient as to replace it for OOP?" We have an answer: Rust. It's no longer premature, bury it.

Rust is over engineered in some area, immature in other. See how many reference types are there, how async is handled and the underspecified unsafe semantic. For higher level tasks, I prefer a language with GC like go or java. Rust can work with references counting, but it don’t mix well with the larger ecosystem. For lower level task, the underspecified unsafe model make it worse than C aliasing problem

I vastly prefer "just write you code serially and never worry about async then spawn 10000 goroutines" approach over async/await/Future nexus of bad ideas (just do message passing like Erlang or don't do it at all...), but I wouldn't use Go in place where I'd use Rust and vice versa, they kinda feel different (if overlapping in places) niche

Re: Memory Safe Languages in Android 13

#482

Post by jstimpfle »

wrongtime wrote: post #469
jstimpfle wrote: post #439

Earlier quoted context omitted.

It's not like you make a bad git commit and suddenly the world stops working. There are checks and processes and redundancies that reduce the impact of human error dramatically. The earth is still spinning, despite so many things not working everywhere. That's not just in software. In every system, there's relatively few single points of failure. As you zoom out, failure points disappear and new ones appear. Sure, st…

>It's not like you make a bad git commit and suddenly the world stops working. https://qz.com/646467/how-one-programmer-broke-the-internet-...

Sure, I know this. I don't think this contradicts my argument. It didn't suddenly make running infrastructure exposed. But yeah, people needed to find a replacement to continue development (which I hope wasn't hard)?

If this breakage is an argument for anything, it is against depending on lots of code that you don't even know. The last Rust projects I tried to build all had on the order of 500 transitive dependencies, by the way.

Re: Memory Safe Languages in Android 13

#483

Post by jstimpfle »

cjg wrote: post #447
jstimpfle wrote: post #426

Earlier quoted context omitted.

I'm one of those people who still write in C, and I like the experience. I've had a lot of fun, and haven't been burned by it, although statistically it's likely that I will be at some point. I've tried a lot of languages in the past, and am currently not willing to dive into a whole new ecosystem, re-learn all the best practices, and unlearn what's worked very well for me with sometimes no good replacement. Best pra…

Implementing a linked list in Rust is somewhat challenging because of the safety issues that arise. Luckily you don't have to, there's one in the standard library: https://doc.rust-lang.org/std/collections/struct.LinkedList.... The equivalent of a generic memcpy is probably something like a .clone() call on a generic type that implements Clone.

This isn't an intrusively linked list.

Probably not the Clone trait but the Copy trait.

Re: Memory Safe Languages in Android 13

#484

Post by ilyt »

berkut wrote: post #218
yosefk wrote: post #203

Earlier quoted context omitted.

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…

At least in VFX, at the high-end Maya's only really used for modelling/UVing/layout now, other apps have taken over the rendering/lighting side of things... But anyway, in my experience a lot of the crashes are often due to quickly hacked together plugins for the various DCCs written for artists, that don't have good error checking or testing, and it's not completely clear to me how that situation's going to improve…

I kinda hate .unwrap() even exists, it leads to excessively shitty error messages with no good context

Re: Memory Safe Languages in Android 13

#485

Post by steveklabnik »

kaba0 wrote: post #409
tialaramex wrote: post #346

Earlier quoted context omitted.

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…

> You need unsafe. You beed it for that feature. It is questionable whether you really want to mandate a special memory layout (because you can’t really do that even in Rust, you don’t have explicit control of struct alignments, paddings, order(!) )

Rust absolutely gives you control over alignment, padding, and ordering. It’s just not the default. Ask for those things and you shall be given it.

Re: Memory Safe Languages in Android 13

#486

Post by sitkack »

dralley wrote: post #365
p-e-w wrote: post #356

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

Well, not exactly. There have been plenty of advancements in bridge / highrise construction over the past 100 years, but in practice we don't go around tearing down old infrastructure that is still functional because it was built with outdated designs and technologies, even when it could theoretically save lives. Buildings get "grandfathered" into meeting code all of the time. Software is not terribly different from…

> we don't go around tearing down old infrastructure

All the time! And the stuff we don't tear down, we retrofit.

Re: Memory Safe Languages in Android 13

#487

Post by tome »

jstimpfle wrote: post #429
foxes wrote: post #370

Earlier quoted context omitted.

Where has time to market and productivity ever been a factor for C and the C ecosystem? My most "productive" languages have been declarative languages like Haskell (depending on how you measure that). I don't care if it takes an extra few minutes to compile either, amortized away in the long term when you don't have to deal with entire additional classes of bugs to deal with. Also why is security never an important c…

I spent a considerable amount of time learning Haskell but I always felt like a slave to the language. Oh, you want to do this other simple thing? Try language extension XYZ, but you'll have to learn some more language theory first. Also sorry but the extension isn't compatible with the extensions you're already using, and you need to require a new dependency on the outside interface. There are some things that the l…

> sorry but the extension isn't compatible with the extensions you're already using

In nearly 10 years of professional Haskell I've never come across a practical situation where extensions that were mutually incompatible. Can you name any extensions that are incompatible in a way that actually matters in practice?

Re: Memory Safe Languages in Android 13

#488

Post by peoplefromibiza »

ilyt wrote: post #475
peoplefromibiza wrote: post #466

Earlier quoted context omitted.

> Defenders of C/C++ frequently note that memory safety bugs aren't a significant percentage of the total bug count Well, first of all, this is said but not proven. But it's easy to prove that memory safety bugs are not a significant percentage of the total number of bugs, even Google agrees. Vulnerabilities are not the same thing as bugs, a vulnerability like spectre or meltdown are not due to a bug in the software,…

> Vulnerabilities are not the same thing as bugs, a vulnerability like spectre or meltdown are not due to a bug in the software, have an ubiquitous immediate impact on 100% of the devices and are much harder to fix or mitigate, sometimes it's could even prove impossible. Using language-independent bug example in discussion about language-caused bug vectors isn't exactly honest. Rust would stop Heartbleed for example,…

> Rust would stop Heartbleed for example, and that was one of huge vulnerabilities

using a low budget project with few developers maintaining one of the most used libraries in the whole World as an example of non memory safe languages perils is not exactly honest.

Heartbleed could have been easily fixed if the companies profiting from using OpenSSL donated a few more eyes to look at the code.

Similarly to what happened to Log4j bug, which had an enormous impact, similar to the heartbleed one and affected a fully memory safe language.

Re: Memory Safe Languages in Android 13

#489

Post by arein3 »

pcwalton wrote: post #67
heather45879 wrote: post #24

Earlier quoted context omitted.

The problem with Rust is the language syntax is ugly. It has a ton of visual noise. I think folks who write languages should have a typographer on their team because something like this: use std::collections::HashMap Is a typographic nightmare. While I understand “form follows function”, it’s tough to be excited to program in something like this.

I was responsible for that decision, and I'm also a typographer (worked for years on vector rendering of fonts). :)

Looks ugly imo

Dot is way better

Re: Memory Safe Languages in Android 13

#490

Post by jstimpfle »

tome wrote: post #487
jstimpfle wrote: post #429

Earlier quoted context omitted.

I spent a considerable amount of time learning Haskell but I always felt like a slave to the language. Oh, you want to do this other simple thing? Try language extension XYZ, but you'll have to learn some more language theory first. Also sorry but the extension isn't compatible with the extensions you're already using, and you need to require a new dependency on the outside interface. There are some things that the l…

> sorry but the extension isn't compatible with the extensions you're already using In nearly 10 years of professional Haskell I've never come across a practical situation where extensions that were mutually incompatible. Can you name any extensions that are incompatible in a way that actually matters in practice?

No, I haven't followed the language in 6 years. I remember there was at least one instance but can't recall. Other extensions significantly change the semantics of language module interfaces in more obtrusive ways than I'd like - compared to say C where it's pretty easy to offer a simple interface.

Some of these things would make working in the language pretty painful. I remember trying some library to toy around with a basic 400 line OpenGL program. It always needed 8 seconds to rebuild at the time. I don't recall and probably didn't understand why, but I suppose it has to do with some extra type or template hackery in the library that would just overcomplicate everything, probably even at the outset.

What remains is the feeling of, I can't do this thing yet in the type system, so take that extension. Oh wow. Now I can't do this other thing that I also need, the only fix is another extension (if it's available yet). I couldn't get around of this feeling of constantly having to hack around the language.

In my experience you need to have a very good overview and understanding of all the available tricks and extensions to be able to navigate your way around the language and not paint yourself into a corner. Maybe I have the wrong personality, the wrong motivations, or am just not smart enough. Obviously I'm not you, and am not Edward Kmett (who would resort to lots of GHC specific hacks and drop down to C++ as well).

Post reply on HN