Then use C or C++ if you really need performance.

And that’s where I stopped. I’m a real working programmer who’s done tons of work in C++, so I know firsthand that it absolutely sucks compared to Rust. Go back to Typescript if you hate Rust so much.

Ok, but have they fixed the UI scaling on high-DPI displays?

deleted by creator

But think of the illiterate people! /s

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.

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.

The newer version is: https://w3c.github.io/openscreenprotocol/

I used to be on that team at Google and when I left they were working on an open source implementation of it.

Miracast is a separate, older protocol from what Chromecast uses.

🤡

Everything in the video is considered acceptable in open source code today. If it wasn’t, it wouldn’t have been right there in the code for the person making the video to find it.

Oh please. This comment has the same energy as Dave Chappelle doing a whole Netflix special about how he’s been cancelled.

You can get in touch with him eventually, but not for anything urgent. For example, I had to rescue his mom when she lost her car key because she couldn’t get in touch with him to help her.

I know a guy who doesn’t have a phone. Trying to get in touch with him is a PITA.

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.

Not if you want to use both at the same time. Due example, I’ve wanted to have a local Gnome session that I leave signed in, and another session with different settings that I remote into.

To give one example, what if someone wants to have more than one set of options for the same app? That’s something I’ve needed before, and it’s really hard to accomplish if the app always looks in one specific place for its options.