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

91–100 of 279 posts

Re: Implications of Rewriting a Browser Component in Rust

#91

Post by dtech »

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…

> If you e.g. have a `print foo` in some obscure branch that rarely happens, that print will ruin your day if you use Python 3

You can use any compiled language for that though, and even some uncompiled ones (PHP will refuse to run the file)

Re: Implications of Rewriting a Browser Component in Rust

#92

Post by pjmlp »

masklinn wrote: post #59
hedora wrote: post #55

Earlier quoted context omitted.

Overall, it did a decent job of being balanced, but I don’t buy the memory overflow example at all. For one thing, idiomatic C++ bounds checks by default. You need to use at(). If you don’t like typing at(), you can implement an array type that always bounds checks fairly easily. On that note, the vulnerable c++ code should be using accessors, not indexing to access the oddly packed and laid out array. Even the fixed…

> For one thing, idiomatic C++ bounds checks by default. You need to use at(). Sounds like it doesn't check by default then. It checks if you remember to check using the more verbose bounds-checking method. Not unlike the issues with subscripting std::map.

It is implementation dependent.

operator[]() does not require bounds checking by ISO C++, however most compilers do actually enable bounds checking in debug builds.

Visual C++ certainly does it for example.

Re: Implications of Rewriting a Browser Component in Rust

#93

Post by duxup »

gardaani wrote: post #89
duxup wrote: post #33

Earlier quoted context omitted.

Yeah I keep hearing / reading about rust, even seen some demos but the demos all end with "oh no I'm not using this for anything". Still cool but ... want to see someone doing something in production / get their thoughts on that. Edit: To be clear I'm not saying anyone isn't using it, this is just more of a comment about the impression I can get when I hear about X tech is so cool, but that's most of what I hear and…

Dropbox is using Rust to decompress Brotli: https://blogs.dropbox.com/tech/2016/06/lossless-compression-...

Thank you.

Re: Implications of Rewriting a Browser Component in Rust

#94

Post by epage »

asdkhadsj wrote: post #84
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…

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

Re: Implications of Rewriting a Browser Component in Rust

#95

Post by pjmlp »

TheAsprngHacker wrote: post #65
masklinn wrote: post #59

Earlier quoted context omitted.

> For one thing, idiomatic C++ bounds checks by default. You need to use at(). Sounds like it doesn't check by default then. It checks if you remember to check using the more verbose bounds-checking method. Not unlike the issues with subscripting std::map.

I have some experience in C++, and I am familiar enough with the standard library to remember that operator[] doesn't check bounds while the at member function does. I would assume that the Firefox C++ programmers know this as well. However, maybe I'm wrong or have too much faith? Or, maybe, the programmer was aware that operator[] didn't perform bounds checking, but opted to use it for some reason? A good way to dis…

Most debug builds across major C++ compilers do support it though.

Re: Implications of Rewriting a Browser Component in Rust

#96

Post by kbenson »

duxup wrote: post #51
chillydawg wrote: post #46

Earlier quoted context omitted.

Firefox?

I'm not saying nobody is using it, just the volume of "hey this is so cool" gets to be a bit much and I want to see more "here it is solving problems in production for a real thing".

The explorations and small little demos and projects in a language is almost always higher than the number of production uses, it's just that in popular languages nobody cares to read much about it (or at least share is so it spreads), because it's already known. Rust is still fairly uncommon, so you're bound to see a lot of people announcing their experiences while playing around with it, and that can skew the perceived ratio of things.

I think the problem is solved by paying less attention to the stuff you care about less, and/or seeking out more production(y) uses if desired by looking in places where it's already common, such as /r/rust, where the content ratio will naturally fall more favorably towards production uses, libraries and advanced discussions since a minimum level of experience (or at least interest) can be assumed.

Re: Implications of Rewriting a Browser Component in Rust

#97

Post by wyldfire »

FreeFull wrote: post #79
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…

Python will actually give you an error for `print foo` as soon as it parses the file. But there definitely are other scenarios where you'll only get the error in the middle of execution (such as passing the wrong type of thing as an argument to a function)

Agreed but Python lazy-loads & parses files as packages are imported. By convention these are all at file scope and at the top of the files, so it's often confined to an initialization phase. But...sometimes developers use clever fallback behavior by catching ImportError.

So the scenario described is possible to escape simple tests, I suppose.

Re: Implications of Rewriting a Browser Component in Rust

#98

Post by londt8 »

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…

I recommend using mypy for python, type safe python has came a long way. The type annotation syntax has been in the language spec for years

Re: Implications of Rewriting a Browser Component in Rust

#99

Post by svnpenn »

masklinn wrote: post #83
TheAsprngHacker wrote: post #65

Earlier quoted context omitted.

I have some experience in C++, and I am familiar enough with the standard library to remember that operator[] doesn't check bounds while the at member function does. I would assume that the Firefox C++ programmers know this as well. However, maybe I'm wrong or have too much faith? Or, maybe, the programmer was aware that operator[] didn't perform bounds checking, but opted to use it for some reason? A good way to dis…

> I have some experience in C++, and I am familiar enough with the standard library to remember that operator[] doesn't check bounds while the at member function does. Everybody knows you're supposed to check pointers for being null, and yet time and time again developers fail. As long as you rely on human nature and provide one API which is simple, convenient, obvious and dangerous and one which is complex, inconven…

this is so true

and has been my experience with unwrap

they dont want people to use it but the alternative is so verbose and clunky

Re: Implications of Rewriting a Browser Component in Rust

#100

Post by marmaduke »

wyldfire wrote: post #97
FreeFull wrote: post #79

Earlier quoted context omitted.

Python will actually give you an error for `print foo` as soon as it parses the file. But there definitely are other scenarios where you'll only get the error in the middle of execution (such as passing the wrong type of thing as an argument to a function)

Agreed but Python lazy-loads & parses files as packages are imported. By convention these are all at file scope and at the top of the files, so it's often confined to an initialization phase. But...sometimes developers use clever fallback behavior by catching ImportError. So the scenario described is possible to escape simple tests, I suppose.

Doesn’t the print raise a SyntaxError not ImportError?
Post reply on HN