hascat
joined 2 years ago
Sometimes it's easier to try a new idea in a new language (e.g. the borrow checker in Rust) rather than trying to shoehorn it into an existing language.
Same here! Testing up front has made it extremely rare that I have to go back with a debugger later.
Diablo 4 retails for $70. If you spent less than that on PoE, I'd say you're getting a good deal.
why do you have to pay extra to play online in 2023, anyways?
The one-time cost of a game isn't going to cover the ongoing costs of hosting the servers hosting the game.
There's an amazing amount of conversation about how this person is supposedly a racist with no evidence to support it. Am I missing something?
I like this, but I'd drop the special election in favor of disqualifying candidates who would age out during their term.
Change your email provider? Run your own email like people should?
This isn't a practical suggestion for the vast majority of the population.
Others note the land and water use issue vut it seems there are a lot of other crops that would be bigger targets on those fronts.
It's very likely other teams are working on other crops, and this just happens to be a high profile early success.
... it would sync overwriting the currently deployed version in qa. I obviously don’t want this.
Then don't allow the deployed software to be overwritten while tests are running? Your test environment should be treated as a singleton. Your CI system shouldn't be able to affect the deployment while it's being used.
I prefer to put return types on their own line:
MyReturnType
doTheThing(int arg1, float arg2);
This keeps function names aligned vertically, which I find helps with readability. It also gives long return types an entire line to work with.
While I do like using auto inside function definitions, I don't like it for return types because it hurts readability. Having the explicit type available to the reader reduces cognitive load. I use trailing return types on non-trivial lambda functions for this same reason.