No, I’m saying that when people run into strange bugs, sometimes they put together an issue (like the person behind cve-rs), and sometimes they quietly work around it because they’re busy.
Seeing as I don’t often trawl through issues on the language git, neither really involve notifying me specifically.
My lack of an anecdote does not equate to anecdotal evidence of no issue, just that I haven’t met every rust developer.
Yes, the problems rust is solving are already solved under different constraints. This is not a spicy take.
The world isn’t clamoring to turn a go app into rust specifically for the memory safety they both enjoy.
Systems applications are still almost exclusively written in C & C++, and they absolutely do run into memory bugs. All the time. I work with C almost exclusively for my day job (with shell and rust interspersed), and while tried and tested C programs have far fewer memory bugs than when they were first made, that means the bugs you do find are by their nature more painful to diagnose. Eliminating a whole class of problems in-language is absolutely worth the hype.
If someone did, why would I hear of it?
The code used in cve-rs is not that complicated, and it’s not out of the realm of possibility that somebody would use lifetimes like this if they had just enough knowledge to be dangerous.
I’m as much a rust evangelist as the next guy, but part of having excellent guard rails is loudly pointing out subtle breakages that can cause hard to diagnose issues.
I recently bought a 7800 XT for the same reason, NVIDIA drivers giving me trouble in games and generally making it harder to maintain my system. Unfortunately I ran headfirst into the 6.6 reset bug that made general usage an absolute nightmare.
Open source drivers are still miles ahead of NVIDIA’s binary blob if only because I could shift to 6.7 when it released to fix it, but I guess GPU drivers are always going to be GPU drivers.
I am curious about why performance cores would go with a no-smt implementation; the die area improvements are obvious, but how are they going to spend that die area improvement to make up the performance gap?
AVX only really affects a small subset of applications, so I can’t see that going too far.
A better branch predictor could be a boon, but given how good they are already I’m not sure how they could make up the 50% multi threaded loss.
Perhaps just cramming more physical cores together and a better cache sharing mechanism?
As far as ARM SBCs go, I’d say B tier. Not as good as a RaspberryPi or RockPi but armbian installed great. Had a pain debugging the rockchip video decoder in a container, and still have issues with USB hard drives.
If you’re coming from x86_64, be prepared for some unique challenges.
On an OrangePi with a powered USB hub using a bunch of SSDs.
All except the Minecraft server running on Podman.
deleted by creator