Memory Safe Languages in Android 13 • Hacker News Board

Re: Memory Safe Languages in Android 13

#211

Post by kllrnohj » Thu, Dec 01, 2022, 9:44 PM UTC

Gankra wrote: post #174

kllrnohj wrote: post #140

Earlier quoted context omitted.

Can you point to any such bounds check in C that an optimizer cannot eliminate but it can eliminate the equivalent one in Rust? I'm sure it's possible to construct such a thing, but I cannot imagine it ever being common enough to show up on any sort of head to head comparison.

there's almost no bounds checking in rust code before the optimizer even looks at it because we use iterators and not goofy manually indexed for loops that are begging you to make a typo that crashes your code :)

Yeah but idiomatic modern C++ is also using iterators and even before that there's no bounds checking to eliminate in the first place since operator[] is unchecked so the optimizer can't be struggling to eliminate it since it's not there.

The question isn't "does Rust have bad bounds checking optimizations" but rather "what is this mythical heavily-bounds-checked C code that the compiler can't optimize away?"

Re: Memory Safe Languages in Android 13

#212

Post by yosefk » Thu, Dec 01, 2022, 9:44 PM UTC

Taywee wrote: post #209

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…

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

Dead - no, dying COBOL-style - quite possibly.

Re: Memory Safe Languages in Android 13

#213

Post by lynndotpy » Thu, Dec 01, 2022, 9:45 PM UTC

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…

Security is absolutely a concern in these areas (except maybe offline graphics).

In my experiences with university HPC clusters, security is very important because you have a lot of young students with no Unix experience accessing the resources. We've had real compromises of individual research machines because of this.

This happens all the time at research universities, but it's not always public. In one public example from my uni, hackers from China compromised a research machine, which was used to attack IT infrastructure, which lead to PII including SSNs being compromised.

Re: Memory Safe Languages in Android 13

#214

Post by nneonneo » Thu, Dec 01, 2022, 9:45 PM UTC

amalcon wrote: post #202

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

Rust has some amazing libraries, too. I recently found out about `rayon`, and I applied it to a compute-heavy program I was writing. It was literally a one-line change (as promised!) to go from sequential to parallel, and I didn't need to worry at all that there might be some data race somewhere (unlike, say, #pragma omp parallel).

Re: Memory Safe Languages in Android 13

#215

Post by kllrnohj » Thu, Dec 01, 2022, 9:46 PM UTC

tialaramex wrote: post #194

kllrnohj wrote: post #140

Earlier quoted context omitted.

Can you point to any such bounds check in C that an optimizer cannot eliminate but it can eliminate the equivalent one in Rust? I'm sure it's possible to construct such a thing, but I cannot imagine it ever being common enough to show up on any sort of head to head comparison.

I would guess all the aliasing stuff will get you. In C it's very difficult for the compiler to know whether two pointers are aliased, if we change X maybe Y changes too (because actually X and Y were the same). In Rust if we can write to it then it isn't aliased, and if we can't write to it then nobody can change it, thus changing X definitely can't change Y and the emitted machine code is sometimes simpler as a res…

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?

Re: Memory Safe Languages in Android 13

#216

Post by kllrnohj » Thu, Dec 01, 2022, 9:47 PM UTC

stouset wrote: post #176

kllrnohj wrote: post #140

Earlier quoted context omitted.

Can you point to any such bounds check in C that an optimizer cannot eliminate but it can eliminate the equivalent one in Rust? I'm sure it's possible to construct such a thing, but I cannot imagine it ever being common enough to show up on any sort of head to head comparison.

Trivially, anything using the Iterator trait. I don't know that I've ever actually manually indexed an array over years of using Rust.

I don't think your answer is relevant to the question:

> Can you point to any such bounds check in C

Re: Memory Safe Languages in Android 13

#217

Post by estebank » Thu, Dec 01, 2022, 9:47 PM UTC

optymizer wrote: post #76

