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

Implications of Rewriting a Browser Component in Rust

hacks.mozilla.org

Post reply on HN
Print view View original

161–170 of 279 posts

Re: Implications of Rewriting a Browser Component in Rust

#161

Post by Gibbon1 »

atoav wrote: post #156
Gibbon1 wrote: post #121

Earlier quoted context omitted.

Have not used rust but I'm assuming it's because when you're down a rat hole rust stops you cold at every turn. You need to back up and rethink what you're trying to do. But when you don't have a good handle on what rust is complaining about you can't see that.

The books are incredibly well written. When people are “stopped cold at every turn” they are usually programmers who come to Rust with a metric ton of existing assumptions how to solve certain problems, without really thinking about the concepts of the language itself. When a C++ programmer starts with python they will write incedibly “unpythonic” code, when they do the same thing in Rust, it just won’t compile. IMO…

You've restated the point I was trying to make much better than I did.

Re: Implications of Rewriting a Browser Component in Rust

#162

Post by rujuladanh »

The article is arguing that Rust somehow has better capabilities than C++ to fight memory-related bugs, but the example vulnerability given is not something Rust can solve nor is more powerful than C++ in its “bug catching” capabilities regarding this kind of bug.

Concretely, the article claims that in Rust the vulnerability doesn’t become a bigger problem because it simply crashes at run-time due to built-in bounds checking. True, but that is alao the case as well with C++ if you were using the equivalent Vec type with mandatory bounds checking - which many projects do (and, critically, enforce).

