You’re right, but that’s not the point. The other poster said it’s a skill issue. Sure, if the person can’t run commands in a terminal or doesn’t know what’s an executable that’s a skill issue.

Getting stuck because the game is having weird glitches that show off once in a while and you need classes on computer graphics to debug isn’t skill issues imo. Otherwise are all gonna establish that Linux isn’t for non programmers then?

I’m not sure how that could even be done, maybe a way to control the GUI with commands that you’d then be able to script, like Selenium on browsers?

That would probably look terrible though.

I think it’s easy to make a generic YAML editor that all you need to do is to pass a “definitions” file that says all the possible options to show as a drop down or toggle etc.

That would be useful for many projects.

You’re right that garbage collection makes Go simpler, and maybe other patterns do contribute to prevent complexity from piling up. I never worked with Go outside of silly examples to try it out, so I’m no authority about it.

What I meant was more of a “general” rule that the simpler a language is, the more code is necessary to express the same thing and then the intent can become nebulous, or the person reading might miss something. Besides, when the language doesn’t offer feature X, it becomes the programmer’s job to manage it, and it creates an extra mental load that can add pesky bugs (ex: managing null safety with extra checks, tracking pointers and bounds checking in C and so on…).

Also there are studies that show the number of bugs in a software correlate with lines of code, which can mean the software is simply doing more, but also that the more characters you have to read and write, the higher the chance of something to go wrong.

But yeah, this subject depends on too many variables and some may outweigh others.

I think when it comes to tooling, some Linux tools are actually BSD software that works because of POSIX compliance. An example is OpenSSH.

I’ve been really into learning about BSD lately and even setup a VM with OpenBSD here to try it. I also like the concept of “immutable” base system and everything else is a user-version package that takes precedence.

Mojo is surfing on the AI hype, so only time will tell whether it lives to fulfill the expectation.

Doing small contributions to Wikipedia is quite rewarding. Sometimes I add little stuff, as it doesn’t take much time and small improvements are more easily accepted in any page.

The problem is people are lazy and most places I’ve been, peoeple make bad commit messages and often very non informative.

That isn’t necessary if HR consult engineers first.

Trying yourself first seems like the best approach. There are people who recommend you not to Google the answer until you have tried all the options and looked at the official documentation as an “exercise” of problem-solving without being fed the answer, cause you won’t always have it.

I’m in a situation like that. I currently work for a huge bank which requires a lot of custom configurations and using their own framework for a lot of stuff. So, most of the problems people have cannot be searched online as they’re company specific. I see new workers there struggle a lot because they don’t try to understand what’s wrong and just want a fed copy paste solution to make the problem go away.