try_lock
already exists; it’s called lock
. I just want a more convenient name and I want the name of the new method to be lock
, but that ship has sailed.
try_lock
already exists; it’s called lock
. I just want a more convenient name and I want the name of the new method to be lock
, but that ship has sailed.
Looks like the author missed my main complaint about Rust mutexes, which is that the lock
method returns a Result
. There should be a try_unlock
method for when someone actually wants to handle the rather obscure failure case, and the name lock
should be used for a method that panics on failure but returns a value that doesn’t need to be unwrapped first. I see the current arrangement as being about as sensible as having array subscripting return a Result
to handle the case of a failed bounds check.
Chrome and Chromium are 99.9% the same. Source: I used to be a Chrome developer at Google.
It does have to be free. It’s open source software. If they tried to charge money for Chrome, people would just use Chromium or one of the other browsers based on it.
I’ve been using it for the last few months, and while it doesn’t offer as many “nice to have” features as Google (like automatically finding mask results need in where you are), the core functionality works great, and the lack of ads is refreshing.
Chrome doesn’t make any money. How is it supposed to support itself as a separate company?
There’s nothing wrong with using dyn
if the problem calls for it. In most cases it’s more idiomatic to use an enum to represent something like a strategy, but if your strategies are complicated entities in themselves, a trait is probably the right approach.
And yet you can still buy phones with headphone jacks. Because there is demand for them. The reason you didn’t see many is because the demand is a lot less than what Lemmy users would have you believe.
I found 8 brands of DVD±R discs—none of them Sony—before I stopped counting. If you think one company stopping production is going to stop people from using physical media, or that demand hasn’t been falling for years, YOU are the one who’s badly out of touch.
Let me spell it out for you: as long as there is demand, someone will find a way to make money filling it. No company, no matter how evil it is, can remove a product category from the market just by leaving the market. Suggesting that a company choosing to stop making a commodity product is an attempt to prevent you from having access to said product is nonsense no matter what company and product you’re talking about, because such a plan could never work.
Or… they’re stopping production because there’s very little demand. Nah, that can’t be it.
Damn, that’s some Qanon-level shit.
I think it means something similar to YOLO.
Seems to me it’s mostly complaining about Google.
But the one in your pocket is fine?
Same general idea, yeah.
Look up a brand called Tenga.
I can’t take anyone who says “commie” seriously. It’s like hearing an adult say they need to go potty.
Millennials are killing the 737 Max industry!
Tell me you’ve never used a filing cabinet…
I think a better solution would be to add a method called something like ulock that does a combined lock and unwrap.
My concern with lock+unwrap is only partly because of convenience; I also didn’t like it because I think it’s a bad idea to get people used to casually calling unwrap, because it tends to hide inadequate error handing.
Now that I think about it, I don’t like how unwrap can signal either “I know this can’t fail”, “the possible error states are too rare to care about” or “I can’t be bothered with real error handing right now”. In one or two of those cases you want to leave it in my production code, and in the last you want to audit all instances and replace them with proper error handing. Using the same function for all three cases makes that difficult.