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

141–150 of 430 posts

Re: Rust in Android: move fast and fix things

#141

Post by Tuna-Fish »

teaearlgraycold wrote: post #125
petcat wrote: post #96

Earlier quoted context omitted.

Rust is truly a marvel of engineering. A breakthrough. Such a thing is so very rare in computer science.

I don't know much about how it got started. I'm curious how much of Rust's capabilities depend upon recent CS breakthroughs. Could we have made Rust in 1990? The compiler is also relatively slow. Would Rust have been worth working with on 30+ year old hardware?

> Could we have made Rust in 1990?

No. Only massively oversimplifying, Rust could be described as a bunch of ideas pioneered among functional languages coming back to C++, the same way Java was a bunch of ideas from Lisp coming back to C. There is very little that's truly new in Rust, it's just mixing a bunch of features that were not often together before.

> The compiler is also relatively slow. Would Rust have been worth working with on 30+ year old hardware?

What makes Rust slow to compile is largely independent of what makes it unique. A lot of text has been written about this, but the again massively oversimplified version is that had the designers cared about compile times when the language was being designed and the compiler written, you could have something that's very similar to Rust but also very fast to compile.

Re: Rust in Android: move fast and fix things

#142

Post by echelon »

imron wrote: post #102
iagooar wrote: post #97

Rust has been such a "pain" to learn - at least compared to other, more straight-forward languages. But boy does it feel good when you know that after a few back and forths with the compiler, the code compiles and you know, there is not much that is going to go wrong anymore. Of course, I am exaggerating a bit - and I am not even that experienced with Rust. But after coding with Ruby, JS/TS and Python - it feels refr…

That’s my favorite feature. Rust turns runtime errors into compile time errors. All that fighting with the compiler is just fixing runtime bugs you didn’t realize were there.

Rust is the most defect-free language I have ever used.

I'd wager my production Rust code has 100x fewer errors than comparable Javascript, Python, or even Java code.

The way Result, Option, match, if let, `?`, and the rest of the error handling and type system operate, it's very difficult to write incorrect code.

The language's design objective was to make it hard to write bugs. I'd say it succeeded with flying colors.

Re: Rust in Android: move fast and fix things

#143

Post by IshKebab »

ActorNightly wrote: post #109
danudey wrote: post #91

Earlier quoted context omitted.

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…

>It's all nonsense, How is any of that wrong?

1. You don't know what you're doing - everyone makes mistakes.

2. You can still write bugs in Rust but the point is you are far less likely to.

Re: Rust in Android: move fast and fix things

#144

Post by josephg »

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

> I cannot like Rust syntax, sorry. For me the ideal syntax is C/Go, just to be clear what I like.

I’m sorry if this comes across as dismissive, but I find it hard to take people seriously with complaints about syntax like this. Learning new syntax is really easy. Like, if you’re familiar with C & Go, you could probably learn all the syntax of rust in under an hour. The only surprising part of rust’s syntax is all the weird variants of match expressions.

Rust has some surprising semantics. Like how lifetimes work (and when you need to specify them explicitly). That stuff is legitimately difficult. But learning that if statements don’t need parenthesis is like - seriously whatever dude. If you want to spend your career never learning new stuff, software isn’t for you.

I picked up objective C about 15 years ago. The only thing most of my friends knew about it was that it had “that weird syntax”. It took no time at all to adjust. It’s just not that hard to type [] characters.

Re: Rust in Android: move fast and fix things

#145

Post by pityJuke »

ls-a wrote: post #137
pityJuke wrote: post #120

Earlier quoted context omitted.

