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

Rust in Android: move fast and fix things

security.googleblog.com

Post reply on HN
Print view View original

401–410 of 430 posts

Re: Rust in Android: move fast and fix things

#401

Post by tialaramex »

AlotOfReading wrote: post #394
tialaramex wrote: post #390

Earlier quoted context omitted.

> There's a line in the standards that basically says a conforming program is anything acceptable by a conforming implementation. Perhaps it "basically" says that, but it certainly doesn't appear to literally say any such thing, so you're going to need to specify where you believe you saw this so that I can have any idea what it actually says.

C standard N3096, Section 4: A conforming program is one that is acceptable to a conforming implementation. That definition goes all the way back to C89. The C++ standard drops it for the term "well-formed program", but adds enough clarifications in 1.4 to mean essentially the same thing.

Ah, no. Most C++ programs that compile are not well-formed programs. This functions as an escape hatch for Rice's Theorem. You see, C++ even more so than C has semantic requirements - but Rice says all non-trivial semantic requiremnts are Undecidable. So, if you want what C++ says it wants it appears that compilers would be entirely impossible and that's awkward. To "fix" that C++ says it's fine if the compiler will compile your program even though it is not well-formed, the program doesn't have any meaning of course, only well-formed programs have meaning, but it did compile, so as a programmer you're happy...

C++ has a recurring phrase in its standard document "Ill-formed No Diagnostic Required" or IFNDR which carries this intent. The compiler can't tell you made a mistake, but you didn't actually write a valid C++ program so -shrug-

Because there's no way to tell for sure without exhaustive human examination we don't know for sure how many C++ programs aren't actually well-formed but experts who've thought about it tend to think the answer for large C++ software projects is all or most of them.

Re: Rust in Android: move fast and fix things

#402

Post by baq »

aeve890 wrote: post #333
throwaway2037 wrote: post #260

Earlier quoted context omitted.

Yeah, I am blown away. Assuming that these stats are true/verifiable, this spells real doom for C++. What is the point of C++ in 2025 except to maintain a large, existing source code base? Else, you should be doing everything that you used to do in C++ in Rust.

> What is the point of C++ in 2025 except to maintain a large, existing source code base? Half of useful things to do are impossible or plain cumbersome to write in rust given the semantics and constraints of the borrow checker. Try to write self referential structures in rust and you'll have a more nuanced opinion.

That’s entirely the point, though. Rust compiler is of the opinion that recursive data types are hard and I don’t think it can be reasonably argued that this opinion is incorrect.

Feel free to use unsafe {} when you need it, though.

Re: Rust in Android: move fast and fix things

#403

Post by baq »

samdoesnothing wrote: post #245
shakow wrote: post #218

Earlier quoted context omitted.

You're sure of a lot of things.

Because I don't blindly accept bad science? It's more like others are sure that this data confirms their biases.

Why do you blindly accept the status quo, though? You should be skeptical of both sides.

Re: Rust in Android: move fast and fix things

#404

Post by tialaramex »

pizlonator wrote: post #31
gpm wrote: post #15

Earlier quoted context omitted.

The first chart does in fact a compelling reason to believe the effect is not that at all. If the "easy" code was predominantly being rewritten you would expect to % new memory unsafe code and % memory safety vulnerabilities to scale at different rates as the difficult to work on areas remained in C and kept causing new memory vulnerabilities. Personal experience also provides a compelling reason, my experience is ab…

I would expect memory safety vulns to be dropping in most C/C++ projects due to better practices

This is basically the C++ treadmill for decades and I think people are starting to realise they were duped.

Bjarne's C++ promised that if you use this instead of C you won't have these problems. The problems persisted of course. Then it was well you need to use standard C++ 98 not that crap pre-standard C++ you've been doing, once you adopt C++ 98 the problems will subside. Then it's you need "modern" C++ 11, of course you've got problems, that's because you used C++ 98, use this "modern" C++ instead.

By around 2020 they started to say the "modern" C++ 11 wasn't up to it, you need to write "contemporary" C++ 20 or better.

What was it George W Bush told us? "Fool me once, shame on...shame on you. Fool me...you can't get fooled again".

Re: Rust in Android: move fast and fix things

#405

Post by baq »

MBCook wrote: post #246
o11c wrote: post #148

Earlier quoted context omitted.

Typescript doesn't even support notions like "unsigned integer". It is not a serious attempt at type-safety; its main claim to fame is "better than raw Javascript" which is not saying much.

If you need to run in a JS environment it’s a hell of a lot. It’s a FANTASTIC improvement. I wouldn’t use it server side or for a client application that doesn’t run in a web browser. That’s not its place, for me. But I will 100% reach for it every time if I need to run in a JavaScript environment.

TS actually works very well as an HTTP server, I’d say better than typed Python. Plain JS… a minute of silence, please.

Re: Rust in Android: move fast and fix things

#406

Post by SkiFire13 »

lmm wrote: post #275
SkiFire13 wrote: post #274

Earlier quoted context omitted.

Rust also has the bigger numbers on microbenchmarks, that's why people care about it.

Yes, exactly. It's tragic that the only way programming culture ever improves is when a language comes out that's better for writing software in and happens to also have bigger numbers on microbenchmarks.

