Re:Implications of Rewriting a Browser Component in Rust
by int_19h on Thursday February 28, 2019 @08:41PM
(#19277264)
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.
[ Parent
| on HN ]
Re:Implications of Rewriting a Browser Component in Rust
by atoav on Friday March 01, 2019 @05:24AM
(#19279307)
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
by int_19h on Friday March 01, 2019 @05:59PM
(#19286144)
> 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.
It's the same as with static vs dynamic typing - some things are just easier to model with dynamic, because you don't have to fight with the type checker to prove that your program really is sound when you know that it is. But, of course, you might believe it to be sound when it really isn't...