151–160 of 606 posts
> This matches the expectations published in our blog post 2 years ago about the age of memory safety vulnerabilities and why our focus should be on new code, not rewriting existing components. and > As we noted in the original announcement, our goal is not to convert existing C/C++ to Rust, but rather to shift development of new code to memory safe languages over time. For those working on C/C++ code bases, how does…
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…
> Passing "self" as the first argument was bullshit in Python, and it's bullshit in Rust too. Don't look at me like that - the compiler can inject it as the first parameter without requiring you to type it in. Nope, that would be a static function on your struct. By using self you let the compiler know that you want to use an instance function.
Earlier quoted context omitted.
There is some important context missing from your comment here. At least two points anyway: In Rust, overflow is not undefined behavior (neither signed nor unsigned). Today, arithmetic wraps in release mode (panics in debug mode), but it may panic in release mode in the future. The other point is that, since overflow wraps, that may indeed result in logic bugs. And in theory that logic bug could be used to lead to ex…
Beyond the above, IIRC Android ships with integer overflow enabled (but can't find where I read this).
Earlier quoted context omitted.
> and effectively making it even LESS maintainable now that it's in some new niche language with a vastly smaller dev pool How is any language supposed to grow if you're only allowed to use it once everybody does? Somebody has to be first (and google isn't, not by a long shot)
You should at least wait until there is more than one working/usable compiler for the language if you're going to start making systemic changes to your multi-billion-dollar code base responsible for the commerce of multiple billions of people on the planet. It's a weird move at this point for google to be making(edit: considering go is already supported on multiple compilers).
Earlier quoted context omitted.
But I think other memory safe languages don't have C++-like performance, right?
There's been many, for example Ada/SPARK, D, Nim, Java, Kotlin, Swift.
- 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.
- Java/Kotlin are not low-level: requires GC, and not often used for low-level systems programming. Great languages, but different niche.
Earlier quoted context omitted.
I love Rust, but I kind of believe in the conspiracy that comptime code features are less loved by the Rust language maintainers because they increase compile time even more.
That directly contradicts in-progress efforts to make `const` better. Things like `const trait`, `const Allocators`, etc are all in progress.
Earlier quoted context omitted.
I suppose reasonable people can disagree, but I don't think it's anywhere near as clear cut as you seem to be implying. You talk about data structures in std using unsafe, but you don't mention the heaps and piles of C code used to implement CPython's standard library. It's not like you need `unsafe` in Rust to build every data structure. I build oodles of data structures on top of the fundamental primitives provided…
You make a good point that much of pythong stdlib is implemented in C. But you could implement python's list in pure python, safely. You can't implement something like that in rust without unsafe.
> Safety measures make memory-unsafe languages slow > > Mobile devices have limited resources and we’re always trying to make better use of them to provide users with a better experience (for example, by optimizing performance, improving battery life, and reducing lag). Using memory unsafe code often means that we have to make tradeoffs between security and performance, such as adding additional sandboxing, sanitizer…
No it isn't. It's just evidence that it's a trade-off you might want to make in order to achieve some other goal, specifically security. But if "security" isn't remotely a concern for a given project (like almost anything graphics / gaming related), this is not at all evidence for changing anything. It could be that Rust's optimizer eliminates the bounds checking so regularly as to be a moot point, but this isn't say…
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.
Earlier quoted context omitted.
I didn’t say it’s not an improvement. I just wonder who will you blame once you have a hacker exploiting that exact CVE which you didn’t know about because they sold you rust as memory safe language, so you didn’t take the time to run any sanitizer or similar. Does Rust provide a way to check if you’re using unsafe code? What if I want to disable that? If I need to make a mission critical software I need to be aware…
Rust would have prevented about half of the CVEs in C code (I've seen a few different studies with somewhat different results, half is close enough for discussion). The other half is on you to write good code. Note that the half Rust would prevent tends to be less impactful, still a CVE, but the exploit is less impactful to end users.
We did a big improvement, but why can’t we disable “unsafe”?
That would leave absolutely no margin for such errors.
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…
The article was about languages being used to implement Android. Clearly, no, you can't have an entirely memory safe language that can be used to implement Android, for the reason you said. But there's a wide gap between "practical for doing useful work of any kind" and "practical for implementing Android".
Then, "entirely". What's "entirely"? Entirely until you get to library calls? Entirely until you get to OS calls? Entirely including the OS? If you include the OS then again, you are right for the reason you said. But if you exclude the OS, I'm not so certain.