101–110 of 186 posts
Earlier quoted context omitted.
I don't think 70% of bugs are memory safety issues. In my experience it's closer to 5%.
probably quite a bit less than 5%, however, they tend to be quite serious when they happen
Earlier quoted context omitted.
I don't think 70% of bugs are memory safety issues. In my experience it's closer to 5%.
I believe this is where that fact comes from [1] Basically, 70% of high severity bugs are memory safety. [1] https://www.chromium.org/Home/chromium-security/memory-safet...
Before the "rewrite it in Rust" comments take over the thread: It is worth noting that the class of bugs described here (logic errors in highly concurrent state machines, incorrect hardware assumptions) wouldn't necessarily be caught by the borrow checker. Rust is fantastic for memory safety, but it will not stop you from misunderstanding the spec of a network card or writing a race condition in unsafe logic that int…
It’s hilarious that you feel the need to preemptively take control of the narrative in anticipation of the Rust people that you fear so much. Is this an irrational fear, I wonder? Reminds me of methods used in the political discourse.
> Is this an irrational fear, I wonder? Reminds me of methods used in the political discourse.
In a sad sort of way, I think its hilarious that hn users have been so completely conditioned to expect rust evangelism any time a topic like this comes up that they wanted to get ahead of it.
Not sure who it says more about, but it sure does say a whole lot.
Earlier quoted context omitted.
Apple claims Swift can be used for systems programming, and is (partly) eating its own dogfood by using it in FoundationDB ( https://news.ycombinator.com/item?id=38444876 ) and by providing examples of embedded projects ( https://www.swift.org/get-started/embedded/ ) I think they are right in that claim, but in making it so, at least some of the code loses some of the readability of Swift. For truly low-level code, y…
Swift is very slow relative to rust or c though. You can also cause seg faults in swift with a few lines. I Don't find any of these languages particularly difficult to read, so I'm not sure why this is listed as a discriminator between them.
Earlier quoted context omitted.
I don't think 70% of bugs are memory safety issues. In my experience it's closer to 5%.
I believe this is where that fact comes from [1] Basically, 70% of high severity bugs are memory safety. [1] https://www.chromium.org/Home/chromium-security/memory-safet...
Earlier quoted context omitted.
What warranties? I assume you’re comparing it to ext4 and not e.g. ZFS?
Here are a few - mandatory byte-range locks enforced by the kernel - explicit sharing modes - guarantees around write ordering and durability - safe delete-on-close - first-class cache coherency contracts for networked access POSIX aims for portability while NTFS/Win32 aims for explicit contracts and enforced behavior. For apps assuming POSIX semantics (e.g. git) NTFS feels rigid and weird. Coming the other way from…
There is also the note that some of them are more database like, than classical filesystems.
Ah, and modern Windows also has Resilient File System (ReFS), which is used on Dev Drives.
[dead]
No they are often found and fixed.
Earlier quoted context omitted.
Yes. As far as kernels go, NT was pretty damn good. So is Mach, by the way, if you can afford the microkernel performance overhead.
Mach is not a very good microkernel at all, because the overhead is much higher than necessary. The L4 family’s IPC design is substantially more efficient, and that’s why they’re used in actual systems. Fuchsia/Zircon have improved on the model further. Someone will of course bring up XNU, but the microkernel aspect of it died when they smashed the FreeBSD kernel into the codebase. DriverKit has brought some userspac…
As opposed to Mach, which is not used in any actual systems
Earlier quoted context omitted.
> It is worth noting that the class of bugs described here (logic errors in highly concurrent state machines, incorrect hardware assumptions) While the bugs you describe are indeed things that aren't directly addressed by Rust's borrow checker, I think the article covers more ground than your comment implies. For example, a significant portion (most?) of the article is simply analyzing the gathered data, like groupin…
It depends what they mean by some of these: are the state machine race conditions logic races (which Rust won’t trivially solve) or data races? If they are data races, are they the kind of ones that Rust will catch (missing atomics/synchronization) or the ones it won’t (bad atomic orderings, etc.). It’s also worth noting that Rust doesn’t prevent integer overflow, and it doesn’t panic on it by default in release buil…
But in the listed categories, I’m equally skeptical that none of them would have benefited from Rust even a bit.
Before the "rewrite it in Rust" comments take over the thread: It is worth noting that the class of bugs described here (logic errors in highly concurrent state machines, incorrect hardware assumptions) wouldn't necessarily be caught by the borrow checker. Rust is fantastic for memory safety, but it will not stop you from misunderstanding the spec of a network card or writing a race condition in unsafe logic that int…
It’s hilarious that you feel the need to preemptively take control of the narrative in anticipation of the Rust people that you fear so much. Is this an irrational fear, I wonder? Reminds me of methods used in the political discourse.