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

191–200 of 279 posts

Re: Implications of Rewriting a Browser Component in Rust

#191

Post by rwmj »

woolvalley wrote: post #190
atoav wrote: post #141

Earlier quoted context omitted.

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.

This was also my experience. It's a fine language if you can't (or more usually "won't" for spurious reasons) use a garbage collector. However a lot of things are just easier to do using a GC, and I suspect in many, not all, of the use cases of Rust, a GC would be just fine.

(Also I have to rant here a bit: Yes I know the GC you used in Java or Emacs in 1997 was terrible, but modern GCs are very good indeed)

Re: Implications of Rewriting a Browser Component in Rust

#192

Post by cetra3 »

duxup wrote: post #33
rkangel wrote: post #4

It's nice to see a balanced, real world, case study including 'these things are fixed by Rust', 'these are problems that don't occur in idiomatic Rust', and 'these are problems that Rust can't help you with'. I'm a big fan of Rust, but the one sided 'Rust makes all the problems go away' articles don't provide any value.

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…

Our product is basically written in Rust (~40k LoC) [1]. When I say basically: there are a few backend components that are written in Java (i.e, ActiveMQ) and the frontend is TypeScript/React, but it is mostly Rust.

[1]: https://www.schoolbench.com.au/

Re: Implications of Rewriting a Browser Component in Rust

#193

Post by int_19h »

masklinn wrote: post #128
epage wrote: post #94

Earlier quoted context omitted.

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

C++ at() doesn't check and abort, it checks and throws a specific documented exception that you can catch. So it is, in fact, closer to get(), just using a very inefficient way of reporting.

Re: Implications of Rewriting a Browser Component in Rust

#194

Post by int_19h »

johnisgood wrote: post #126
gameswithgo wrote: post #123

Earlier quoted context omitted.

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

Can you recommend a good book on SPARK in general? I've read one on Ada 2012 itself, and what it had to say about Ravenscar and SPARK got me interested.

Re: Implications of Rewriting a Browser Component in Rust

#195

Post by int_19h »

TheAsprngHacker wrote: post #151
pjmlp wrote: post #92

Earlier quoted context omitted.

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.

Huh. According to https://en.cppreference.com/w/cpp/container/vector/operator_... , “no bounds checking is performed.” I find cppreference.com generally trustworthy, but maybe it’s wrong here? Or, maybe “no bounds checking” actually means “no guaranteed bounds checking?”

You need to look at the text of the Standard itself when it comes to this level of language lawyering. The short answer is that operator[] has undefined behavior if the index is out of range. Performing a check and terminating the program with some kind of runtime error is a legal subset of "undefined behavior", and so it's commonly done in debug builds, but you cannot rely on it in any sense.

Re: Implications of Rewriting a Browser Component in Rust

#196

Post by int_19h »

hedora wrote: post #55
rkangel wrote: post #4

It's nice to see a balanced, real world, case study including 'these things are fixed by Rust', 'these are problems that don't occur in idiomatic Rust', and 'these are problems that Rust can't help you with'. I'm a big fan of Rust, but the one sided 'Rust makes all the problems go away' articles don't provide any value.

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…

I'm pretty sure OP meant to write "idiomatic C++ does not bounds check". That's certainly true - the only place I've ever seen at() in use is in textbooks, never in production code. It doesn't really make much sense, because the moment you start using iterators, it's all unchecked anyway, so why bother with at() specifically?

Re: Implications of Rewriting a Browser Component in Rust

#197

Post by int_19h »

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

I wonder if it has something to do with the nature of the problems. Rust can be very smooth or a real pain, depending on the data structures you need to model - basically, whenever ownership is unclear and sharing is common, it's going to be more painful.

Re: Implications of Rewriting a Browser Component in Rust

#198

Post by int_19h »

wahern wrote: post #178
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…

> The “thread safe by default” property sounds interesting; I’d be interested in reading more about that. This property is simply a corollary to Rust's ownership invariants enforced by the borrow checker. There can only be a single live mutable reference to any object, therefore two threads can never hold mutable references to the same object simultaneously. Similarly, all objects must have a lifetime at least as lon…

> Contrast that with Windows programming or, especially, Java, where the expectation is that objects are shareable and guarantee thread-safety internally.

That's not an expectation on either. For example, the single most common phrase you can see on MSDN in class docs is: "Public static members of this type are thread safe. Any instance members are not guaranteed to be thread safe."

There was a period when it was different for some things. In particular, both Java and .NET had thread-safe standard collection classes initially - e.g. Vector in Java, ArrayList in .NET. This has proven to be a bad trade-off in both cases - it's a massive perf hit for something that's not even all that useful even to threaded code, because in practice you often need to perform multiple operations on the collection atomically, and then you still need your own lock.

So they have since been obsoleted by new collections that do not attempt to do any thread synchronization; the old collections remain for backwards compatibility purposes. Modern idiomatic Java or C# code doesn't do any kind of synchronization or locking to protect the caller, unless that is specifically the purpose of this class or function to provide such things.

So I wouldn't say there's significant cultural differences between Windows, Unix and Java in that regard.

Re: Implications of Rewriting a Browser Component in Rust

#199

Post by int_19h »

ChrisSD wrote: post #143
jcranmer wrote: post #131

Earlier quoted context omitted.

Multiple return values. Ownership annotations. SIMD type support. String charset information. More challenging would be to include stuff like allocation management (how to free a pointer when it's done), GC integration, function boxing, iterator/generator support. Vtables and cross-language inheritance is interesting but difficult. One point of clarity: this would be an FFI ABI, not necessarily expecting that most da…

> Vtables and cross-language inheritance is interesting but difficult. Windows' COM "solved" that problem. For example see C++/WinRT[0] for a modern C++ interface to COM. Or the C# .NET equivalents. [0] https://github.com/Microsoft/cppwinrt

Take a look at this.

https://github.com/Microsoft/xlang

Re: Implications of Rewriting a Browser Component in Rust

#200

Post by int_19h »

blub wrote: post #14
rat9988 wrote: post #10

Earlier quoted context omitted.

Rust is about zero cost abstraction. Bound checks can be disabled.

And then it's no longer memory safe, which makes the whole exercise pointless...

Your choices are exactly the same as in C++ - memory-safe with runtime checks, or memory-unsafe without - except that the default is different.

But the real benefit of Rust is ownership tracking - and that one is zero overhead.

Post reply on HN