The React devs fucked up by not wrapping state in trackable containers, and we’re all paying the price with laggy apps.

You’re acting like you’ve never accidentally reduced a soup far enough that you almost burned it.

There are dozens of cases, every year!

The editorconfig rules you’re referencing can turn code analyzer warnings into errors, but you still need a code analyzer to actually trigger the error.

https://www.jetbrains.com/help/resharper/Reference__Code_Annotation_Attributes.html#MustDisposeResourceAttribute

This one, I’m guessing? At least that’s the one I know.

For specific individuals who personally alienated us, yeah, sure. But if you generalize and broadly accuse all tech bros, there will be people who think you’re targeting them, even though they’ve never actively alienated us.

Let’s not let ourselves be divided unnecessarily.

You have to understand that on some days, even leaving the house or writing a message is impossible. I don’t think it’s possible to understand the impossibility until you’ve gone through the same.

And all that while they’re off the air? Oh, duh, time travel.

Oh, I had no idea! Thanks, that’s great to know!

Codeberg only targets a subset of projects. For example, I no longer want most of my self-written code to be publicly available, but Codeberg only supports public repos.

The Bible says it’s okay as long as you don’t fuck your buddy in the pussy

I’m not sure I agree. The real world is never going to run perfectly, so some slack must be included (either by adding buffer time to schedules, or using the way you mention). Of course there are examples like Japan that have done a really good job at optimizing these systems, but you won’t be able to successfully apply their approach to every country. Some locations require more work to achieve this, others require less.

Generally the closer you get to an “ideal” performance, the more costly every further improvement gets. If 7 min isn’t reasonable, what number would be? Say we manage to shave off two minutes, at twice the cost of the current system. Is that really worth it?

The better approach is to include reasonable slack time in people’s train schedules, while increasing frequencies so missing a connection doesn’t result in hour-long wait times.

Aw. I hope they at least feel really swole, so they get something out of it

I’ll have you know that Reacher cannot help his overactive steroid gland!

It’s also not the old people. Sure, the rich are old people, but that doesn’t mean old people are rich.

You gotta understand - making workers obsolete is the owning class’s greatest desire. They can’t wait to get rid of us. So when any chance might come up, they’ll try everything to make it work, no matter the cost for everyone else.

As a passionate Golang hater, I can gladly explain!

• It’s not just the repeated if err != nil, even though that’s already bad enough. But the really fucked up part is the := bullshit. It makes moving code around unnecessarily annoying, and it’s telling that few other languages share Golang’s approach.
• The lowercase/uppercase rules for private/public stuff is theoretically not a horrible idea, but it makes the code look much more inconsistent. I find _ much easier to read, and this leaves upper/lower to signal other details. But I see that this is mostly personal preference.
• Fairly basic operations take much, much more code than they should (e.g. deserializing JSON while handling extra args, or basic functional operations - though that should change sooner rather than later with the new generic methods, right?)
• The decision to initialize every non-pointer primitive with the “bottom value” (or whatever it’s called again) makes sense in isolation, but it’s really unfortunate that they don’t support additive types, because this means a bunch of common tasks need to use pointers, and unfortunately the type system is worthless when it comes to preventing segfaults caused by bugs with pointers.
• I find that most Go libraries have basically no documentation, if you’re lucky you get an example that might vaguely be related to whatever you want to know. I’ve had much better experiences in other languages.

All in all IMO most Go code is 5x longer than necessary to actually express itself in a readable manner, all because the language still doesn’t have proper error handling or generic support (until recently at least). At the same time it’s fairly inflexible, the type system is still shallow and basic, and it’s still way too easy to shoot yourself in the foot.

The only good thing Go has going is the single file deployments, but I’ll gladly spend one hour of every remaining day of my life setting up containers, if it means I never have to touch anything Go again.