Be advised: this thread is not for serious in-depth discussion of weighty topics (we have a link for that), this thread is not for anything Culture War related. This thread is for Fun. You got jokes? Share 'em. You got silly questions? Ask 'em.
- 127
- 2
Jump in the discussion.
No email address required.
Notes -
Well, I've been switching back and forth between Windows 10 and Linux Mint for a few weeks now. Windows for work, and Linux for pleasure. I stopped trying to have steam share a steam library between both OS's. For one, Linux and Windows kept fighting over whether the linux or windows versions of the games should be installed. Second, I saw a lot of posts about how Linux eventually corrupts NTFS drives if you try to use them for anything other than simple data storage. So that's a thing I guess.
I've been playing Doom 2016 in Linux thanks to Proton, and it's pretty OK. Every now and again pulling up the menu tanks the framerate, but not consistently. Outside of that it runs fantastic. Because I'm a fucking nerd, I got some simple C programming with SDL set up, as well as a Rust dev environment because I decided I need to learn that. I hate it. It disagrees with all my sensibilities about "talking computer", and thus far I find it's constructs around "borrowing" references silly and contrived, especially in light of being able to assign unsafe sections of code that ignore it's memory safety rules. I guess it assumes you'll be responsible with that, but it feels like a half measure to me, and no replacement for actual skill. All the same, since I mostly work on government contracts, a day may come where it's a requirement.
Anyways, Linux seems like a super viable alternative to Windows these days thanks to Proton. If my work didn't require windows, I'd try to shift over to it entirely. But since a local instance of IIS is essential in my day to day work, that's incredibly unlikely.
That's pretty much the idea. Rather than C(++) where unsafe memory access can happen anywhere, in Rust the strategy is to limit the unsafe scope so that you can focus really hard on getting those parts right.
It doesn't seem like a half measure to me, though. The reality (for better or for worse) is that when you're doing systems programming you're going to have to access raw memory sometimes (e.g. memory mapped registers for devices). So they have to have some kind of escape hatch where you are allowed to do things that the compiler can't verify are safe. Maybe that doesn't look exactly like what Rust has, but it still has to exist somehow or other.
Also note that unsafe blocks don't completely let you off the hook for Rust's memory rules. For example, you still can't take two &mut references to the same thing, nor can you use a variable after you transfer ownership to another function. So it's not a complete free for all or anything.
Also worth highlighting that a bug in an unsafe block can cause nonlocal misbehavior in a 'safe' portion of code.
In my, admittedly somewhat brief, experience with Rust in embedded, there are hardware constructs that result in much of the hairy lowlevel performance-critical driver code being 'unsafe' for one reason or another - and it is more difficult to get
unsafecorrect than to write C.More options
Context Copy link
More options
Context Copy link
More options
Context Copy link