I think you're generalizing a bit too much. Rust targetted the audience that wanted big numbers on microbenchmarks, but not all languages do. Typescript for example has no performance advantage against Javascript, but it became very popular due to the better dev experience. Kotlin is another example where that mattered a lot.

Re: Rust in Android: move fast and fix things

#407

Post by aw1621107 »

TuxSH wrote: post #331
pdpi wrote: post #227

Earlier quoted context omitted.

> Just making not literally every piece of data universally mutable? Not possible in C. Trivial in C++ and Rust, and it makes your programs SO much easier to reason about. And Rust is significantly better at this than C++ for the simple reason that mut is a modifier. I’ve lost track of how many times I’ve listened to Kate Gregory extol the virtues of const-ing all the things, but people still don’t systematically add…

> I’ve lost track of how many times I’ve listened to Kate Gregory extol the virtues of const-ing all the things, but people still don’t systematically add it Adding const to _function-local_ variables only really matters when you "leak" a pointer or ref, whether mutable or const, to a function or variable the compiler can't optimize away: std::size_t sz = 4096; const std::size_t &szRef = sz; some_opaque_func(szRef);…

Pretty sure the std::abort() can't be optimized away if sz is mutable since it's legal for some_opaque_func() to cast away szRef's const and modify sz via that. sz itself needs to be const for the if statement to be removable as dead code.

https://cpp.godbolt.org/z/Pa3bMh9Ee shows that both GCC and Clang keep the abort when sz is not const. Add const and the abort goes away.

Re: Rust in Android: move fast and fix things

#408

Post by kccqzy »

LexiMax wrote: post #399
kccqzy wrote: post #385

Earlier quoted context omitted.

> what I hear is a group of scared developers who have been able to coast on their knowledge base for years or even decades That’s certainly not the case for C++. The C++ language has evolved quickly, with a release every three years or so. One could coast, but they would be writing outdated C++ that no newcomer likes. That is, the entire organization needs to also coast for this behavior to be viable. Instead I see…

> The C++ language has evolved quickly, with a release every three years or so. There was a revival of C++ starting with C++11 and ending around the era of C++17. It was, frankly, great. However, a few things happened around and since C++20 that has caused the language to backslide. First, it seems like corporate support for C++ has dropped significantly. Apple, having successfully replaced GCC with Clang for their o…

Agree with a lot of what you said. Definitely to a lot of corporations C++17 was the peak of the language. Apple prioritized Swift afterwards and Google started doing Carbon and begrudgingly accepted Rust.

First time hearing about the embed issue and god that person’s experience is awful: https://thephd.dev/finally-embed-in-c23 and it feels like a job for only the best project managers.

Re: Rust in Android: move fast and fix things

#409

Post by MBCook »

baq wrote: post #405
MBCook wrote: post #246

Earlier quoted context omitted.

If you need to run in a JS environment it’s a hell of a lot. It’s a FANTASTIC improvement. I wouldn’t use it server side or for a client application that doesn’t run in a web browser. That’s not its place, for me. But I will 100% reach for it every time if I need to run in a JavaScript environment.

TS actually works very well as an HTTP server, I’d say better than typed Python. Plain JS… a minute of silence, please.

I’ve never been a JS on the server person, I was used to other languages when that was developed.

Well I think I would prefer python, but simply because it’s “more traditional“ and I realize that’s specious reasoning, I prefer to use strongly typed languages whenever possible.

I would generally reach for Java since it’s the language I’m most proficient in due to my career. There’s also Go, which I played with long ago, or maybe I’d try Rust.

This is only for anything important. If I was just toying with something locally I’d probably do whatever was fastest. In that case Python or JS might be my choice for a very tiny script.

Re: Rust in Android: move fast and fix things

#410

Post by hyc_symas »

josephg wrote: post #318
bgwalter wrote: post #224

Earlier quoted context omitted.

The downvoting patterns of anything that is mildly critical of Rust (see above) very much indicates a feud war. Rust has a dogmatic, aggressive and self-righteous community that uses any available tactic to push their language through. The Rust literature is poorly written compared to C and Ada and the argumentation style on forums is sloppy, aggressive, and often unintelligible. Which is a pity, because the language…

> Rust has a dogmatic, aggressive and self-righteous community that uses any available tactic to push their language through. I'm confused, because that's not been my experience of the rust community at all. I've been very critical of certain aspects of rust over the last few years, and I've (for the most part) gotten fair, reasonable feedback in response. > The Rust literature is poorly written compared to C and Ada…

> So much C library code is documented in ad-hoc ways - often through doxygen, which is a disaster. Eg here's the documentation for LMDB. LMDB is one of the most thoroughly documented C APIs I've seen, but I find this almost totally unusable. I often find myself reading the source instead. There's not even any links to the source from here:

> http://www.lmdb.tech/doc/group__mdb.html

How is doxygen a disaster?

Why do we need links to the source code? Doxygen is already embedded in the source, you should already be reading the source code on your local machine. It makes no sense to go searching across the web for information that's already stored on your local machine. Especially since you have no idea if the version you find on the web matches the version you're using locally.

Post reply on HN