DaveTheCoder I had one of the early Macs. There was no assembler for it initially. Using a 68000 programming manual, I used pencil and paper to write assembly code and translate it into hex, and patched the instructions into RAM. That had the side effect of making me really familiar with the instruction set, which came in useful at a later job.
Now that's hardcore. Urban legend has it that von Neumann could program in hexadecimal machine code directly off the top of his head. When suggested to build an assembler to make the job easier, he dismissed it as a waste of time. See, fellow kids, you nowadays complain about not having a brace or two. Back in the day we didn't even have assemblers 🥳
Joking aside...
Yeah, multithreading is one of Python's weaknesses... or strengths, depending on how you look at it. But for a game engine it's definitely a problem. Other reasons from the official "why custom language" list are also not without merit. When you think about it, a "new" language for a new engine should be made as accessible and easy to pick up as possible. So your best bet is to employ a popular syntax that lots of people are already familiar with. There are really only 2 options: C-like or Python-like. Since C# already is a good C-like readymade option, Python-like is the only reasonable thing left. Using otherwise pure Python syntax with curly braces shoehorned in would just be confusing (and frankly - irritating) for people with previous coding experience. And it can be argued that this is the majority of active and potential users.
Overall, I think Godot masterminds did the right thing with GDScript, in both - desicision to use a custom language and to make it look like Python . As with most other things in Godot, the solution is well thought out and aptly implemented. So kudos. I still didn't check the new GDScript features and improvements in v4 though.
