Live data from Hacker News

Rust in Android: move fast and fix things

security.googleblog.com

421–430 of 430 posts

Re: Rust in Android: move fast and fix things

#421

Earlier quoted context omitted.

Rust has things that have dynamic runtime check overhead that are often used. Reference counters, array size, e.t.c You have to have runtime checks because of Rice's theorem. The only way around this would be to have a absolutely strict type system that defines the finite sets of data that memory can hold. But for compile time checks, its not hard. For example, the I would do it C is that every pointer gets an option…

So your claim is that sufficiently careful C is just as safe as rust? Seems like a pretty wild claim to make in the comment thread of this article. Google has some of the most careful engineers in the business. They use valgrind & ubsan & friends religiously. And yet this is their conclusion: > Our historical data for C and C++ shows a density of closer to 1,000 memory safety vulnerabilities per MLOC. Our Rust code i…

I agree that C is a basket case when it comes to safety and security.

The CPU and the hardware don’t care how confident C coders are in their ability.

C developers tend to forget the reason why Windows and UNIX like systems are now quite robust is that there has been over 50 years of turd polishing. Unfortunately for rust it is not immune to bugs other than memory safety issues. I think that it is a good idea to write new code in rust. Less so for battle hardened old code.

C++ is somewhere between C and rust. With modern ‘good practices’ (no raw pointers, no for loops) it can be an order of magnitude or two safer than C.

Re: Rust in Android: move fast and fix things

#422
post #414
post #412

Earlier quoted context omitted.

> Every time a language in the same space comes they get asked if they are memory safe? So what? It might be shocking for you, but every new messenger gets asked if it supports e2ee these days. Why shouldn't people want to know about the availability of a massive advancement in the space of system programming languages?

And yet at the same time naming Ada is forbidden?

It is not

Re: Rust in Android: move fast and fix things

#423

Earlier quoted context omitted.

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

Hah! Do you have a running search giving you alerts when lmdb is mentioned or something?

> How is doxygen a disaster?

I've just never read any good, user friendly documentation ever produced by doxygen. Even when I used it myself. It always comes out looking like a pig's breakfast.

Like, take the lmdb docs. And I'm sorry for picking on it. But its a good example, because you've clearly put effort into using doxygen to document lmdb. I think the lmdb docs are about the best that doxygen generated documentation gets.

Looking at this page: http://www.lmdb.tech/doc/group__mdb.html

There's a bunch of concepts here:

- Environment (mdb_env)

- Database and database (dbi)

- Transaction

- Cursor

- Record

- Key

But none of those concepts are defined or explained. They're simply referenced without explanation in a big jumble of function names and descriptions, leaving me to figure out how they're supposed to work together. Maybe if those data types were defined up the top of the page? No. Doxygen tries to put some data structures at the top of the page - but for some reason the only documented types are MDB_val, MDB_stat and MDB_envinfo. All terrible places to start reading if you want to understand how to use lmdb.

Good documentation would lead with some front matter like:

- What does the library do

- How does the library sees the world. Here, explain the above concepts and how they relate. (Eg an environment represents a set of files on disk. Each environment contains a numbered set of databases, database contains a set of records. You can read and write within a txn. You can use a cursor to iterate. ... Etc)

- Code examples of all of the above. Ideally a hello world, and more complex / specific examples showing each feature.

Doxygen does not help with any of that. From this documentation I don't know how to use lmdb to make a correct program. I can kinda guess how to use various features, but not what the features actually are or how to use them correctly.

For example, I can obliquely tell from reading the function descriptions that an environment can be opened multiple times at the same time. But I have no idea why I'd want to do that, or how, or what performance implications there are, or if there are any gotchas I need to be aware of if I do that. I see there's a bunch of functions for mdb_env_copy. Does that copy in memory or on disk? Does it do it atomically, like at a snapshot? Is it synchronous? Does it fsync? fdatasync? What errors can happen? The documentation isn't helpful.

So I'm not just banging on about rust, here's equivalent - but much better - reference documentation for prisma:

https://www.prisma.io/docs/orm/reference/prisma-client-refer...

Prisma also has a separate guide, explaining the concepts involved:

https://www.prisma.io/docs/orm/prisma-client/queries/select-...

Or for another positive example, here's bun's documentation on using sqlite from javascript:

https://bun.com/docs/runtime/sqlite

They explain the concepts and present examples for how to use all the features. When I read those docs, I come away knowing how to use the library to solve my problems. I don't have that experience reading the lmdb documentation.

Maybe its possible to produce good documentation using doxygen. But I've never seen it done. Not even once.

-----

Side points:

> you should already be reading the source code on your local machine.

I'd rather not read the source code of all my dependencies to understand how to use them. Reading the source code of your dependencies should be a last resort. Eg, I don't go reading my compiler's source code if I want to understand my programming language. I don't want to read the source code of my web browser, or postgres, or linux, or any of this stuff.

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

I hear you, but honestly I don't really care where documentation lives. Just so long as I can find it and read it. But with rust in particular, if you want local documentation you can run cargo doc to generate & open the documentation of your project and all your dependencies, which is nice.

And re: versions, rust docs hosted online also have a little 'version' field up the top showing which version of the library you're looking at the documentation of. Eg if you open https://docs.rs/rand/ I see "rand-0.9.2". If you change versions, the URL changes. It'd be nice if doxygen had that too.

Re: Rust in Android: move fast and fix things

#425
post #331

Earlier quoted context omitted.

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

Yes, that is what I said - sorry if this wasn't clear

Re: Rust in Android: move fast and fix things

#426
post #425

Earlier quoted context omitted.

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.

Yes, that is what I said - sorry if this wasn't clear

Looking back I think I might have misread your comment and thought you meant that the const on the reference was what mattered. Sorry about that!

Re: Rust in Android: move fast and fix things

#430

[flagged]

I find it very ironic that you are calling out sockpuppets when your name is literally "RustSupremacist" and your submission history is less than stellar.

Nothing says "intellectual honesty" like necrobumping a 9 day old post because of moderation concerns.
Post reply on HN