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

231–240 of 279 posts

Re: Implications of Rewriting a Browser Component in Rust

#231

Post by atoav »

int_19h wrote: post #197
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.…

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.

Usually that just means you have to think much harder about the problem you are trying to solve within the new set of requirements (borrow checker, lifetimes).

Weirdly enough these things should also be a hard problem in other non-Garbagecollected languages, but you get away with a lot more when the compiler doesn’t force you.

From a purely practical level there is so much already that I had a hard time finding some data type that had no existing and tested solution for it. Looking at the code in the std library can be enlightening.

Re: Implications of Rewriting a Browser Component in Rust

#232

Post by alex_duf »

chrisweekly wrote: post #75
alex_duf wrote: post #67

Earlier quoted context omitted.

When comparing speed on the JVM with speed with native languages, the only positive side you get from native binaries is cold start nowadays. For a webapp this doesn't matter, but as we're moving towards more cloud functions it start to make a lot of sense. That needs to be ponderated by the fact any real life application will have to access the network at bootstrap to load configuration and therefore your bottleneck…

> "ponderated" Huh! I have a fairly strong vocabulary and thought this might have been a made-up word -- but apparently it means "to weigh down or give substance to", which aligns with your intended point here. TIL

Sorry that's directly brought from French.

English is my second language. I did a quick google search just to make sure it was correct but it's hard to gauge if a word that happen to be in the dictionary is also widely understood.

Re: Implications of Rewriting a Browser Component in Rust

#233

Post by atoav »

c3534l wrote: post #102
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…

I assumed borrowing and lifetimes were part of his experience as well.

Sure, and I find both not very hard as a concept.

The hard thing is not understanding the concepts but learning what this implies for your coding style, especially when you come from a garbage collected language like Python.

Both concept can at times give you hard to solve tasks, but it usually is because the problem you are trying to solve is hard and you cannot just naively hack away without thinking long and hard about it.

Other than that I learned liking the borrow checker and lifetimes because you will get a incredible narrow scope of which variables can matter when — which makes debugging much easier

Re: Implications of Rewriting a Browser Component in Rust

#234

Post by atoav »

jhrmnn wrote: post #103
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…

And with something like Mypy, you can get most of the benefits of static typing even in Python, if you want to. But Rust has so much more to offer, such as memory ownership.

I didn’t know mypy, but I am going to check it out, thanks!

Re: Implications of Rewriting a Browser Component in Rust

#235

Post by Yoric »

Manishearth wrote: post #204
Yoric wrote: post #132

Earlier quoted context omitted.

> What exactly do you mean? How does it differ from any other language's type system? If you're familiar with affine types, this is basically what Rust's borrow checker implements. If you're not familiar, it's a bit complicated to summarize on Hacker News. You should try it out, because it lets you guarantee statically entire classes of properties that non-academic languages struggle with. > In Ada/SPARK, you can for…

It's more than just affine types, it's region typing, which is far less common.

Fair enough.

Re: Implications of Rewriting a Browser Component in Rust

#236

Post by Yoric »

pjmlp wrote: post #214
Yoric wrote: post #142

Earlier quoted context omitted.

I will give you a few examples. My knowledge of Ada is insufficient, so I'll let you tell me whether Ada can solve that without using an external prover (note: being able to use an external prover is great and I haven't seen this done in Rust yet :) – but that's not the topic at hand). 1/ Consider a file `f` (or a socket, etc.). Using the standard library, Rust will statically ensure that, once the file is closed, yo…

SPARK is a subset of Ada 2012. Your examples are possible with contracts.

I'm interested, do you have examples somewhere on how to implement that kind of properties with contracts?

Re: Implications of Rewriting a Browser Component in Rust

#237

Post by yannickmoy »

Yoric wrote: post #236
pjmlp wrote: post #214

Earlier quoted context omitted.

SPARK is a subset of Ada 2012. Your examples are possible with contracts.

I'm interested, do you have examples somewhere on how to implement that kind of properties with contracts?

You can look at this blog post where I used a ghost global variable to hold the current state of the game (see section "Proving Functional Properties of Tetris Code"): https://blog.adacore.com/tetris-in-spark-on-arm-cortex-m4

You can similarly express ghost properties of your types, even though we don't have ghost fields in SPARK. For more on ghost code in SPARK, you can look at this presentation last year from my colleague Claire Dross: https://www.adacore.com/uploads/products/SSAS-Presentations/...

As a more extensive example of a useful library with this kind of contracts for proof, Joffrey Huguet added rich contracts of this kind to the Ada.Text_IO standard library just two weeks ago, as part of his current internship with us. This should be in the FSF trunk in the coming weeks. For example, here are some contracts he added:

   procedure Open
     (File : in out File_Type;
      Mode : File_Mode;
      Name : String;
      Form : String := "")
   with
     Pre    => not Is_Open (File),
     Post   =>
      Is_Open (File)
      and then Ada.Text_IO.Mode (File) = Mode
      and then (if Mode /= In_File
                  then (Line_Length (File) = 0
                        and then Page_Length (File) = 0)),
     Global => (In_Out => File_System);

   procedure Put (File : File_Type; Item : Character) with
     Pre    => Is_Open (File) and then Mode (File) /= In_File,
     Post   =>
       Line_Length (File)'Old = Line_Length (File)
       and Page_Length (File)'Old = Page_Length (File),
     Global => (In_Out => File_System);

   procedure Close  (File : in out File_Type) with
     Pre    => Is_Open (File),
     Post   => not Is_Open (File),
     Global => (In_Out => File_System);

Re: Implications of Rewriting a Browser Component in Rust

#238

Post by empath75 »

scoutt wrote: post #227
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…

A system crash is a bug. Period. In many cases it could lead to Denial of Service. An insulin pump can stop working. I remember when C# came out almost 20 years ago. People said "I can forget about managing memory so I can focus on the logic". Programs kept crashing, memory problems were still there. The article goes with "...remove the burden of memory safety from our shoulders, allowing us to focus on logical corre…

A crash is a bug but not a security problem.

Re: Implications of Rewriting a Browser Component in Rust

#239

Post by maelkum »

Yoric wrote: post #146
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…

I've heard these "idiomatic C++" and "improved data structures" arguments a few times and as a C++ developer, I'm a bit skeptical. Does anybody know of any non-toy C++ projects that actually demonstrate such a high-level of reliable use of C++? If so, how much do they rely on the developers being ideal programmers, who know intimately the intricacies of C++ and how to avoid ending up in UB-land?

I have a codebase that amounts to several kLOC of C++, available here: https://git.sr.ht/~maelkum/viuavm While I openly admit that parts of it are shoddily written, I also try to always use the "reliable subset" of C++.

From my experience it is not hard to make it a habit (e.g. using `::at()` and declaring variables as `auto const x = ...;` is muscle memory at this point) but the code becomes very verbose and looks like programmed defensively to a sometimes ridiculous extent.

So I understand your skepticism. To address the point of relying on developers being "ideal": just turn the compiler warning flags up to eleven, make all warnings errors, and run your tests two times - one time with sanitisers, and the other under Valgrind. This won't catch all errors, sure, but will still make you more confident in your code's reliability.

Re: Implications of Rewriting a Browser Component in Rust

#240

Post by sanxiyn »

herogreen wrote: post #172

Can you build in some kind of "unsafe release" mode, so that every array bound check that were asked in the code are skipped ? If not, would it be an interesting feature ?

This is trivial to implement, but it will never be accepted by Rust upstream. There will be a fork if someone really wants this.
Post reply on HN