Live data from Hacker News

Implications of Rewriting a Browser Component in Rust

hacks.mozilla.org

181–190 of 279 posts

Re: Implications of Rewriting a Browser Component in Rust

#181

Earlier quoted context omitted.

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 ?

I tried to change some constants in random places(in 1 line each time) and on average it's ~10 seconds Also compilation unit in rust is a crate. I guess if your app can be separated in different crates it can ease the pain.

Re: Implications of Rewriting a Browser Component in Rust

#183
post #149

Earlier quoted context omitted.

Aka exceptions. Yes, chaps, that Result type is all but isomorphic with checked exceptions, Java-style.

Semantically, returning a sum type like Result absolutely is the same thing as exceptions (ie, it's the exception monad). However, there's one very important language design difference between this and Java-styled checked exceptions: using sum type gives you effect polymorphism for free. This means you can write (say) a map function which says it has precisely the same exception type of its argument function, using t…

No, lack of static parameterization of the representation of failure is not the problem with checked exceptions. In fact the prison of being forced to construct a tunnel in the (static) type system to carry your error information, irrespective of how dynamic it becomes, is the torture that kills the idea. Errors are fundamentally the leaks in abstractions. They betray the implementation.

The network error that makes a mockery of pretending something is local. The dynamic link error that discloses a pluggable implementation. And all the steps between giving lie to the idea that errors should be caught and handled anywhere near their occurrence - when the only code that knows about the actual final composition is at the top of the stack, far far away, a perilous journey for a fragment of error info - unless such transport is automated, and not gated at customs, as so many checked exceptions boundaries end up being.

I'm in favour of error values for functions that return errors in normal circumstances. But they should be exceedingly easy to dispatch into an unwind mechanism, if it turns out you're not interested. Almost all of the time, the code in the middle doesn't care. Why should it pay the tariff for the transport?

Re: Implications of Rewriting a Browser Component in Rust

#184
post #72

This is in tune with my own experience using Rust in production: it can stop you from doing certain classes of mistakes, but it won't stop you from doing stupid things. But the idea that I don't have to think about certain classes of problems allows me to give these stupid things more focus, which is surprisingly refreshing. The predictable nature of Rust was so refreshing for me that I ended up using it even for sma…

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

> I have no understanding why last time was so painful, and this time it's been so amazing.

It has been my experience that if I try to learn something hard and give up and then come back to it a few months later, I have a way easier time even with no apparent changes in process. I suspect some of it is giving your brain time to process fundamentals or something.

Re: Implications of Rewriting a Browser Component in Rust

#185
post #36

Earlier quoted context omitted.

This is actually an interesting distinction. The way that Rust defines "safety" is a little jargon-ish. It's probably more useful than the (highly impractical) colloquial meaning, but still different. In a rust context, "safety" means that the program is protected from a very specific set of things. One might expect that set to contain things like crashing (panic! and friends) and leaking memory (forget). It does not…

But the parent's point remains: a Java NPE and a panic because of unwrap are really equivalent. Not really unsafe in the C sense, but equally bad as unhandled crashes.

There's one really major distinction - you can `grep` for `unwrap`. You could grep for null, but that won't tell you if an NPE elsewhere is possible, and it won't hit every single case (like 3rd party libs returning null).

Making bugs grep'able is huge.

Re: Implications of Rewriting a Browser Component in Rust

#186
post #156

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…

I agree entirely.

One of the reasons why when I learn a new language I deliberately research the idiomatic way to write that language, it saves a bunch of trying to hammer a square peg into a round hole time.

Also some languages purely because of the domain they are in can do things in ways that others can't (trivially) do so if you treat each language as "foo" with different syntax you end up hobbling yourself to the lowest common denominator of "foo"'s features across every language you use.

Re: Implications of Rewriting a Browser Component in Rust

#187

Earlier quoted context omitted.

But the parent's point remains: a Java NPE and a panic because of unwrap are really equivalent. Not really unsafe in the C sense, but equally bad as unhandled crashes.

There's one really major distinction - you can `grep` for `unwrap`. You could grep for null, but that won't tell you if an NPE elsewhere is possible, and it won't hit every single case (like 3rd party libs returning null). Making bugs grep'able is huge.

Greppable also means it is trivially lintable. And the standard linter Clippy defaults since two years to disallow unwrap()

Re: Implications of Rewriting a Browser Component in Rust

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

Curious about memory usage too

Re: Implications of Rewriting a Browser Component in Rust

#189

Earlier quoted context omitted.

Ada is awesome, and if compiler writers had been more timely it might have taken hold. Rust solves the same problems without a runtime, and about 3 times the performance. Granted it looks like c++ and ocaml made a particularly ugly child.

>> [...] solves the same problems without a runtime, and about 3 times the performance. I think you should look more into Ada. The only "runtime" is for the exception handling and bounds checking, both of which can be turned off if needed. And I don't know where you got that "3 times" figure from? Do you have an example you are referring to?

I knew you could turn off the runtime but not about the formal verification lint tools that make it safe to do so. My reference for performance is the benchmark game. If you or someone else can mod those programs to beat rust I'd be thrilled. I like Ada.

Re: Implications of Rewriting a Browser Component in Rust

#190
post #141

Earlier quoted context omitted.

Because people underestimate the amount of effort needed to learn a new language at first?

For real Beginners to programming Rust can be hard, because concepts like pointers are hard in most languages that use them. For Programmers that try Rust out Rust can be hard because they are stubornly trying to program Rust as if it were Python/Java/C/C++/Foo – but it isn't. Rust as a language makes certain types of approaches (or anti patterns) nearly impossible. In the beginning it happens quite often that after…

From my friends that have tried rust, creating a graph or doubly linked list without using some special structures is fairly painful or impossible. You can create a graph by using some sort of adjacency matrix or some other kind of structure that keeps ownership in some sort of tree without much pain, but that has it's own downsides.
Post reply on HN