I have first hand experience of painfully slow C# compile times. Sprinkle in a few extra slow things like EDMX generated files (not C# but part of the MS ecosystem) and it has no business being in a list of fast compiling languages.
> ...I keep trying because I'm hoping theres patterns I don't see.
Python's popularity is an accident of timing. If you're digging deep for wisdom and gold nuggets you're not going to find any. The gold of python is the surface level stuff. Easy to type for hunt-n-pec typers. Press tab to indent is easier than {}.
That's all it took for an army of noobs who wanted to be "hackers" to choose Python. Then they grew up, got real jobs and brought Python with them.
It's not literally the age that's the issue, it's just a correlation. Some employers want people they can squeeze more easily and get the most juice out of.
Younger people are more likely to accept orders without push back. Accept lower pay. Work 60+ hr/week for crunch time, etc.
Depends on the employer of course. Google employs an 80+ year old Ken Thompson.
Same but from a C vs Go perspective. Didn't like GC or bundling dependencies into the final binary. But at the end of the day it's still small compared to most other languages deployment artifacts. Despite being a GC language, GO still puts you in the driver seat for how memory is allocated (ie avoid GC in the first place). And goroutines are really nice to use, without introducing colored functions like most other languages do. To top it all off Go keeps the C tradition that error handling should be a first class part of the algorithm, not something hidden off to the side.
So I'm reaching for Go for pretty much everything now days.
I was coming here to say: "grep as IDE". It's dynamic language tooling 101.
Find defs and refs. Master a little bit of regex and you will reduce false positives.
Grep serves as a rudimentary autocomplete. find the definition, open in a buffer, observe fields. This is analogous to an autocomplete popup displayed inline. The buffer can now power your contextual completions, similar to an inline popup.
Web based UI's (javascript baked in) are the only cross platform GUI all the major tech players endorse. Companies like Apple are hostile to alternative GUI frameworks, except web browser. Flash? that threatens the walled gardens so the big tech cartel came together to squash it out. Java graphics? we will not ship a JVM becuase "security". The web was already ubiquitous so the big tech couldn't squash it without squashing their own foot.
Typescript let's you start with a cross platform GUI right out of the gate. Text based HTML GUI is screen reader friendly, battle hardened for many years to get accessibility right.
Type system is advanced and allows for that sweet IDE experience.
And.... the Javascript ecosystem is the only game in town that gets close to the Lisp immediate feedback experience. (no Javascript is not as good as a lisp image, but it's better than nothing). Change a function, see the result instantly in the browser while you're app is still running. I'm not 100% sure this is true for Typescript as it must compile to javascript first, but compiling the TypeScript for 1 modified file with an on-save-hook could still be a pretty quick feedback loop.
Do these reasons have anything to do with AI agents? no but it would explain why people are already using Typescirpt, and thus use it for AI agents.
That's sort of the problem with C#. It couples the type (struct vs class) with allocation. C# started life by copying 1990's Java "everything-is-a-reference". So it's in a weird place where things were bolted on later to give more control but still needs to support the all-objects-are-refs style. C# is just not ergonomic if you need to care about data layout in memory.
Go uses a C-like model. Everything is a value type. Real pointers are in the language. Now you can write a function that inputs pointers and does not care whether they point to stack, heap, or static area. That function can be used for all 3 types, no fuss.
True, but running errcheck will catch cases where you accidentally ignore the error. Maybe not as good as having it built-in to the language like Rust, but the goal of error check safety is achieved either way.
And there's a few cases like Print() where errors are so commonly ignored you don't even want to use the "_" ignore syntax. Go gives you the poetic license to avoid spamming underscores everywhere. error linters can be configured to handle a variety of strictness. For non-critical software, it's OK to YOLO your Print(). For human-death-on-failure software you may enforce 100% handling, not even allowing explicit ignore "_" (ie become even stricter than Rust language default)
I remember wasteland 2 (from steam/wine) crashing on Linux when you finally entered the rangers headquarters. Luckily a linux kernel developer played the game and figured out what was going on. He told everyone how to fix the game with some arcane commands, increasing max counts, etc. Was pretty wild.
iterm2 has some options to fix key bind issues that hamper emacs in the terminal.