Even C++11 is pretty old. I would recommend at least C++17

If anyone is starting to learn C++, make sure to use books or training materials based on C++11 or later.

Of C? No

Of C++? Yes

So you're saying the jank has become structural?

Gzip (any properly configured static server will serve compressed assets) probably compresses them down so probably a single extra byte per file

No, the C++ should fear you!

But if every single comparison used in a file is a triple =, then any compression algo worth its weight in salt will compress that bloat away during transmission

The real issue is all the precious precious RAM those extra = use on the client device once received and unpacked!

Where's the >== operator? Because they also have the exact same problem.

I wonder how much bandwidth is wasted on the extra =, since it survives minification 😅

For those needing help the code is:

using namespace std;
int main()
{
while (true)
{
cout << 'e';
cerr << 'e';
}
return 'e';
}

Anyway, my opinion: c is the best thing to ever exist, and c++ is evil

IIRC modern linter rulesets generally just outright error if you do anything remotely like this.

The recommended ESLint rules catch most of the bad stuff, and these days this is all you need in your ESLint config to enable them:

import {defineConfig} from 'eslint/config';
import js from '@eslint/js' 

export default defineConfig([
  js.configs.recommended,
]; 

There's one use case where == is still commonly used: == null matches both null and undefined. Lint rules that block == usually allows the null case as an exception.

This diagram is nonsense. JavaScript programmers know to simply never use == but to use === instead. Half of JavaScript is like this. Oh, there's a feature, but it behaves in a super weird way so we don't use it to avoid the weirdness.

Less fucked-up than Javascript.

No

So yes

No. I don't find it a particularly nice language to work with, but there's no reason to fear it. Just make sure you know what you're doing if/when you use it.

Now I definitely know you haven’t seen a real professional codebase.

Extremely wrong. So much for your assumptions.

Professional git repos are full of one sentence commit messages with little to no explanation of what’s in the change set.

Yes, humans can communicate poorly, of course. But people letting the LLMs do it do not understand what is in the change, and the LLM certainly doesn't. There's no one at all to ask because no one understands what was changed or why.

I'll take “sometimes lazy but they wrote it and their understanding of it can be interrogated”, all week.

Any critical security vulnerabilities will be the fault of Google. This app is a glorified filepusher manipulating bash strings into standard path structures for google buckets.

Edit: to describe more precisely, it's a bunch of bash functions that manipulate a bash string for the commands gcloud storage ls and gcloud storage cp. It has some useful functionality beyond that, such as tracking projects and project versions for collaborative purposes, but this is a mask on top of existing commands.

I used to put messages into my commits “if anyone reads this and messages me, I will give you $5”

Only one has ever been noticed by a coworker and that was like 5+ years after I made the commit

It’s a setting in Claude code, you are able to disable the trailer automatically

That's fine. It is probably worth noting human written code that has been reviewed by 1000s of humans are having valid critical bugs found in them by AI. No one is forcing you to use it but humans aren't magically perfect just because you don't like AI.

Now I definitely know you haven't seen a real professional codebase. Professional git repos are full of one sentence commit messages with little to no explanation of what's in the change set.

Humans suck at communication, especially when there's pressure to get product features out the door. AI driven repos are full of beautifully summarized commits with clear explanations of architectural choices, change motivation, etc.

Working professionals are, if at all competent to be committing code to a professional code base, entirely capable of writing their own commit messages.

If they can't write the commit message, they can't sufficiently explain in writing the commit they just made to anyone. So, they should not be working professionally on a code base.

If they are capable of writing the commit message with their own understanding in their own words, but they choose not to communicate their understanding in the commit message? Also disqualifying, they should not be working professionally on a code base. Human communication is essential to this work.

That this is a controversial position, is a clear sign of the Slopocalypse.