I don't really know myself, probably the many footguns and complexities. Like taking a reference to a value in a vector and then resizing the vector, boom undefined behaviour. There a re a lot of things like this. Maybe also the verbosity and multie ways to do things. Look at the linked code, there is a lot of overhead to the function definitions, sure there is a point to all of it and I put it there for a reason, but to people less familiar to the language it is probably quite offputting.

Personally I like the language, second only to rust for me

Just replies to this two-comment-long chain where we're now talking about elephants. Did you know that it's theorised they're the largest surviving land animal mainly because they're the only large land animal that co-evolved with humans, so had appropriate fear and awareness to avoid being hunted to extinction, whereas other similarly-sized creatures wouldn't see humans as a threat, so would be vulnerable.

There are lots of ways to write C++ code that looks perfectly reasonable but introduces horrible undefined behaviour. You need to be aware of lots of edge cases all the time and you will still make mistakes that can introduce difficult to trace bugs. One of my personal favourites is object slicing.

class A {
   int foo;
};

class B : public A {
   int bar;
};

B b;
A a = b;

Looks OK? Well, a now only contains the A part of the object. The field bar is lost in the assignment. There are reasons for this behaviour but its a sharp edge nonetheless.

These kinds of problems are numerous and you have to keep them in mind while programming C++. Some people don't mind it but many do. Static analysis tools that can catch many of these errors exist, but I understand people who say they don't want to deal with that and rather use a language where these kind of errors are not possible. Personally, I would also discourage people from starting new C++ projects today if they can avoid it.

This is the type of shit that haunts me. Imagine overloading ">>" for piping and hiding threading behind that. The idea was to create an async pipe, but nowhere are you aware of async or threading or whatever was chosen. You look at the code and think "of it's like piping to stdout" or whatever, only to find out that the method immediately returns.

Tracking down what the hell is happening with code that has such hidden side effects is a nightmare.

Are you still in the C++ world?

Weird opinion: I like square brackets, angle brackets are neat, curly braces range from neat to ok.

But I just don't like the look of parentheses compared to the others. They especially look ugly and clunky when you need a bunch of them in a row, in a way that's not true for the others.

I can't think of a reason why I feel this way apart from the fact they tend to be very clunky in math too. They're also the ugliest one when handwritten despite being the arguably simplest shape.

All that said it annoys me how parentheses are the most used bracket type in programming.

I'll pass on the AI review. I'll QA my work myself, thanks.

IT'S FUCKING MEEEEE

If you tell Claude to commit for you it adds it then

Which highlights another situation of people telling it to let them handle the committing

How does Claude attribution appear in the first place? I've written code with it before and it never shows up in GitHub.

I'm seeing Claude as a contributor all the time in random repos, but like, how does that even happen? In my experience with "agentic" coding, the agent does not get credit for commits, even if all diffs were made by them. What kind of workflows do people have for Claude to credit itself in a commit?

I definitely do. But yeah a lot of people on GH are worried about employability and a big part of that is showing you're down with big corpo tech.

I prefer Java style:

entity.position = entity.position.add(entity.velocity.scale(dt));

Not hard to read.

That's a lot, so I'll be forthright that I'll probably be giving a relatively terse and gappy response, but that's more because of my own limitations as a mobile user.

Fundamentally every test unit, integration, ui, manual is still the same thing:

Given X do Y expect Z.

Mocks, fakes, whatever you want to call them, they're fundamentally the same concept too: "given some idealized version of P"

All you've done is pushed where that line sits. If I update my company writer to prospend all my company names with "corp.", and my company read API test seeds without it and something at your read service layer strips ".", if I forget to update the "given" in my read test seed data, that bug stays invisible.

It's the same class of issue. We just kicked the can down the road.

You could do writes and reads in the same test, but even then you're still kicking the can down the road that your front end is calling the API correctly at all. Maybe that the buttons even render to an end user given their authority.

One might then conclude, then, that everything should be an automated UI test.

But would it catch a bug where the bottom collapsed to 1PX? Is that part of the test too? Maybe manual testing is the real way to go.

