This shape certainly beats a triangle (...)

Nature loves triangles.

https://en.wikipedia.org/wiki/Michell_structures

Why do you think test times are proportional to coverage rates?

appears to be a weak patch.

It's not a patch. It's eliminating an attack vector, and the one which is more pervasive and easier to exploit.

Security-minded people pay far more attention to what software you run than what hardware you have.

how centeralised GitHub

It's a pointless and irrelevant remark. Mozilla uses Git to track work on Firefox. GitHub provides Git repositories. I can clone Firefox out of GitHub, create an account on GitLab/Bitbucket, push the code there, and GitHub does not feature as a concern at all.

What point can you possibly think you're able to make regarding GitHub?

GitHub is enshittifying everything that has to do with Git.

Nonsense. Speaking as someone who actually hosts the same projects on GitHub and other version control providers, GitHub does not even feature as an implementation detail.

I'm starting to think you're just trolling.

You should care.

I do my best to not waste my time with irrelevant nonsense. It's silly to believe that the version control system you use has any influence on the quality of the software you deliver.

I would expect more negativity than average because ‘actually useful’ is relative and frankly, I cant be bothered to make my case.

Perhaps it's just me, but the way I interpret the "actually useful" is that the goal is to showcase practical uses of some AI implementation showcasing how it's used to solve real world problems.

This is fundamentally different than all the "solution in search for a problem" announcements which ride the AI buzzword, which boil down to handwaving over their practical relevance.

What features do you use often And what features are not that useful in an IDE and can be considered bloat?

Being able to build projects and debug them is a given. Why would anyone use an IDE that did not supported building or running a project?

Developers spend most/practically all their time navigating through a project. Therefore, features such as opening files, searching for symbols, going to definitions, navigating back to points you were in, end up being the ones everyone uses the most. Also, code bookmarks are also of critical importance to work on specific tasks.

Support for refactoring primitives is also of critical importance. It's extremely convenient to extract/inline functions, rename symbols across the whole project, automatically generate code such as classes and their unit tests, etc. Nowadays, if an IDE does not support basic refactoring features such as extract/inline function/variable then I'd argue that it's not worth bothering with.

Finally, source code formatting. It's surprising the impact on team dynamics and productivity that we get by having an entire team on the same page with regards to where a space is expected to show and not show up.

I'm sure that there are plenty of spectacular features that should be must-haves but I'm oblivious to. Not using them doesn't mean they are bloat.

I think that it’s because a) the abstraction does solve a problem, and b) the idealized solutions aren’t actually all that simple.

I'd go a step further and state quite bluntly that these critics do not even understand the problem that the abstraction solves, and their belief is formed based on their poor and limited understanding of the problem space.

Everyone can come up with simpler alternatives if they throw most requirements out of the window. That's basically the ages old problem caused by major rewrites and their expected failure once the unknowns start to emerge.

But I still agree with the article because I also think that a) the problem solved by the added abstraction isn’t practical, but emotional, and b) the idealized solutions aren’t all that complex, either.

Hard disagree.

There is not a single technical argument refuting these abstraction layers; only ignorance of the problems they solve. It's easy to come up with simpler solutions if you leave out whole sets of hard requirements.

The idealized solution never leaves the conceptual stage because the idealized solution is never thought all the way through and the key requirements are never gathered. That's when the problems solved by the abstraction layers rear their head, and what forces these critics to face the fact that their proposed solution is inconveniently converging to the real world solution they are complaining about, but that they are reinventing the wheel poorly.

Some Java version older than 8

Did not expect that 2 decades of developer experience in Java EE would amount to nothing, for the people who implemented Jakarta.

I'd love to hear more about specifics.

Something in the dependency tree will yell at you that it is deprecated or discontinued.

Only if you didn't pinned the dependencies you actually consume, and expect that all your dependencies magically comply with semver.

Blindly replacing dependency versions never worked, at least reliably. If you do not put in the work to ensure things work, more often than not you'll be surprised by them not working.

Your format looks half baked and not thought all he way through. Take for instance the success bool. What info does this add that error_code and the request's own status code doesn't already send? And what's the point of context if it is both unspecified and optional?