I have a modern one with a mouse-event bug specific to Wayland, that still presents in XWayland windows. Switched to KDE/X11 just to work around it (so, not exactly enthused to see this news item on HN).
Nope. Off the top of my head, I've had serious issues (crashing, visual glitching, extreme lag, etc) running OpenMW and Minecraft on XWayland, both of which were resolved entirely by switching to X11. There have been many others too, those are just at the front of my mind because they were the most recent.
Oh, also Godot has a lot of issues on Wayland at the moment, specifically the Godot editor. I spent a long time trying to figure those out, because if I'm developing I would really rather be in a Wayland session where my DPI stuff works much better, but ultimately I resigned to just running the Godot editor only under an X11 session.
Since the thread mentions Rust: in Rust, you often replace Mutexes with channels.
In your case, you could have a channel where the Receiver is the only part of the code that transfers anything. It'd receive a message Transfer { from: Account, to: Account, amount: Amount } and do the required work. Any other threads would therefore only have copies of the Sender handle. Concurrent sends would be serialized through the queue's buffering.
I'm not suggesting this is an ideal way of doing it
What you're describing is called the "Actor model"; in your example, the receiver is an actor that has exclusive control over all bank accounts.
The actor model reaches its limits as soon as you need transactions involving two or more actors (for example, if you need to atomically operate on both the customers actor and the bank accounts actor). Then you can either pull all involved concerns into a single actor, effectively giving up on concurrency, or you can implement a locking protocol on top of the actor messages, which is just mutexes with extra steps.
Hikaru accused Luis Paulo Supi of cheating at least twice.
From his Wikipedia article:
```
In an online blitz tournament hosted by the Internet Chess Club in May 2015, American Grandmaster Hikaru Nakamura accused Supi of cheating (Supi had defeated Nakamura).[2] The tournament judges accepted Nakamura's accusation, reverted the match's result, and banned Supi from the tournament. Brazilian Grandmaster Rafael Leitão wrote in his personal website, "Accusing him of using an engine in this match is absurd. The match is full of tactical mistakes. Nakamura played extremely poorly and, honestly, wouldn't have survived long against any engine given his terrible opening.".
```
Some years later Nakamura lost 4-0 and again insinuated that GM Supi used an engine.
Despite all that, Nakamura still published a video calling him a "legend" for once beating Magnus in 18 moves
> The attitude of Rust being bug-free is _insaaaane_.
Funny, because that's not anywhere close to what the comment you're replying to states.
They said `"Safety" is just a shorthand for "my program means what I say"`. That's a reasonable explanation: the code you wrote is not working exactly as you intended, due to some sort of unknown behavior.
The "bug" you're talking about would be the program doing exactly what you implemented, but what you implemented is wrong. The difference is so obvious that it's hard to think that you're engaging in a good faith argument.
I find that Employers of Record (EoR) make this a non-issue.
I work for an American startup, remotely from S. America. I'm hired according to the (extensive, and expensive) local labor laws, while my startup likely knows absolutely nothing about the intricacies of how my countries' labor laws work, the EoR just handles everything and sends the employer a bill every month.