As an Android user ever since the T-Mobile G1, I'm a fan of not having my phone remotely exploited via WebView, or with an SMS, or the other million ways there are to interact with a device, so I absolutely celebrate this progress. As an Android developer though, I have to be the one bitter old man yelling at cloud. I was spoiled by Java and Kotlin to the point where I cannot look at Rust and think it's a nice modern…

https://github.com/rust-lang/rust/pulls?q=is%3Apr+author%3Ae...

The aesthetics of syntax is a personal matter, but when the critique of a language focuses exclusively on its syntax, it tells me that the critique is skin deep. Semantics are way more important to what code "feels" like to write.

Why not @derive? @ was a reserved token for something else before 1.0 and today is still used in patterns. Now it's too late to change.

The ' lifetime syntax was borrowed from another language. Some way of differentiating types and lifetimes is necessary, ' is not any worse than most others we could have chosen.

We try to make things that are common and safe terse, and things that are uncommon and potentially problematic more verbose. ? is common and safe, .unwrap() is less common and potentially problematic. Mutable bindings are not exactly unidiomatic, but mildly discouraged.

println! is a macro because it 1) is a compiler intrinsic to do compile time magic like the recent addition of capturing bindings directly in the formatting string and 2) it takes a variable number of arguments. Differentiating between macros and function calls is important if you want to get a sense for what the code you're reading can do. You can choose another way of differentiating them, but whatever you choose will be subjective and has to mesh well with the rest of the language.

Explicit self makes it easy syntax to differentiate between associated functions (part of the type) and methods (part of the instance), while also making very clear when you're accessing the current instance's data. And because Rust cares about mutability and ownership, you still need to communicate the differences between self, &self and &mut self. It also provides syntactic space for arbitrary self types: fn foo(self: Pin)

Re: Memory Safe Languages in Android 13

#218

Post by berkut » Thu, Dec 01, 2022, 9:47 PM UTC

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…

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 that much with something like Rust, if the same programmer time constraints are going to exist in writing them: i.e. I think it's very likely people will just unwrap() their way to getting things to compile instead of correctly handling errors, so it will be the same situation from the artists' perspective: technically it may be a panic rather than a segfault, but from the artists' perspective, it will likely be identical and take the DCC down.

Re: Memory Safe Languages in Android 13

#219

Post by Taywee » Thu, Dec 01, 2022, 9:49 PM UTC

nneonneo wrote: post #164

TheNorthman wrote: post #143

Earlier quoted context omitted.

> I can tell you that bad programmers can write bad code in Rust. Of course. The question rust users seem to put forth is that bad programmers write _better_ (not good) rust code than C code. That bad programmers write bad code is to expected. That is, after all, a likely explanation for why they're bad.

I would argue that the type system does make it somewhat more difficult for bad programmers to do egregiously bad things in the language. A carefully written library can be quite difficult to misuse (at least, without panics or using unsafe code in the user code, both of which are easy to catch in code review). Rust has no null/nil pointers. Instead, it has nullable types (Option ), which are harder to misuse. If you…

`x->foo()` in C++ often isn't just "crashy", but undefined behavior. See https://en.cppreference.com/w/cpp/utility/optional/operator*

> The behavior is undefined if *this does not contain a value.

I'll take crashes over "probably does the wrong thing" any day.

Re: Memory Safe Languages in Android 13

#220

Post by burntsushi » Thu, Dec 01, 2022, 9:50 PM UTC

bluGill wrote: post #146

burntsushi wrote: post #25

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

> Is there any practical programming language that is memory safe in its "entirety"? This isn't possible. Eventually you are sitting at a block of memory and need to write the allocator. Maybe (like python) your allocator is written in C and you hide it, but there is always something that isn't memory safe sitting under your language. You could write a language for an actual Turing machine which since it has infinite…

Yes, exactly. That's why I asked the question: to drive out the point that the ontology the GP was using was probably not terribly useful.

Although I did use the weasel word "practical" to narrow the field. If you don't limit yourself to general purpose languages, then I'm sure you can find one that is "entirely" safe.