Personally, I like what Rust brought to the compiler/language world. However, some people is definitely overstating the case. Most non-trivial memory-safety errors and vulnerabilities are related to runtime problems like the example shown. In these, no language can help in the general case - we are not solving the Halting Problem. Therefore, saying Rust is immune to memory-related problems is not true. It is true, however, that those bugs will not trigger anything worse than a crash if there is no unsafe blocks. The same way that many other common languages out there do (Java, C# and many others).

The same way, I have seen people (and even the linked blog) to claim Rust is free of race conditions or thread-safety issues (even if it introduced great ideas to write correct code).

Giving a false sense of security is the worst thing we can do.

Re: Implications of Rewriting a Browser Component in Rust

#163

Post by bluejekyll »

andrekandre wrote: post #158
bluejekyll wrote: post #34

Earlier quoted context omitted.

> I think they're relatively simple to avoid? Most issues in software fall into this category, though. The issue with Java’s null is that it’s not type safe. The language is generally a strongly typed language, except in the case of null. And until Value Types land, there is no way to express nullability to the compiler. The arguments you make aren’t all that different than the undefined behavior arguments with C. “J…

this is just an honest question, and i’m genuinely curious, but why couldn’t Optional be done as an immutable reference type... why does it need value types to be implemented first?

do you mean like a final field in an class?

Re: Implications of Rewriting a Browser Component in Rust

#164

Post by mrath »

bluejekyll wrote: post #22
mrath wrote: post #2

I primarily use Java for my job. Security and memory related features of Rust are not an advantage compared to Java. But I like rust because it feels modern and produces efficient standalone binaries. Most of my hobby projects are in Rust now. But I would not rewrite any of my work projects in Rust even though they require ultimate performance. That would be a maintenance burden. It is great to see people rewriting i…

For me, also primarily a Java person before Rust, it’s datarace safety that captured me. Java’s executors improve the world, but I can’t count the number of concurrency bugs that I had in Java that are not possible in safe Rust. This isn’t just my code, btw, but large teams where it’s hard to disseminate good practices when building threadsafe code. If it had been in Rust, those issues wouldn’t have happened. Other t…

about RAII there is quite a bit of support in recent Java versions not quite as good as Rust but there is support.

Data race is one other thing, I do have data race issues but that is very rare. Some of the static analysis tools even catch these anti patterns.

Re: Implications of Rewriting a Browser Component in Rust

#165

Post by mrath »

ianlevesque wrote: post #40
mrath wrote: post #2

I primarily use Java for my job. Security and memory related features of Rust are not an advantage compared to Java. But I like rust because it feels modern and produces efficient standalone binaries. Most of my hobby projects are in Rust now. But I would not rewrite any of my work projects in Rust even though they require ultimate performance. That would be a maintenance burden. It is great to see people rewriting i…

I use Java constantly in my job and recently tried rewriting a math & memory heavy component in rust to see what performance gains there might be. Surprisingly (to me) the naive rust version was ~15% slower than Java. There’s probably room for more rust optimization but it was interesting that “efficient standalone binaries” doesn’t automatically mean faster too when competing with HotSpot.

I would except best performing Java code to be slower than best performing Rust code. But comparing general cases is not going to be simple.

Re: Implications of Rewriting a Browser Component in Rust

#166

Post by asdkhadsj »

kingbirdy wrote: post #160
asdkhadsj wrote: post #84

Earlier quoted context omitted.

Agree completely. For a bit of my own story, a year+ ago I had the option to write a project in Rust and evaluated it vs Go. Long story short, I tried rust, and it was a massive headache and I failed. We used Go (as I had been for ~4 years). Fast forward to ~2 months ago, a work project dictated tight control over memory which, while possible in Go, had me looking at alternatives. I decided to give Rust another try.…

How do you like Kakoune? It's the first I've heard of it

Love it - was a Vim user for many years before that. I will say that while the Unix-y design is really cool, the plugin system written around Unix (Bash) is a bit of a pain. You technically don't need to use bash at all, but idiomatic plugins tend too.. so.. meh.

These days I'm wanting out of the Terminal - but wherever I go, I'll need to take Kakoune's style of modal navigation with me. I love it too much.

_(For reference, I'm hoping Xi editor implements the foundation of modal editing, and then I can make Kakoune style editing work in Xi Editor)_

Re: Implications of Rewriting a Browser Component in Rust

#167

Post by gameswithgo »

gubbrora wrote: post #6

> could have been caught by a run time bounds check And here I thought rust was all about zero cost abstractions.

normally you can use iterators to access arrays and when you do, array bounds checks are elided.

if you can't use iterators, and you need to omit bounds checks for perf, you can do so with unsafe blocks.

Re: Implications of Rewriting a Browser Component in Rust

#168

Post by rujuladanh »

rujuladanh wrote: post #162

The article is arguing that Rust somehow has better capabilities than C++ to fight memory-related bugs, but the example vulnerability given is not something Rust can solve nor is more powerful than C++ in its “bug catching” capabilities regarding this kind of bug. Concretely, the article claims that in Rust the vulnerability doesn’t become a bigger problem because it simply crashes at run-time due to built-in bounds…

(Continued...)

It is not realistic either to ask everyone and every company to rewrite all their C/C++ code in Rust. Even if it were financially doable and a rewrite were to happen, in many cases it would simply be best to move to a language like C# anyway, not Rust; for productivity reasons. Where performance allows, of course.

In my opinion, the realistic and pragmatic solution is, instead, to strive to make all languages (in particular C and C++) embrace security-first approaches/types/mechanisms like Rust does. The compiler tecnology is already written - now retrofit as much as possible into C++ (even to the point of introducing a “safe” scope if needed) and allow companies to embrace it at minimal cost and progressively.

Re: Implications of Rewriting a Browser Component in Rust

#169

Post by herogreen »

pum-purum wrote: post #113
pum-purum wrote: post #107

Earlier quoted context omitted.

Compile time. For my 9k lines project it takes 20 sec to compile in debug mode and 1 minute in release. Wich is insane because I have to do a lot of runs to test things(where cargo check can't help).

In spite of this i'm in love with Rust

If you modify a single line and rebuild, how much time does it takes, on average ?

Re: Implications of Rewriting a Browser Component in Rust

#170

Post by Sharlin »

epage wrote: post #94
asdkhadsj wrote: post #84

Earlier quoted context omitted.

Agree completely. For a bit of my own story, a year+ ago I had the option to write a project in Rust and evaluated it vs Go. Long story short, I tried rust, and it was a massive headache and I failed. We used Go (as I had been for ~4 years). Fast forward to ~2 months ago, a work project dictated tight control over memory which, while possible in Go, had me looking at alternatives. I decided to give Rust another try.…

> 1. I find it odd that some things like slice reads can still panic by default. Yes, I can use `foo.get(1)` to avoid panics, but still - it's a bit odd to me. I wonder if this is similar to C++'s `[]` vs `at`. `at` does implicit bounds checking but, as an optimization, if you are already doing an explicit bounds check, you can elide the implicit check via `[]`.

It's more about ergonomics. With `get` you get an `Option` which allows you to handle the out-of-bounds situation, but is unnecessarily noisy when you know that the index must be valid unless the program is buggy (and in that case you most likely want to abort anyway).
Post reply on HN