6 ms·
Its hard, but you're trading memory safety for performance. Rust cheerleaders will tell you that its possible to avoid that trade-off, but the proof is in the p
by la_barba 7y ago
Its hard, but you're trading memory safety for performance. Rust cheerleaders will tell you that its possible to avoid that trade-off, but the proof is in the pudding. Its become almost impossible to see a new OS project succeed in the current landscape, so maybe an entire AAA game written in Rust will be an interesting challenge.
Also, being memory safe doesn't get you much (or rather very very little IMHO), because complex code still contains logic bugs, UI bugs, performance bugs, etc, etc. Personally, I want the program to crash rather than keep running only to find out it was silently messing up data or otherwise leaving things in an inconsistent state.
- cwyers 7y agoThe showcase project for Rust is a web browser (after all, Rust started out at Mozilla), which is certainly one of the larger undertakings one can start nowadays.
- la_barba 7y agoWell, I personally wouldn't put any web-browser in the performance applications category. They are important applications, no doubt, and increasing their memory safety is always a plus. But there is something "soft realtime"/definitive about fitting the rendering of millions of textured-polygons, and running AI, Physics, data streaming, audio, gameplay code in a total budget of 16ms per-frame for hours and hours.
- hu3 7y agoHow is Firefox a showcase of Rusts performance when Chrome beats it in benchmarks? https://www.phoronix.com/scan.php?page=news_item&px=Firefox-66-Chrome-73-Benchmarks https://www.phoronix.com/scan.php?page=news_item&px=Firefox-... Not to mention Firefox's poor state in macOS.
- wtetzner 7y agoWhat do you mean by it’s poor state in macOs? I use it as my main browser on macOs both at work and at home, and much prefer it over Chrome.
- hu3 7y agoI envy you. There are complains of Firefox on macs on most Firefox-related threads. Ignore the titles and search comments in recent threads with significant number of comments: https://www.google.com/search?q=site:news.ycombinator.com+firefox+macbook+crash+slow+fan+heat https://www.google.com/search?q=site:news.ycombinator.com+fi... On my machine at current gig it crashes every other day making me lose my containers. It doesn't overheat the machine like some others reported though.
- wolfspider 7y agoAccording to the same benchmarks that test is a few versions older. Compare it to these and they are neck and neck (in theory). Consider that most benchmarking is subjective...depends on so many factors like is this Clear or Ubuntu Linux? Are the chipsets the same? The numbers are different here for "Speedometer" but between both tests there isn't enough information here even to say the tests are comparable just different. https://www.phoronix.com/scan.php?page=article&item=firefox-69-beta&num=3 https://www.phoronix.com/scan.php?page=article&item=firefox-...
- Scuds 7y agoIt's not. You may as well be comparing C++ to Swift. Chrome has had a lot more time and resources put into it anyway while Quantum has only seen release for two years. That said, you're better off comparing CVE counts for Firefox vs Chrome. That said someone could craft a malformed legacy font file that has to be parsed by some dusty win32 code and BOOM!
- cwyers 7y agoRust is 6.5% of Firefox's code: https://4e6.github.io/firefox-lang-stats/ https://4e6.github.io/firefox-lang-stats/ They are working on a new Rust-based rendering engine, Servo, but it hasn't received nearly the level of work that a browser like Chrome has yet.
- steveklabnik 7y ago> Its become almost impossible to see a new OS project succeed in the current landscape, Fuchsia contains a considerable and ever-growing amount of Rust. And if you consider VM infra in the "OS" category, you have Firecracker from Amazon and crosvm from Google as well. > maybe an entire AAA game written in Rust will be an interesting challenge. We'll see how it goes; there is one studio that has made AAA-level games in the past using Rust now, and a new studio that is full of ex-EA folks. > Personally, I want the program to crash rather than keep running The alternative here isn't keeping running, it's "does not compile in the first place". That's even sooner than your crash, and guaranteed, as opposed to "happens to hit the right code path."
- la_barba 7y ago>The alternative here isn't keeping running, it's "does not compile in the first place". That's even sooner than your crash, and guaranteed, as opposed to "happens to hit the right code path." Different people mean different things when they talk about correctness. I think it means accurately capturing the intent of the programmer, i.e. the logic/algorithm/code flow or whatever, and eliminating the ambiguity. How does rust help here?
- steveklabnik 7y agoSure, if you’re talking about that, then Rust has more maintstream tools: a very strong and static type system, built in test framework, that kind of thing. You can help guard against logic bugs by using these tools more effectively, but they do require proficiency to use.
- la_barba 7y agoRight, but such tools are available across multiple programming languages, and the onus is on Test/QA to ensure that. Lets say that Rust eliminates memory crashing bugs by restricting certain freedoms afforded by C or C++. The problem of coordinating between multiple threads of who gets to do what when, and with which data and accurately capturing the intent of the programmer still exists. Now if you view the world through Rust-colored glasses, then any invalid state is the result of a programmer error because they used Rust incorrectly. I'm saying that its this the same kind of programmer error (not being able to specify things without ambiguity or a way to capture intent accurately) that was the cause of the memory bug in C too. Its just that with C you will hard crash whereas in Rust you wont. You didn't crash but you modified a data structure you shouldn't have, and your program will still end up in an inconsistent state. In much the same way, the kernel doesn't care what happens in userspace - which thread is doing what with memory or what userspace resources are being corrupted, etc. The kernel can trivially kill userspace threads at will, and continue to remain rock solid as ever. So yes while the separation of kernelmode and usermode helped the user escape from poorly coded apps, it didn't really help reduce the actual bugs as much. Hopefully that made as much sense as it did in my head! :)
- eklavya 7y agologic bugs + UI bugs + performance bugs < logic bugs + UI bugs + performance bugs + memory bugs Just in this thread stats about memory bugs being 70% of CVEs is presented, so why do you believe "being memory safe doesn't get you much" ? I am not a Rust fanboy and would rather use a GCed language for most work. But I don't get this stubbornness towards progress and better tools. If some tool can make "your" life easier in many ways, use it for your own profit !!
- la_barba 7y agoWell, I'm not opposed to it, as much as I have yet to "see the light". I think that the the original non-trivial problem of deciding which thread or which subroutine gets to change what piece of memory at what time is still there. The original problem was a logic bug, but it manifests as a memory bug in C. As an aside, I've recently been working with PLCs and I've come to respect a lot of the design elements of things like the Siemens GRAPH language which makes it easy to capture my intent for sequential control stuff.