• 0 Posts
  • 304 Comments
Joined 3 years ago
cake
Cake day: September 2nd, 2023

help-circle



  • That’s just someone that doesn’t know why people say things, so just made it up.

    Enums outside of rust are indeed bad (I would correct it to enums in every language I know that is not rust, since maybe some other do the same thing as rust). But it’s not because the tagged union thing.

    The problem of enums in other languages is that they do not make for a distinct type. They are just integers in a name. Or at least that is the case for C and Java enums. Python and JavaScript do not even have enums, which is even worse.

    When enums are just integers, you don’t know if a variable of the type of the enum is actually one of the variants of the enum. If you assume that, you can easily get into undefined behavior/crash territory quite fast.

    When making a library in C, for example, if one of your functions has an enum as a parameter, one of the first things you have to do is check if that parameter is actually in the range of the enum. Since you don’t control the caller to your function. These checks don’t belong in code at runtime, they belong to compile time, as you’re just validating the type of a variable.

    In rust, switch/match statements need to cover every single enum variant (of course, you can also have default paths to not cover every case) your code just won’t compile if you don’t. Which means that when you add a new variant to an old enum, you don’t have to go hunting every match statement to see if it affects your new change. That is a tedious and error-prone task if done manually, while it is pretty simple for the compiler.

    Of course, now that these differences are established, the tagged union thing comes in and makes rust ones better. The reason other language enums are bad is because they’re named integers, the reason rust’s are good is because they are tagged unions, completing the algebraic type system.


  • I see the benefit. For example if I have to keep a window open just so it is open. But I don’t need to look at it. For example when opening a VM that I’m going to access via SSH.

    In that case it’s useful so it is open but nowhere to be seen.

    On the other hand, setting up the thing, and later remembering that I have it in case I want to manually close it is a hassle. So it’s just easier to not use the workspaces and just have it minimized. It’s going to be on the far side of the alt-tab queue anyway.















  • I don’t think the chances are that remote.

    Microsoft values backwards compatibility a lot. At least in windows. So from a technical viewpoint, the older Xbox games are probably already compatible with the newest Xbox. If that is the case, technically it would be as easy as removing the arbitrary check that the Xbox version matches. Maybe add a frame rate limiter so old games that calculated time for physics based on frame rate don’t break.

    From a business perspective, Microsoft does not sell as many remakes/remasters as other companies (like Nintendo, that just sells you an old game+emulator for absurd prices).

    In fact, with gamepass, Microsoft states that it doesn’t want to sell you games. It just wants you to spend as much time in Xbox/WinPC paying their subscriptions.

    Allowing old games will mean bringing them to gampass too. Which is what they want. They want as many games in gamepass as possible.