If a Rust function can panic, there's generally a non-panicking alternative. For example, `Vec` indexing has `vec[n]` as the panicking version and `vec.get(n)` as the version that can return `None` when there's nothing at that index.
I do wish this is something Rust had done better though - the panicking versions often look more attractive and obvious to developers, and that's the wrong way round. Vec indexing, IMO, should return Option<T>.
One of my dream projects is creating a Rust stdlib based solely on panics for error handling. Sure, it'd be incompatible with everything, but that might be a feature, not a bug.
One of my dreams is for someone to create a Rust stdlib, full stop.
I love Rust the language, but the current bazar of little bits of functionality scattered around in the form of a zoo of crates is such a mess compared to, say, Java's class library (I/O, data structures, std. algorthms for searching, sorting etc., arranged in a logically and hierarchially named way).
I'm not against alternative implementations, but I'd rather have one "official" implementation that everyone knows that covers most cases and makes for the idiomatic reading of source code.
Sylvain Kerkour described the problems Rust faces by having a limited standard library:
"The time has come for Rust to graduate from a shadow employment program in Big Tech companies to a programming language empowering the masses of engineers (and not just "programmers") wanting to build efficient and robust sfotware.
What crypto library should we use? ring, RustCrypto, rust-crypto (don't use it!), boring, aws-lc-s or openssl?
Which HTTP framework? actix-web, axum, dropshot or hyper?
What about a time library? time, chrono or jiff (how I'm even supposed to find this one)?
You get it, if you are not constantly following the latest news, your code is already technical debt before it's even written. Fragmentation is exhausting.
I just looked at the dependencies of a medium-sized project I'm working on, and we have 5+ (!) different crpyto libraries: 2 different versions of ring, aws-lc-rs, boring, and various libraries from RustCrypto. All of this because our various dependencies have picked a different one for their own cryptographic usage. This is insane, first because it introduces a lot of supply chain attack entry points, but also because there is no way that we will audit all of them"
My moderate-sized Rust web service project requires 587 third-party crates which seems ridiculous.
Fortunately, cargo makes it easy to manage the dependencies, but unfortunately I don't know how well supported or maintained the dependencies are. How well will they be maintained in five years from now? Will I need to find newer libraries and rewrite portions of my project to provide the same features that I have now? I don't know.
I'm a bit lost on how the bitcoin supply isn't in the hands of the rich. Do they give out free mining equipment and electricity to the poor to equalize things?
I don't agree with GP that naysayers might be "rabid" but I certainly know someone who was bitten by a bat(coin). "Rabid" is bang-on for at least some people.
It's relevant and non-hypocritical. It may not be the best comment, but neither was yours.
A game engine will tell the OS to start up the discrete GPU if it is available. This is why I asked the original question. Is there some way to turn that off?
When initializing a GPU context you can specify whether you want the most efficient device, the fastest device, etc, for a GUI app then you would want to pick the most efficient, which is a single flag to pass in, or supply options and let the user pick which one they want.
The author doesn't give the impression that they understand what they're reading.
> But she gives the game away when she writes: “Maybe my relationship with dreaming wasn’t like everyone else’s.” Not like everyone else’s, no. But certainly like that of many people who suffer from recurring and terrifying nightmares.
Obviously, she's talking about the fact that she discovered that there were some people who didn't have her kind of nightmare issues. Realizations that your invisible traits aren't shared by everyone is a fairly common experience.
Yet, this is twisted so that the absurd criticism that, while writing her book after she found out that the condition is shared with enough people to be given a name, she just doesn't realize that there are some people who share her condition. Good thing the author pointed that out to her, I guess.
> Eloise writes that, according to the Mayo Clinic, nightmare disorder “only affects around 4-5% of adults, which shocked me: did adults really not have nightmares?” It’s as if she genuinely does not know the difference between 4% and zero.
She literally just got finished mentioning the 4%, which is why it should be obvious that she's talking about her realization that some adults exist that didn't suffer that condition rather than a statement about literally all other adults.
And the last sentence there gives the game away: she obviously realizes the difference and literally just mentioned it, and so she must have meant something else.
I'm not sure that's down to Venezuela's power companies. That's right about when the US was trying to coup their government, right? Stuxnet's origin story can tell us a bit about what kinds of sabotage they pull.
>The volunteers recognised cloned speech as such only half the time (ie, no better than chance).
That's incorrect. It's like saying that one lottery ticket has a 50% chance of winning. If they're fooling people half the time, that's way better than chance, since there are so many ways of screwing things up.
I think they are saying the volunteers performed no better than chance, i.e., volunteers are no better at guessing real vs. clone compared to randomly guessing. It's a really good outcome for the clone.
