161–170 of 186 posts
Earlier quoted context omitted.
This is outdated since Windows Vista, and even more so in Windows 11.
Windows Vista isn't Windows NT 3.x. In the internal versioning, it's not even 4.0.
And it is irrelevant anyway, given that this comment was written from 10.0.26100.
Earlier quoted context omitted.
Windows Vista isn't Windows NT 3.x. In the internal versioning, it's not even 4.0.
Indeed, it is something better, Windows NT 6.0. And it is irrelevant anyway, given that this comment was written from 10.0.26100.
You’re saying they improved the design. I know they added user-privilege device driver support for USB (etc).; did they revert the display compromise/mess as well?
Earlier quoted context omitted.
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.
But those segfaults will either be memory memory safe or your lines will contain “unsafe” or “unchecked” somewhere.
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…
At one point, I found serious bugs (crashing our product) that had existed for over 15 years. (And that was 10 years ago).
Rust may not be perfect but it gives me hope that some classes of stupidity will be either be avoided or made visible (like every function being unsafe because the author was a complete idiot).
Earlier quoted context omitted.
Expensive because of: 1/ a re-write is never easy 2/ rust is specifically tough (because it catches error and forces you to think about it for real, because it makes some contruct (linked list) really hard to implement) for kernel/close to kernel code ?
Both I'd say. Rust imposes more constraints on the structure of code than most languages. The borrow checker really likes ownership trees whereas most languages allow any ownership graph no matter how spaghetti it is. As far as I know that's why Microsoft rewrote Typescript in Go instead of Rust.
However: https://www.reddit.com/r/typescript/comments/wbkfsh/which_pr...
so looks like it's not written in go :-)
Earlier quoted context omitted.
Both I'd say. Rust imposes more constraints on the structure of code than most languages. The borrow checker really likes ownership trees whereas most languages allow any ownership graph no matter how spaghetti it is. As far as I know that's why Microsoft rewrote Typescript in Go instead of Rust.
I've been using rust for several years now and I like the way you explain the essence of the issue: tree instead of spaghetti :-) However: https://www.reddit.com/r/typescript/comments/wbkfsh/which_pr... so looks like it's not written in go :-)
That post is three years old, before the rewrite.
Earlier quoted context omitted.
But those segfaults will either be memory memory safe or your lines will contain “unsafe” or “unchecked” somewhere.
You can make a fully safe segfault the same way you can in go. Swapping a base reference between two child types. The data pointer and vft pointer aren't updated atomically, so a thread safety issue becomes a memory safety one.
Earlier quoted context omitted.
You can make a fully safe segfault the same way you can in go. Swapping a base reference between two child types. The data pointer and vft pointer aren't updated atomically, so a thread safety issue becomes a memory safety one.
This is no longer allowed with strict concurrency
Edit: Ah, the global variable I used had a warning that it isn't concurrency safe I didn't notice. So you can compile it, but if you treat warnings as errors you'd be fine.