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

321–330 of 430 posts

Re: Rust in Android: move fast and fix things

#321

Post by pjmlp »

danudey wrote: post #91
petcat wrote: post #7

At this point I feel like it's no longer an uphill climb to get Rust into foundational, mission-critical code adoption. The benefits are so obvious. Maybe it's just a lingering religious war? In any case, I'm glad we're seeing more and more evidence and case-studies of why "rewrite it in Rust" isn't just a meme.

Go look at the comments on any Phoronix article involving Rust in any way and you'll see that it's 80% rust haters making all the same arguments every Rust hater makes. You can implement the same safety features in C++ and assembly if you know what you're doing! You can still write bugs in Rust! I know someone who tried to learn rust and he accidentally deleted his home directory so everyone may as well stick to C! I…

The irony is that those haters have been doing the same speech since Ada, Modula-2 and Object Pascal early days.

Multics got an higher security score than UNIX, thanks to PL/I.

During the USENET flamewar days, they used to call programming with straightjacket languages.

Also note how proudly they keep digging out Brian Kerninghan complains against Pascal, that disregard the dialects have taken out those issues, and that while Pascal was designed for teaching, Modula-2 was already available, taking care of those pain points, designed for systems programming.

Re: Rust in Android: move fast and fix things

#322

Post by rstuart4133 »

ikety wrote: post #124
josephg wrote: post #114

Earlier quoted context omitted.

One big source of bugs in TS is structural sharing. Like, imagine you have some complex object that needs to be accessed from multiple places. The obvious, high performance way to share that object is to just pass around references wherever you need them. But this is dangerous. It’s easy to later forget that the object is shared, and mutate it in one place without considering the implications for other parts of your…

Appreciate it, that makes a lot of sense. I feel like I've been trained to favor immutability so much in every language that I sometimes forget about these things.

Yes, immutability is great for safety. But the copies you have to make to keep everything immutable extracts a price in copies and garbage collection.

Rust is advertised as having fearless concurrency. That's true, but not that important as concurrency is not that common. What's important to everyday programming is Rust provides fearless mutability. The fearless concurrency you get with that is just a bonus.

Fearless mutability provides Rust the same safety as a functional language in a without the speed or space cost. IMO, it's Rust's true secret sauce.

Re: Rust in Android: move fast and fix things

#323

Post by jkrejcha »

AlotOfReading wrote: post #264
bgwalter wrote: post #228

Earlier quoted context omitted.

> You're not fully understanding the issue with memory safety. When you write C or C++, you're promising that you won't violate memory safety at all. The post you reply to does not indicate a misunderstanding of memory safety at all. .

The comment I'm responding to implicitly assumes memory safety violations are like other bugs where that it's meaningful to speak of programs being more or less correct depending on the number of issues. What I'm emphasizing is that code with safety violations, strictly speaking, isn't C/C++ at all. It's more like parsing paint splatters as perl [0]. You might get something resembling what you want if you're lucky, b…

> What I'm emphasizing is that code with safety violations, strictly speaking, isn't C/C++ at all.

This isn't really correct and many programming language standards (including that of C and C++) don't support this view. Many language standards define a notion of conformance. Strictly conforming programs aren't allowed to invoke behaviors that which are undefined[1].

Conforming programs do not have this requirement and basically any non-trivial C and C++ programs are written to this rather than the notion of "strictly conforming".

Most non-trivial programs are not strictly conforming (including some C compilers themselves), generally because restricting the set of targets to something smaller than "any possible C implementation" is useful.

It is perfectly legal (and very desirable in cases where the standards fall short of usefulness) for a C compiler to define undefined behavior. What you compiled is still a C program, just one that isn't portable across the entire potential set of implementations.

[1]: Or unspecified or implementation-defined, for that matter, but this part tends to get left out of discussions.

Re: Rust in Android: move fast and fix things

#324

Post by AndrewDucker »

androidcode wrote: post #306
pjmlp wrote: post #302

Earlier quoted context omitted.

Thing is, from security point of view, if it is part of the ISO C++ PDF one can buy in Geneva, compiles with a C++ compiler in C++ mode, it is C++.

BTW; Do you know if it is possible to track new comments to Hacker News threads?

I used https://hnreplies.com/

Re: Rust in Android: move fast and fix things

#325

Post by androidcode »

pjmlp wrote: post #312
androidcode wrote: post #304

Earlier quoted context omitted.

That argument can be applied to unsafe Rust as well. There are code reviews, coding standards and other checks for a reason. Though, I suppose something like C++ profiles, just for modernization, might make it much easier to enforce and track that modern C++ is used.

The difference is that with Rust one can prevent unsafe in the compiler build settings. Or any language with unsafe code blocks, which people keep forgetting also exist, while complaining about Rust, as if there isn't any other memory safe language. With C++ you need external tooling to disable C like code, that a large part of the community refuses to adopt.

