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

121–130 of 279 posts

Re: Implications of Rewriting a Browser Component in Rust

#121

Post by Gibbon1 »

insulfrable wrote: post #114
steveklabnik wrote: post #87

Earlier quoted context omitted.

It’s probably a combination of both things, but “I tried rust, struggled, quit, came back months or years later and now I have no idea why I thought it was so hard” is certainly a recurring pattern we’ve seen. Glad it’s working for you now!

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

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.

Re: Implications of Rewriting a Browser Component in Rust

#122

Post by wilsonthewhale »

jcranmer wrote: post #105
jupp0r wrote: post #60

One of the major hurdles in rewriting parts of C++ projects in Rust is that the interop surface between both languages is C. The necessary interface layer has created more bugs and work than the conversion saved. I'd really like to see more high-level interoperability between the two languages in the future, although C++ is a pretty fast-moving target at this point, with all the changes in C++20.

Honestly, I wish a few different major languages would get together and start developing system ABIs that move beyond C as the interchange language.

But what would you put in such an ABI beyond what's in the C ABI? Beyond basic data types, struct defintions, and function definitions, languages begin to wildly diverge almost immediately.

Re: Implications of Rewriting a Browser Component in Rust

#123

Post by gameswithgo »

johnisgood wrote: post #90
atoav wrote: 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…

> before but soon got annoyed with obvious errors that would only show up once you run a program. From what I gather you are comparing static vs dynamic typing, and I agree. I do not use Python because I prefer a subset of errors caught at compile-time. However, it is silly to make it sound like that this is somehow limited to Rust. You could just as well have used Go or OCaml and feel "refreshed" because obvious err…

>could you please tell me what kind of official formal proof tools exist for Rust that makes it predictable?

I feel like you aren't really asking a question, that your intent was really to lecture someone, but in case you really are:

* a borrow checker * option types

So OCaml would catch a similar set of obvious errors, though Rust would also catch all data races at compile time, as the borrow checker does that as well as prevent memory mistakes.

Re: Implications of Rewriting a Browser Component in Rust

#124

Post by johnisgood »

matthewmacleod wrote: post #104
johnisgood wrote: post #90

Earlier quoted context omitted.

> before but soon got annoyed with obvious errors that would only show up once you run a program. From what I gather you are comparing static vs dynamic typing, and I agree. I do not use Python because I prefer a subset of errors caught at compile-time. However, it is silly to make it sound like that this is somehow limited to Rust. You could just as well have used Go or OCaml and feel "refreshed" because obvious err…

That’s one aspect of the errors that are avoided, but there are many others too - some of which aren’t solved by other languages. Go, for example, will happily nail through all of your obviously null pointers with gay abandon. The Rust ownership model prevents other classes of bugs. It’s not a panacea—and to be blunt, I find Rust more work than it is worth for the sort of projects I typically work on. But any tools w…

I was responding to the issue I quoted, which really is just a matter of using a programming language with static typing. :)

> some of which aren’t solved by other languages

You only mentioned null pointers, so I will go with that. In Ada, you can have access types (pointers) that are guaranteed to not be null, and accessibility rules of Ada prevent dangling references to declared objects or data that no longer exists, so this particular issue is solved by a language other than Rust. Please feel free to give me other examples of errors or issues that you may believe is not solved by languages other than Rust.

https://www.adaic.org/resources/add_content/standards/05rat/...

> But any tools which can eliminate whole error categories are worth looking at for sure!

I agree. That is why I think Ada/SPARK is awesome! :P

Re: Implications of Rewriting a Browser Component in Rust

#125

Post by galangalalgol »

johnisgood wrote: post #124
matthewmacleod wrote: post #104

Earlier quoted context omitted.

That’s one aspect of the errors that are avoided, but there are many others too - some of which aren’t solved by other languages. Go, for example, will happily nail through all of your obviously null pointers with gay abandon. The Rust ownership model prevents other classes of bugs. It’s not a panacea—and to be blunt, I find Rust more work than it is worth for the sort of projects I typically work on. But any tools w…

I was responding to the issue I quoted, which really is just a matter of using a programming language with static typing. :) > some of which aren’t solved by other languages You only mentioned null pointers, so I will go with that. In Ada, you can have access types (pointers) that are guaranteed to not be null, and accessibility rules of Ada prevent dangling references to declared objects or data that no longer exist…

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.

Re: Implications of Rewriting a Browser Component in Rust

#126

Post by johnisgood »

gameswithgo wrote: post #123
johnisgood wrote: post #90

Earlier quoted context omitted.

> before but soon got annoyed with obvious errors that would only show up once you run a program. From what I gather you are comparing static vs dynamic typing, and I agree. I do not use Python because I prefer a subset of errors caught at compile-time. However, it is silly to make it sound like that this is somehow limited to Rust. You could just as well have used Go or OCaml and feel "refreshed" because obvious err…

>could you please tell me what kind of official formal proof tools exist for Rust that makes it predictable? I feel like you aren't really asking a question, that your intent was really to lecture someone, but in case you really are: * a borrow checker * option types So OCaml would catch a similar set of obvious errors, though Rust would also catch all data races at compile time, as the borrow checker does that as we…

No, I was really curious. My bad if it looked like I was trying to lecture. I do not think that I have the necessary knowledge in this topic to do that. :)

> a borrow checker

What exactly do you mean? How does it differ from any other language's type system?

> would also catch all data races at compile time

In Ada/SPARK, you can formally verify tasks, too. Please take a look at https://docs.adacore.com/spark2014-docs/html/ug/en/source/co... if you have some time!

> prevent memory mistakes.

Which mistakes are you referring to specifically? I need to know so I can have a meaningful response to it, but all I can say right now is that Ada/SPARK does the same.

Re: Implications of Rewriting a Browser Component in Rust

#127

Post by zaphar »

steveklabnik wrote: post #116
insulfrable wrote: post #114

Earlier quoted context omitted.

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

I'm not sure it's that simple. I've never heard anyone say this about Go, for example.

To be fair, Go is uniquely designed to be easy to learn and become productive with quickly. It was practically a design goal of the language.

Re: Implications of Rewriting a Browser Component in Rust

#128

Post by masklinn »

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 `[]`.

Except Rust's [] behaves like C++'s at (checks and aborts). C++'s [] is called `get_unchecked`.

Re: Implications of Rewriting a Browser Component in Rust

#129

Post by masklinn »

insulfrable wrote: post #114
steveklabnik wrote: post #87

Earlier quoted context omitted.

It’s probably a combination of both things, but “I tried rust, struggled, quit, came back months or years later and now I have no idea why I thought it was so hard” is certainly a recurring pattern we’ve seen. Glad it’s working for you now!

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

There's plenty of languages which take limited / little efforts to learn. So I'd say more that the unfamiliar concepts need to stew or sink in.

One way is to just keep at it until it clicks. An other way is to not do that, but once you've got the words for something you start seeing the issue everywhere, and next time around it makes a lot more sense.

Re: Implications of Rewriting a Browser Component in Rust

#130

Post by steveklabnik »

zaphar wrote: post #127
steveklabnik wrote: post #116

Earlier quoted context omitted.

I'm not sure it's that simple. I've never heard anyone say this about Go, for example.

To be fair, Go is uniquely designed to be easy to learn and become productive with quickly. It was practically a design goal of the language.

Sure. I think it's one of Go's strongest points. But it's still a counter-example to the parent's point. Learning a new language does not inherently require a lot of effort, and so expecting it to be reasonably easy, especially when you're an experienced developer, doesn't seem unreasonable to me.
Post reply on HN