I’ve run into that exact issue with copilot (deleting my tests). It is infuriating.

I don’t think I’d trust it to refactor code for me, not for anything important. I’d need to completely understand both the initial state and the result on a statement-by-statement level to be confident the result wasn’t secretly garbage and at that point I might as well write everything myself.

if you work in a shared codebase then PLEASE just follow whatever convention they have decided on, for the sake of everyone’s sanity.

That goes without saying; I'm not a barbarian.

“readability” is subjective. much like how there is no objective definition of “clean code”.

Did you not see the part where I said it's less readable "in my opinion"?

i am insisting that people use a common standard regardless of your opinion on it.

I can read this one of two ways: either you're making an assertion about what people are currently doing, or you're telling me/others what to do. In the first case, you're wrong. I've seen many examples of self-closed tags in the open source projects I've contributed to and/or read through. In the second case, IDGAF about your opinion. When I contribute to an existing project I'll do what they do, but if I'm the lead engineer starting a new project I'll do what I think is the most readable unless the team overwhelmingly opposes me, 'standards' be damned, your opinion be damned.

The spec says self-closing is "unnecessary and has no effect of any kind" and "should be used only with caution". That does not constitute a specification nor a standard - it's a recommendation. And I don't find that compelling. I'm not going to be a prima donna. I'm not going to force my opinions on a project I'm contributing to or a team I'm working with, but if I'm the one setting the standards for a project, I'm going to choose the ones that make the most sense to me.

You seem to be implying that applications could be considered basic functions. I can understand that perspective, but an application such as a music player or browser is certainly not a basic function of the OS, and I think it's a stretch to call those a basic function of the desktop environment. Maybe a better word is 'essential'. User applications are not essential to the OS, and the only applications I consider essential to the desktop environment are a terminal and a file browser, though the last one is negotiable. Of course things like the system setting app (or whatever GNOME calls it) are essential, but that's a component of the desktop environment and not a user application. So my list is:

• The kernel
• The init system
• Essential system components and services such as dbus and pipewire without which the OS and/or desktop environment will be degraded or not function.
• A terminal emulator app
• A file manager app

I used GitLab’s version of Copilot when it was free and that was net helpful. It predicted for loops and stuff and was close enough, enough of the time that it was net positive. Not enough that I’d actually pay for it…

just use await in an async function.

Sure, I'll just put await and async everywhere. Oh wait, I can't. A constructor can't be async so now I need to restructure my code to use async factories instead of constructors. Wonderful...

Of course, but OOP is typically about putting methods on classes, inheritance of behaviour etc.

You’re referring to one subtype of OOP. That may be what most people mean when they say OOP, but that doesn’t make it correct. Object-oriented programming is programming with objects, which does not require inheritance or classes.

As someone whose first language was C, I plan to never use C++ for anything more than programming an Arduino precisely because of the multitude of pointer types. A pointer should just be a pointer. Having five hundred different flavors of pointers is confusing as fuck.

Ananace and the article they linked are using their dislike of Go to conclude that it’s a bad language*. It is not a bad language. Every language has hidden complexity and foot guns. They don’t like Go. Maybe you won’t like Go. That’s ok. But that doesn’t make Go a bad language. The language designers are very opinionated and you might dislike them and their decisions.

I haven’t used Rust but from what I’ve seen, it’s a lot less readable than Go. And the only thing more important than readability is whether or not the code does what it’s supposed to do. For that reason I doubt I’ll ever use Rust outside of specific circumstances.

*I’m using “a bad language” as shorthand for “a language you shouldn’t use”. Maybe they don’t think it’s bad but amounts to the same thing.

Agreed. Even self-reviewing a few days after I wrote the code helps me see mistakes.

Ah, yeah that makes a lot more sense

I used this tutorial for shaders: https://learnopengl.com/Lighting/Colors

This one also has useful stuff about how lighting works: http://www.opengl-tutorial.org/beginners-tutorials/tutorial-8-basic-shading/

These are both about OpenGL, but the theory is the same regardless of the environment.

• Scenario: I'm in the middle of writing a new feature.
• Boss, to me: "Shit broke. Go figure it out."
• Me, thinking: I'm in the middle of doing some complex work. If I commit/stash and close the open files, it will take a day for me to remember WTF I was doing.
• Me: "Oh look, worktrees! I can leave my workspace intact with all the files open, pending changes, test results, terminal output, everything! And just create a new worktree to checkout the production version and debug! I'm saved!"

Also setting up a worktree is really easy. git worktree add ../hotfix prod-branch && cd ../hotfix and get working. Though in reality it's cd ../hotfix && git checkout prod-branch because I've never needed more than one secondary worktree.