Yes, so something like a modernization profile for C++ would make it easier to enforce, and would not require external tools. But it ultimately does not change that C++ is not C, and that the blog is deeply misleading. Nor does it change that Google Android source code appears to have significant issues.

> as if there isn't any other memory safe language.

But Rust is obviously not a memory safe programming language. Unsafe's prevalence and difficulty, no_std, and arguably also the bugs and holes in the type system of Rust that have not been fixed for many years by now, make this clear.

Re: Rust in Android: move fast and fix things

#326

Post by tcfhgj »

woodruffw wrote: post #205
linkage wrote: post #156

Earlier quoted context omitted.

C has plenty of high quality linters like ClangTidy that can teach junior and intermediate developers what not to do. Granted, even with linters, C projects typically have more vulnerabilities than Rust projects, but C has fewer concepts a developer must know to produce working code. For example, to implement a self-balancing binary tree in Rust, you need to first understand reference counting, `RefCell`, and ownersh…

How often do you find yourself implementing self-balancing trees in either C or Rust?

once in university

Re: Rust in Android: move fast and fix things

#327

Post by aw1621107 »

androidcode wrote: post #325
pjmlp wrote: post #312

Earlier quoted context omitted.

The difference is that with Rust one can prevent unsafe in the compiler build settings. Or any language with unsafe code blocks, which people keep forgetting also exist, while complaining about Rust, as if there isn't any other memory safe language. With C++ you need external tooling to disable C like code, that a large part of the community refuses to adopt.

Yes, so something like a modernization profile for C++ would make it easier to enforce, and would not require external tools. But it ultimately does not change that C++ is not C, and that the blog is deeply misleading. Nor does it change that Google Android source code appears to have significant issues. > as if there isn't any other memory safe language. But Rust is obviously not a memory safe programming language.…

> But Rust is obviously not a memory safe programming language. Unsafe's prevalence and difficulty, no_std, and arguably also the bugs and holes in the type system of Rust that have not been fixed for many years by now, make this clear.

Everything else aside, why is no_std included here?

Re: Rust in Android: move fast and fix things

#328

Post by pjmlp »

androidcode wrote: post #325
pjmlp wrote: post #312

Earlier quoted context omitted.

The difference is that with Rust one can prevent unsafe in the compiler build settings. Or any language with unsafe code blocks, which people keep forgetting also exist, while complaining about Rust, as if there isn't any other memory safe language. With C++ you need external tooling to disable C like code, that a large part of the community refuses to adopt.

Yes, so something like a modernization profile for C++ would make it easier to enforce, and would not require external tools. But it ultimately does not change that C++ is not C, and that the blog is deeply misleading. Nor does it change that Google Android source code appears to have significant issues. > as if there isn't any other memory safe language. But Rust is obviously not a memory safe programming language.…

With that line of argumentation there are no safe languages, we should all go back to Assembly.

Re: Rust in Android: move fast and fix things

#329

Post by pjmlp »

flohofwoe wrote: post #305
pjmlp wrote: post #297

Earlier quoted context omitted.

CMake is the defacto tool adopted by the industry, regardless how many love to hate it. You can use BSD Make instead of Gradle, isn't UNIX great?

> You can use BSD Make instead of Gradle, isn't UNIX great? So the NDK officially supports creating an APK just with a Makefile? That would be news to me (and great news at that). It is possible to cobble together a build process that directly calls various Android SDK command line tools to build an APK directly from a C/C++ build tool without involving Gradle, but as far as I know, most of those invoked cmdline tool…

No, I wasn't talking about APKs.

The NDK supports building shared objects with Makefiles, via ndk-build.

The original plan to deprecate ndk-build was reversed, due to the complaints.

Pretty much official,

https://developer.android.com/ndk/guides/build

I also stand corrected, it is actually GNU Make, not BSD Make.

Re: Rust in Android: move fast and fix things

#330

Post by pjmlp »

flohofwoe wrote: post #291
quotemstr wrote: post #226

Earlier quoted context omitted.

Huh? "Barely"? What are you talking about? The NDK supports compiling C++ just fine. There are CMake files, among other things, ready to use --- as well as Soong native configurations. CMake is under active development. Other toolkits are within easy reach: for example, Meson works fine. Also Bazel. Hell, even autotools can be made to work.

Sure, building C/C++ code into an .so file kinda works but that's about it, try building the APK entirely with cmake, that's simply not supported, you'll have to integrate with Gradle. The result is a complexity clusterf*ck that's a nightmare to maintain. The NDK team should take a long hard look at Emscripten to get some inspiration how native code development is integrated into a 'native-hostile' runtime platform.

Interesting that you give Emacripten as example, given how badly documented its whole tooling is, and is a pain to prevent it from downloading the Java tooling and everything else that is already downloaded, unless using the Github installation from source.
Post reply on HN