TehPers @ TehPers @beehaw.org

Posts

0

Comments

688

Joined

2 yr. ago

I rarely do, but when I do it's for something a bit specific, like ordering/depositing foreign currency (for travel) or depositing large checks that exceed the online deposit limit (which again is extremely rare). For everything else, it's online only, especially since every time I go in, there's only one teller working and the line is super long.

I can't afford to buy a new car. Public transportation in the US basically doesn't exist, and riding a bike is a death sentence here. Buy me an EV and I'll gladly drive it though :)

Edit: Also, I'd have nowhere to plug in the vehicle charger since I don't have a garage where I live :/

Lets say we have a spaceship game.

Some facts about our game's code:

• All of our spaceships live in a central list.
• We also need to have a separate cache for displaying them.
• Every ship needs to be in both the central list and the display cache.
• When the ship dies, we need to remove it from both the central list and the display cache.

If we forget to remove it from the display cache, we'd get an odd bug when displaying.

Let's use single ownership to prevent this bug at compile-time. No mainstream language prevents this kind of bug, but we're about to do it easily!

The idea of using single-ownership to track "reminder" objects is actually really cool, and a variation of it sees use in other languages too. Traditionally, RAII is used for resource acquisition and freeing (as the name implies) in the context of heap-allocated pointers, so smart pointers for example. However, it can also be used for things like mutexes to automatically free up a mutex when some kind of "guard" object is dropped (both Rust and C++ support this, and Rust even enforces it). It's not the same as a "reminder" object, but instead of having the compiler tell you "you forgot to free the mutex", you instead automatically get the mutex freed so you don't need to explicitly do it anymore.

The article would be right that languages don't traditionally enable some kind of "reminder" object in the sense that you can't compile the code without first doing X with that object. However, from my experience, the RAII approach means you don't need those reminder objects anyway since the action that you're supposed to take when you're done with some resource can be done automatically in these languages.

Here's an example in Rust translating the ship/display cache example in the article to something that takes advantage of these "guards" to automatically notify the display cache when the ship is dropped. You'll notice that in the main function, nowhere do I need to explicitly tell the display cache "hey this ship was destroyed". Instead, the cache automatically knows and updates its state when the ships() method is called to get the list of ships in the cache. I believe something similar to this can be done in C++. C# would allow you to use IDisposable and .Dispose() to achieve something similar too, although it wouldn't be an automatic process like in Rust and C++.

Not if JS creates the input in the first place :)

I can't say my experience playing PC games comes even close to that.

1. My PC is already on - it's a multipurpose machine, so I was already using it for something else.
2. Steam opens on startup, no need to open it.
3. Steam auto-updates the game in the background. No need to wait.
4. I don't think I've ever needed to update a driver to play a game. Also, regularly updating most drivers is actually not recommended, and you should only really be updating them if something's broken. Graphics card drivers you might want to update now and then, but even then it's rare that a graphics card driver makes a game suddenly playable. This seems comparable to firmware updates for consoles, although the last two consoles I used were a Switch and I think a PS3 so my memory's a bit hazy there.
5. Yes, third party launchers are obnoxious. It still only takes maybe 10 seconds at most to get most games opened though, from my experience. Not all games use third party launchers either, but sadly a lot of the bigger games do.
6. Being able to continue easily where you left off does seem like a benefit consoles have. It'd be interesting to see that on PC, although I have yet to find a need for it since you can save practically anywhere in most games anyway, with the exception of cutscenes and tutorials I guess.

It takes me maybe 10-20 seconds to get most games that I play open on my machine, excluding the obnoxious splash screens games have when you open them which is the reason I think #6 might be a compelling argument. With the splash screens, it's easily 2-3 minutes because more than half of that is sitting there staring at some stupid brand logos.

Of course, I already have a PC for other reasons, and the PC's hardware is more than capable of playing games (moreso than most consumer gaming consoles at least, if not all), so I've never really felt like there was much reason to get a console, with the exception of a Switch since it's a handheld. There's already an enormous catalogue of games to play on PC, so it's not like I'm missing out on much. Also, I might be a bit unique in that I'm using my PC all the time anyway. For someone who doesn't use a PC very much, I could see a console being more appealing due to it being a dedicated gaming device.

I thought I read in one of their feedback threads that Kagi doesn't use Bing anymorel, but I could be wrong.

MTG Arena - there's a regular play queue and a ranked queue, and people definitely play to mess around and try new decks for fun. This of course doesn't cease to induce salt from sweaty gamers in the play queue.

Even ignoring games that you consider "in the gray area," who are you to say someone can't find a way to have fun in a game that doesn't align with your way of having fun? Not everyone is playing the game hoping to land on an esports team.

Edit: I'm mostly referring to casual queues - ranked queues being hyper competitive does make sense. I've just seen the same argument made that casual queues should be the same level of competitive.

Regardless of how untrustworthy Meta as a company is, it also tends to hold the kinds of "mainstream" social media platforms that I have actively been avoiding for many reasons, including their communities. Beehaw has already defederated from other instances for having open sign-up and a disproportionately large number of users on them who needed moderation actions taken, and I can see a Meta-run instance posing the same kinds of problems.

Plus, like others said, it's not impossible to federate later if it ends up being an overreaction. It's just that Meta and its userbase already exist, so it's possible to make pre-emptive judgement with that knowledge and correct the judgement later, potentially avoiding a flood of unwanted content.

There are a few resources out there, but a good starting place is the book. There's also Rust by example which has example snippets for doing various tasks.

Also, keep in mind that Rust is a very different language from C, C++, and Python. It's going to be hard to learn it if you try to treat the higher level concepts (structs, enums, traits, etc) like how other languages you know work. Take your time, it takes most people a lot longer to learn Rust than to learn most other traditional languages.