Yeah but if the class changes you need to update everything, you got all that boilerplate taking up space for no real reason, etc...

The Rust way's just a lot cleaner imo.

Ah yes, closed source, such a dealbreaker, as if 99% of the other games weren't.

Don't get me wrong, I have nothing against open source games, it's just not a viable monetization strategy for most projects, and people gotta eat. There's reason why most open source games are either passion projects or old games that have been open sourced simply as an act of kindness towards the community since they generate pretty much no revenue.

I've found working with Rust and Bevy to be quite pleasant. If you're used to working with ECS, I suggest you at least give it a go.
Rust is as functional as C++ 20 with ranges and views is, which is to say it isn't. Not sure where you got that impression from, but while it does borrow some ideas from functional languages, it's still very much a procedural one.

Zig doesn't have headers, nor inheritance. Again, not sure where you got that from, but Zig is basically a modern C, so there's no OOP anywhere, let alone multiple inheritance.

As for what to use, I think they're both viable alternatives. I lean more towards Rust, but that's just due to familiarity. Odin also looks like a viable option, if you don't mind a smaller ecosystem.
If you want a garbage collected language, then I'd go for C#. Despite its historic reputation as a Windows only language, it's been cross platform and open source for roughly a decade at this point. I find it great to work with.

I've found it's mostly two things: readability (ironically) and performance. I'll describe a few crude examples, but I won't get too much into specifics, otherwise I might as well write another book myself.

The performance part is simple: its excessive reliance on polymorphism and the presence of several levels of abstraction just doesn't allow for good code generation. I've seen 10x+ performance improvements by dropping all of the above, with often minimal loss in readability; on the contrary, oftentimes the code became more readable as well.

The readability part is harder to explain; not only because it depends on the codebase and the problem at hand, but also on the coding style each programmer has (though in my opinion, in that particular case it's the programmer's problem, not the codebase's).
I like to think of codebases as puzzles. To understand a codebase, you need to piece together said puzzle. What I've found with Clean Code codebases is that each piece of the puzzle is itself a smaller puzzle to piece together, which isn't ideal.

Functions

They should be small and do one thing

I generally disagree, not because those ideas are wrong, but because they're often too limiting.
What often happens by following those principles is you end up with a slew of tiny functions scattered around your codebase (or a single file), and you are forced to piece together the behaviour they exhibit when called together. Your code loses locality and, much like with CPU cache locality, your brain has to do extra work to retrieve the information it needs every time it needs to jump somewhere else.
It may work for describing what the code does at a high level, but understanding how it works to make meaningful changes will require a lot more work as a result.

Don't repeat yourself

Once again, it makes sense in principle, but in practice it often creates more problems. I agree that having massive chunks of repeated code is bad, no questions about it, but for smaller chunks it may actually be desirable in some circumstances.
By never repeating code, you end up with functions that are over-parameterized to account for all possible uses and combinations that particular code snippet needs to work with. As a result, that code becomes more complex, and the code that calls it does too, because it requires you to know all the right parameters to pass for it to do the right thing.

Exceptions

Exceptions are just bad. They are a separate, hidden control flow that you constantly need to be wary of.
The name itself is a misnomer in my opinion, because they're rarely exceptional: errors are not just common, but an integral part of software development, and they should be treated as such.
Errors as values are much clearer, because they explicitly show that a function may return an error and that it should be handled.

Classes, interfaces and polymorphism

I have lots of gripes with object orientation. Not everything needs to be an object, not everything needs to be polymorphic. There's no need to have a Base64Decoder, much less an IBase64Decoder or an AbstractBase64Decoder. Base64 only works one way, there are no alternative implementations, a function is enough.

I'm a lot more on the data oriented side of the isle than the OO one, but I digress.
Object orientation can be good in certain contexts, but it's not a silver bullet.

Encapsulation for the sake of it

Let's say you have something like this:

class Point {
	public float X, Y;
}

With the Clean Code approach, it magically becomes:

class Point {
	private float x, y;
	
	public float get_x() {
		return this.x;
	}
	public float get_y() {
		return this.y;
	}
	public void set_x(float x) {
		this.x = x;
	}
	public void set_y(float y) {
		this.y = y;
	}
}

Why? Who the hell knows. It makes absolutely no tangible difference, it only makes your code longer and more verbose. Now, if a value needs validation, sure, but oftentimes this is just done regardless and it drives me insane.

Abstract classes for everything!

• "You'll never know when you'll need to add another implementation, right?"
• "You don't need to know the underlying implementation"

The problem with wanting to create the most generalized code in advance is that you end up stuck in abstraction hell.
You may as well not need the ability to have arbitrary implementations, but now you need to plan for that.

Not only that, but it also makes reasoning about your code harder: how many times have you had to step through your code just to figure out what was being executed | just to figure out what particular concrete class was hiding behind an abstract class reference?
I myself, way too many, and there was often no reason for that.

Also, the idea that you shouldn't know about the implementation is crazy to me. Completely encapsulating data and behaviour not only makes you miss out on important optimizations, but often leads to code bloat.

There's more but I'm tired of typing :)

Take a look at these if you want more info or someone else's view on the matter, I wholeheartedly recommend both:

• It's probably time to stop recommending Clean Code
• "Clean" Code, Horrible Performance

You can now review reviews

Gotta pad those CEO bonuses somehow!

I'm of the opinion that Uncle Bob did some massive damage to software development as a whole with that book.
With that said, this is genuinely funny.

Hey there's a word for that! It's called "Child prostitution"!
Doesn't sound quite as reasonable, does it? Not that it ever did.

Then you're practically naked

it's a different kind of cool

People dislike JS because it's packed full of moronic footguns and technical debt. The "standard library" is full of baffling decisions and, much like the language, rarely does what you expect. Even its creator agrees it's a terrible language and should have been replaced by now.

TypeScript is better, but at the end of the day it's just an illusion. Add an any anywhere, which will happen, and you're back to square one. It also still inherits some of the weirdness of JS, because it is just JS with fake types bolted on. Plus, the amount of work one has to do to create a proper library with TypeScript support completely undermines the few advantage of JavaScript. Might as well use a real statically typed language at that point, at least you'd be sure your types are actually enforced.

Also, the whole web ecosystem is ass. The hoops one has to jump through nowadays to do web development are absolutely batshit crazy. And no, having a create-whatever that sets things up for you is not a real solution.

You didn't need to post this.