A further step back why do we even test anything at all? To provide some ultimate guarantee that everything works perfectly at all times? Is that the gate for a PR? A deployment to prod?

There are various gates, at different levels of certainty, and there is an economic scaling for the different levels of assurances. AND they scale with the overall complexity of the system.

And that isn't a bug, that's a feature.

It's ALL behavioral contracts, up and down the pyramid.

There is a bang, there is a buck. Get the most bang for your buck. The distribution will vary by complexity and structure of your project.

That being said, I've said it before and I'll say it again: int and UI tests make it very very easy to write fucking garbage code, the VALUABLE architectural pushbacks on poorly patterned code that unit tests avail is AT LEAST as much value to the overall tech debt accumulation of a project as the results themselves.

Please don't read this as me shitting on int tests. It's me trying to impress that unit tests are worth writing, and justifications for forgoing them usually are fundamentally driven by an underlying code smell. Sometimes the smell is "our architecture is already so fucked that writing a meaningful unit test would involve re architecting large swathes of our system".

And in that case I'd say "it is what it is", recalibrate the testing posture towards int tests, and accept that is the reality.

But I would NOT conclude on the blanket statement that unit tests SHOULDN'T be at the bottom of the testing period generally. Just that I'd inherited or failed to maintain a strong system design, and take the opportunity to reflect on how things came to that state for the purposes of becoming wiser.

Addendum:

Even int tests can reveal insane system architecture, just at a different layer and scale. I worked on a system at a fortune 500 company where the architecture was too far gone to even have meaningful integration tests. They were too far gone to even have automated front end tests. All material testing had to be done by hand. They had engineered their system with that staggering level of incompetetence. At the risk of making a slippery slope argument... It's a slippery slope.

Clearly you’ve never had to read code like

entity.position = vector_algebra::vector2_add(entity.position, vector_algebra::vector2_scale(entity.velocity, dt));

I asked the other day in another thread about hating on C++ what makes C++ so bad and never got an answer.

When I was an intern, I was tasked with writing a file converter for 3D geometry files. There was an official cpp library to read the source files, so I was using that to read the data, restructure and transform it as needed, then write it to the output file format. Near the end, I was having a problem where I was SURE that my math was correct for the transform coordinates, but the resulting file would load in the viewer with all the correct looking pieces but all in the wrong locations. The senior guy there helped me debug it since I wasn't super familiar with cpp at the time, and we found that the library I was using had overloaded the multiply (*) operator specifically for the objects I was using it on, and it was actually multiplying and saving the result directly to the first variable used in the multiplication. I assume it was done for memory efficiency or something, but I had no idea it would behave that way, so I was accidentally changing the values of variables I didn't intend to.

Example: I was doing something a = b * c, which caused the value of b to be changed (to b * c). Which screwed things up when I needed the original value of b later.

It is with great pride that I can say that a GCP-HPC pure-bash application I've been working is completely AI free.

For the interested, it's something I was working on while bored at work has been blessed as good use of time for the benefit of our dry lab. I'm hoping to be allowed to open source it. It's basically a git-like interface between GCP head nodes and GCP buckets

All it takes to remove Claude attribution is something like this

git filter-branch -f --msg-filter 'sed "/Claude/d"'

That's before realising things like DeepSeek don't add the trailer

Be pleased that people are generally not trying to hide it, but also don't trust its absence, look at the commit patterns

It's such a nice treat when I don't see it on a new project, especially on Microsoft's GitHub.

You are insane. Elephants. There. Now the entire thread is about elephants. Get the fuck out of here.

This conversation has been about people who fork software to continue working on it without bigoted leaders in charge, in what way is that not using the software?

Thanks. I haven't tried that yet and am interested, so maybe this'll be a good experiment.

Once you're replying to me, someone who's said their sure Earthwormjim's comment was specifically referring to a specific kernel patch, you're in a conversation about that specific kernel patch, whether or not I'm right about that original comment being about that specific kernel patch.