There are certain places on the internet where any mention of rewriting in Rust is met with scorn and ire. And while, like any technical decision, there are pros and cons, I cannot see why in the face of astounding evidence like this, you would completely dismiss it. And I say this as someone who has never written a line of Rust in their life (some day I'll find the time).

[flagged]

But every language has those, even C.

You can just ignore those people. I’d hate to miss out on a positive technical choice because some people were being annoying about it.

Re: Rust in Android: move fast and fix things

#146

Post by Mond_ »

mkehrt wrote: post #111
guywithahat wrote: post #89

Earlier quoted context omitted.

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.

> great error handling Go get this completely wrong! It use a tuple rather than an enum for potential errors. This means you can forget to check errors and just use the invalid (nil?) return value from the function. On the other hand, rust uses the Either enum to force you to handle the error. Alternatively you can use the ? operator to pass it to the calling function, which is reflected in the enclosing function's t…

Pet peeves nitpick: it's not even a tuple. Go doesn't have tuples. It just has special-cased "multiple return values", which means that it's often impossible to just stuff the return of a function call (error value and all) into any data structure to aggregate them. You just can't do without first defining a struct since tuples don't exist in Go.

Re: Rust in Android: move fast and fix things

#147

Post by josephg »

bluGill wrote: post #133
danudey wrote: post #63

Earlier quoted context omitted.

As an end user: at least with autotools it's easy for me to see the available configuration options with ./configure --help in a nicely readable way. cmake has -LAH but it's still... kind of awful. At least it knows how to use ninja though.

Problem is autotools doesn't work when cross compiling - the options are there but there is always something wrong, and it isn't easy to fix. cmake can at least get that right. Note that I cross compile a lot of code so this matters to me, if you just do the common thing autolools might work - but make would as well then.

Yeah; generally I find CMake rules are much easier to read and modify than autotools and makefiles. With Makefiles there’s about 18 different ways to write a rule to compile something, and I find I need to go hunting through a bunch of files to figure out how this makefile in particular defined a rule for compiling this C file in particular. CMake is much higher level. I can just see all the higher level targets, and how they’re built. Then - orthogonally - I can modify the build system that CMake uses to compile C code. It makes a lot more sense.

But I’d take cargo over any of this stuff. Cargo means I don’t have to think about compiler flags at all.

Re: Rust in Android: move fast and fix things

#148

Post by o11c »

ikety wrote: post #106
iagooar wrote: post #97

Rust has been such a "pain" to learn - at least compared to other, more straight-forward languages. But boy does it feel good when you know that after a few back and forths with the compiler, the code compiles and you know, there is not much that is going to go wrong anymore. Of course, I am exaggerating a bit - and I am not even that experienced with Rust. But after coding with Ruby, JS/TS and Python - it feels refr…

I'm interested in what scenarios you don't get this same feeling when writing TS code? I of course agree with Ruby, JS, and Python.

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.

Re: Rust in Android: move fast and fix things

#149

Post by Mond_ »

ActorNightly wrote: post #126
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…

>if your code compiles, it usually runs just fine. This was the same argument for Java, which is memory safe, fairly strict in terms of ownership. The fact is, Rust addresses only one memory safe thing, and that is double free. If you don't understand why that is, you probably shouldn't talk about memory safety. The dividends never get there if you don't ever run into this. >And then there's the fact that the program…

> The fact is, Rust addresses only one memory safe thing, and that is double free. If you don't understand why that is, you probably shouldn't talk about memory safety.

How does Rust not address use after free?

Re: Rust in Android: move fast and fix things

#150

Post by linkage »

pityJuke wrote: post #120
habibur wrote: post #74

5 million Rust LOC One potential memory safety vulnerability found Rust is 0.2 vuln per 1 MLOC. Compared to C and C++ : 1,000 memory safety vulnerabilities per MLOC. Key take.

There are certain places on the internet where any mention of rewriting in Rust is met with scorn and ire. And while, like any technical decision, there are pros and cons, I cannot see why in the face of astounding evidence like this, you would completely dismiss it. And I say this as someone who has never written a line of Rust in their life (some day I'll find the time).

> I cannot see why in the face of astounding evidence like this, you would completely dismiss it.

Because it's not a silver bullet. That safety comes at a cost; Rust is much more difficult to learn than C or Zig and the compilation time for code with equivalent semantics is an order of magnitude greater. It has also added a great deal of toolchain complexity to projects like the Linux kernel.

People have decided that the pros outweigh the cons in those particular cases, but those cons exist nonetheless.

Post reply on HN