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

81–90 of 430 posts

Re: Rust in Android: move fast and fix things

#81

Post by ModernMech »

manmal wrote: post #75
kridsdale1 wrote: post #55

Earlier quoted context omitted.

I’d say the same applies for Swift vs ObjC. Let’s end the C era.

Apple should have modernized ObjC instead of making Swift the lingua franca. Both speed of iteration and flexibility (on which web-stack-rivaling productivity features would have been possible) are gone forever. Swift Concurrency is a tire fire that not even their async-algorithms team can use completely correctly, and useful feature like typed throws are left half finished. The enormous effort the constant further b…

Swift has so many issues they would honestly be better off just moving to Rust rather than fix Swift. Seriously. The fact that it's so easy to get the compiler to spend exponential time resolving types that it very often just shits the bed and begs you to rewrite your code for it to stand a chance is shameful coming from, as you say, a $4T company. Points to deep problems with Swift.

Re: Rust in Android: move fast and fix things

#82

Post by kridsdale1 »

manmal wrote: post #75
kridsdale1 wrote: post #55

Earlier quoted context omitted.

I’d say the same applies for Swift vs ObjC. Let’s end the C era.

Apple should have modernized ObjC instead of making Swift the lingua franca. Both speed of iteration and flexibility (on which web-stack-rivaling productivity features would have been possible) are gone forever. Swift Concurrency is a tire fire that not even their async-algorithms team can use completely correctly, and useful feature like typed throws are left half finished. The enormous effort the constant further b…

I don’t disagree with anything you said.

Re: Rust in Android: move fast and fix things

#83

Post by vatsachak »

ModernMech wrote: post #80

The thing about Rust is you pay for everything up front, and the dividends come later. You pay first to learn it, which is not easy. Then you pay every time you have to compile your code, which can kill development momentum. When you are learning, often times this manifests as a moment where you have to completely rearchitect your approach because plowing forward is too costly. It's at this point a lot of people say…

Yeah, I use Rust at work and it's a boon.

It's so easy to bake in proofs/invariants into types, yet you still retain control of the memory model.

One of the main features of Rust is the community, there are so many great packages

Something that will replace/build on Rust in the future is a language based on Two Level Type theory, where you have zero cost abstractions with a language that can do full dependent type theory

Re: Rust in Android: move fast and fix things

#84

Post by GeekyBear »

gpm wrote: post #23
vbarrielle wrote: post #20

Earlier quoted context omitted.

But the approach here is "write new code in rust", not rewrite.

Eh, I don't think it's actually one or the other. Google has taken on rewriting some more problematic components in rust. See for example: Binder kernel driver: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... Media codecs: https://www.androidauthority.com/android-16-in-process-softw...

This is also happening at Microsoft:

> Rewriting SymCrypt in Rust to modernize Microsoft’s cryptographic library

https://www.microsoft.com/en-us/research/blog/rewriting-symc...

Re: Rust in Android: move fast and fix things

#85

Post by schuyler2d »

pizlonator wrote: post #9

This isn't control for confounding factors. For example: folks are more likely to rewrite stuff that is well-understood, and stuff that is well-understood is going to have shorter review times and lower rollback rate. That gnarly horrid mess that only a few greybeards grok and has massive test coverage, a long tail of requirements enforced by tests and experience, and a culture of extreme rigor? Longer reviews, more…

That is somewhat mitigated by grouping comparisons of S/M/L change sizes.

It would be interesting to group changes by line-deletions, say to indicate rewrites (and size of them)

Re: Rust in Android: move fast and fix things

#86

Post by ModernMech »

vatsachak wrote: post #83
ModernMech wrote: post #80

The thing about Rust is you pay for everything up front, and the dividends come later. You pay first to learn it, which is not easy. Then you pay every time you have to compile your code, which can kill development momentum. When you are learning, often times this manifests as a moment where you have to completely rearchitect your approach because plowing forward is too costly. It's at this point a lot of people say…

Yeah, I use Rust at work and it's a boon. It's so easy to bake in proofs/invariants into types, yet you still retain control of the memory model. One of the main features of Rust is the community, there are so many great packages Something that will replace/build on Rust in the future is a language based on Two Level Type theory, where you have zero cost abstractions with a language that can do full dependent type th…

I'm glad you said that because that's exactly where my research is ^_^

Re: Rust in Android: move fast and fix things

#87

Post by vatsachak »

ModernMech wrote: post #86
vatsachak wrote: post #83

Earlier quoted context omitted.

Yeah, I use Rust at work and it's a boon. It's so easy to bake in proofs/invariants into types, yet you still retain control of the memory model. One of the main features of Rust is the community, there are so many great packages Something that will replace/build on Rust in the future is a language based on Two Level Type theory, where you have zero cost abstractions with a language that can do full dependent type th…

I'm glad you said that because that's exactly where my research is ^_^

https://andraskovacs.github.io/pdfs/2ltt_icfp24.pdf

I think that something like this is the endgame practical programming language

Re: Rust in Android: move fast and fix things

#88

Post by ActorNightly »

masklinn wrote: post #3

Most of these is confirmation of easily observable reality, but the 4x difference in rollback rates, jesus christ.

The issue with most codebases is nobody thinks about starting out with acceptance testing system.

The way it should work is that before even writing code, you design a modular acceptance system that runs full suite of tests or a subset based on what you are working on.

This is essentially your contract for software. And on a modular level, it means that it scopes down the contracts to the individual sub systems. And things like memory and cpu runtime constraints are a part of this.

If you have this, you basically replace what the Rust compiler is doing for you with tests. Memory leaks are caught. However, as a benefit, you also can verify changes in the dev cycle with things like performance degradation, all in the same system.

Re: Rust in Android: move fast and fix things

#89

Post by guywithahat »

mk89 wrote: post #30
beeflet wrote: post #13

Earlier quoted context omitted.

rust has other advantages. I think cargo is better than cmake. I think the syntax is better, I think the way dependencies and modules are handled is better. It can be annoying to write "safe" code, but once it meets a certain standard I can be confident in multithreaded applications I write. I would like to use rust to write android apps. I don't really like the whole android studio java thing.

I cannot like Rust syntax, sorry. For me the ideal syntax is C/Go, just to be clear what I like. But I agree that the tooling that cargo introduced is a breath of fresh air in a world dominated by huge makefiles, libraries copied in the repository (I know, there is Conan, vcpkg etc)...

Go is such a great language. If your code base doesn't mind garbage collection and doesn't depend on some external library, everyone should really look at go. Great multithreading, memory safe, great error handling, and a familiar syntax for people coming from C++/Java/etc.

Re: Rust in Android: move fast and fix things

#90

Post by gf000 »

dontlaugh wrote: post #52
mk89 wrote: post #30

Earlier quoted context omitted.

I cannot like Rust syntax, sorry. For me the ideal syntax is C/Go, just to be clear what I like. But I agree that the tooling that cargo introduced is a breath of fresh air in a world dominated by huge makefiles, libraries copied in the repository (I know, there is Conan, vcpkg etc)...

All three have very similar syntax when compared even to something like Python or Ruby, let alone ML or Haskell. Seems like a spurious complaint.

I mean, Rust is quite a different category than C or Go, if this is the 3 languages you reference.

Rust has plenty of syntax coming straight from ML (okay, not straight, probably through OCaML)

Pattern matching, destructuring, expressions everywhere, etc are stuff that C/Go never even heard about.

Post reply on HN