You don't need ORMs to prevent SQL injection. Prepared statements have existed for decades.

Nah it was eternally annoying that it didn't support Unix line endings. Also there are clearly a ton of basic features that people want from lightweight text editors.

In my experience a lot of these old projects really go out of their way to dissuade contributions anyway. Lots of naysaying "it's always been like that", ancient infrastructure - e.g. insisting on git send-email patches, etc.

Usually the only way it gets resolved is when someone writes a more modern competitor and it starts gaining traction. Suddenly all those improvements that people tried to do and were told were impossible and stupid aren't such a bad idea after all.

I don't think that's the case with Unity but it probably is with things like GCC, sudo, sysvinit, X11, etc.

The audacity to be nostalgic for Eclipse!

This just seems completely unimportant compared to them locking down Android.

Full of WTFs.

My default development environment on Windows is the Linux-like MSYS2 environment

I think this sets the tone nicely lol.

it’s clear at this point already that Zig is a weakly-typed language

Uhm... pretty sure it isn't.

You can only use the zig command, which requires a special build file written in Zig, so you have to compile Zig to compile Zig, instead of using Make, CMake, Ninja, meson, etc. as is typical.

Yeah who wants to just type zig build and have it work? Much better to deal with shitty Makefiles 🤦🏻‍♂️

Ignoring the obvious memory safety red herring,

Uhhh

we can worryingly tell that it is also a weakly-typed language by the use of type inference

Ok this guy can be safely ignored.

the fact that the unsafe keyword is required to cooperate with C interfaces gives even great cause for concern

?

Rather than dealing with this ‘cargo’ remote repository utility and reliving traumatic memories of remote artefact repositories with NodeJS, Java, etc., we’ll just copy the .rs files of the wrapper directly into the source folder of the project. It’s generally preferred to have dependencies in the source tree for security reasons unless you have some level of guarantee that the remote source will be available and always trustworthy.

Lol ok... Ignore the official tool that works extremely well (and has official support for vendoring) and just copy files around and then is surprised that it doesn't work.

Although you can use the rustc compiler directly, it provides an extremely limited interface compared to e.g. Clang and GCC

That is a good thing.

You get similar struggles with just getting the basic thing off the ground

Uhm yeah if you ignore the tutorials and don't use the provided tools. It's literally cargo init; cargo run.

What an idiot.

I assume people want something centralised like Twitter but without Musk. Most people don't care about federation and don't want the extra complexity and division it causes.

I'm afraid your colleagues are completely right and you are wrong, but it sounds like you genuinely are curious so I'll try to answer.

I think the fundamental thing you're forgetting is robustness. Yes Bash is convenient for making something that works once, in the same way that duct tape is convenient for fixes that work for a bit. But for production use you want something reliable and robust that is going to work all the time.

I suspect you just haven't used Bash enough to hit some of the many many footguns. Or maybe when you did hit them you thought "oops I made a mistake", rather than "this is dumb; I wouldn't have had this issue in a proper programming language".

The main footguns are:

1. Quoting. Trust me you've got this wrong even with shellcheck. I have too. That's not a criticism. It's basically impossible to get quoting completely right in any vaguely complex Bash script.
2. Error handling. Sure you can set -e, but then that breaks pipelines and conditionals, and you end up with really monstrous pipelines full of pipefail noise. It's also extremely easy to forget set -e.
3. General robustness. Bash silently does the wrong thing a lot.

instead of a import os; os.args[1] in Python, you just do $1

No. If it's missing $1 will silently become an empty string. os.args[1] will throw an error. Much more robust.

Sure, there can be security vulnerability concerns, but you’d still have to deal with the same problems with your Pythons your Rubies etc.

Absolutely not. Python is strongly typed, and even statically typed if you want. Light years ahead of Bash's mess. Quoting is pretty easy to get right in Python.

I actually started keeping a list of bugs at work that were caused directly by people using Bash. I'll dig it out tomorrow and give you some real world examples.

Rust is the obvious answer, though I dunno how suitable it really is for games - the most popular game engine is Bevy and I'm not sure I like it too much. Also there seems to be much more focus on game technology than making actual games.

Don't worry about it being "functional" though. It did support lots of FP features but the typical style is much more like imperative C++ than Haskell.

I would also look into Zig though.

Eh web rings were pretty lame even when they existed. There are plenty of ways to find new stuff these days. I hear they even have sites where anyone can post links and vote on which ones are good.

I disagree. People run Bash scripts they haven't read all the time.

Hell some installers are technically Bash scripts with a zip embedded in them.

Neat FP style. Pretty verbose though. Someone should invent a terser syntax so you don't need to write do_two_things everywhere. It's a common operation so maybe it could even be a single character.