The Problem With Sovdevery
A while back, I made my decision to switch from C# to C++ for future gamedev projects. I made that decision because I simply can no longer ethically be dependent on a Microsoft controlled language. C# was just a ticking time bomb, even if both .NET and Mono are FOSS now. I already don't like the direction Microsoft is going with Windows starting with Windows 8, then 10, and now 11. It's only a matter of time before the truly screw over the .NET ecosystem if they haven't already, and I doubt that there would be a dedicated group that is willing to create a viable fork when the happens.
I was aware of the problems with so called "soydevs" for a while now, but I've always made an exception when it came to video games because they're a form of entertainment and are not used for productivity. Gamers are expected to be using the most cutting-edge hardware out there already, and gamedevs just want to make their fictional universes come to life. But now, I realized that modern gamedevs (especially indies) are still part of the problem. For one, there is no reason that a 2D game should struggle on a low-end computer. That's because these games are using bloated engines like Unity (which I've never used) and are written using bloated languages like C#. C# seems to be the goto language for indie and hobbyist gamedev. If not C#, then it's JavaScript. In JavaScript's case, the developer is making an HTML5 canvas or WebGL game. Even if there is a desktop port, it's most likely packaged using Electron which bundles Chromium (possibly the most bloated browser core right now) and the HTML and JS documents into a single executable file. The only other language they might be using is Lua which is used as a scripting language for a lot of games and engines already, but in the case of indie games, there is a framework (it calls itself an engine but it's too barebones to be one imo) called Love2D. Love2D is a 2D game framework for the Lua programming language. It's basically a wrapper for SDL with some additional features. The problem is though is that you are writing the game's logic in a scripting language. That doesn't seem right to me. If you are making a more complex game like an RPG then you are going to need some way to script dialog and in-engine cutscenes (assuming you are not hardcoding them), in that case, you would have a scripting language running on top of another scripting language, which is why I moved from Python to C# back in 2017.
Soydev Defined
Okay, I haven't defined what a soydev is. Basically, it generally refers to a programmer that relies on frameworks (especially web frameworks), abstraction layers, IDEs, virtual machine platforms like .NET and Java, container platforms like Docker, and cloud-based solutions like AWS. These programmers usually fall into the neo-hipster, "soyboy" stereotype, hence the name. They may have knowledge of languages like C, C++, Go, or even Assembly, but they are no proficient in it and they primarily program in languages like C#, Java, JavaScript, Python, Lua, Ruby, Swift, etc. Bonus points if they're reliant on frameworks like jQuery, Spring, Larvel, Ruby on Rails, Electron, etc. As a result, they have little to no clue what's truly going on in the background. They are also probably not familiar with the hardware they are working on.
This contrasts with more traditional devs who write a program in a language that compiles to native machine code, uses only a few libraries, and the only abstraction layer that they depend on is the operating system itself and the few libraries that they can't statically link. They have an understanding of the hardware and operating system, their quirks, how memory is allocated, and how to manage said memory effectively. Because they have a deeper understanding of the hardware and OS, and are using languages that are closer to the hardware, they have more direct control and their programs are less bloated and more efficient.
The Problem
Soydevs are at the mercy of these abstraction layers, so people who control said layers can screw them over at anytime. For example, a lot of websites are dependent on JavaScript frameworks. Usually, these people don't host the frameworks themselves, so they rely on sites like Google to host them, which allows Google to track users of said sites and allows Google to block those sites from using those frameworks at anytime. These JavaScript frameworks and the overuse of JavaScript in general is also part of the reason why Google and Mozilla have a duopoly (or monopoly since Mozilla is just a second head of Google) in the browser-sphere. Even the smaller browsers are dependent on their browser engines. This is because the developers of smaller browsers can't keep up with the latest web standards and modern webdevs can't grasp the idea of creating a simple yet presentable website. They can't even create their bloated sites themselves, which is why they rely on frameworks like jQuery, Bootsrap, and Angular along with Big Tech APIs like ReCaptcha, Google Analytics, and CloudFlare.
It's not different in the desktop application world either. I've already talked about video games and their dependence on bloated engines and VMs, but it has gotten worse. Unity has recently been bought out by an Israeli spyware company. Unity itself is completely proprietary, and I doubt that anyone is going to make a FOSS Unity-compatible, engine (ala Enigma, a GameMaker compatible compiler) anytime soon. And of course you have the .NET/Mono dependency as well.
Another problem with being overly dependent on middleware is that it creates vendor lock-in. You may be able to port your game to macOS and Linux, no problem but what if you want to port your game to an even more obscure operating system like BSD or Haiku. Well, that requires you to port all these dependencies to those operating systems as well. So, you need to port the runtime (e.g .NET, Mono, JVM), the libraries (SDL, SFML, Vulkan, OpenGL), the engine (assuming it's FOSS), and then the game itself. It's actually kind of ironic because the main selling point for languages like C#, Java, and JavaScript is that you can write once and run anywhere, but you are really limited to what platforms the VM or interpreter runs on and porting said VM or interpreter (or writing your own) is no easy task. In C or C++, all you have to do is write a compiler for the platform. With higher-level languages, you have to write a compiler (for the byte-code if it's VM based) or interpreter, the runtime environment, port all of the dependencies for the runtime, and then your done. Languages like C are much simpler so it's much easier to write a compiler for it. That's why there are so many C compilers out there and for nearly every platform known to man. Whereas something like C# has only two actively maintained implementations (.NET and Mono) and are generally restricted to the big three operating systems (Windows, macOS, and Linux).
But the main problem is that there are now less programmers that actually know how to write native applications or applications without these general purpose frameworks. We still need programmers who write native code because obviously these virtual machines are written in it and framework developers still need to know the actual language. It also makes it so that once change to these middleware can affect the entire industry and people are less likely to fork said middleware if they don't know the inner workings of it.
The Solution
The solution should be obvious. If you are a desktop developer, learn mid-low level languages like C, C++, Go, etc. If you are a web developer learn to develop sites without using frameworks. I'm not saying that you can't ever use them, but try to be less dependent on them as possible. These languages are harder but once you understand the inner-workings of them, you will get the hang of it.