Discussion
Not at all a new observation for me, but I think that most opinions about programming languages come from having to deal with Other People's Code, for good or for ill.
In fact, some of you are probably squinting at me and saying: "no duhhhh, girl."
1/n
Most of the code we actually interacted with was code we owned. In many cases, it was even more personal, that you'd be interacting heavily with your own years-accumulated code and having to live with your choices and feel what worked and what didn't. I loved that. I'm all about that longitudinal study stuff.
But this means that my attitudes about programming languages are usually about what conventions and patterns you *can* build on a language if you have well-refined taste and freedom, treating the literal language design itself as the only immutable thing about that language. This means I give grace to languages that lots of people - for valid reasons in their own very-different-than-mine experience - consider to be trash.
3/n
This is why I have a backburner blog post I keep meaning to write about how JavaScript is actually not as bad as everyone thinks. This is why I love C, but regularly criticize the C stdlib. Other people's trash, my treasure, because I have that privilege I talked about: I am not integrating with a ton of community code and community idioms that, for most normal and sane people, do a lot to define the language experience. Less controversially, this is one of the perks of Python for me, with a giant stdlib that isn't always good, but has good feature coverage without having to reach for PyPI.
I'm not the only person like this either, of course. The TigerBeetle people stick to a subset of the Zig stdlib, and a bunch of strict rules that prevent integrating most third-party code. And "love the language, hate the stdlib" is a common attitude for people who self-identify as C lovers.
4/n
This is probably also one of the factors in my iconoclastic feelings about Rust, where the same phenomenon pulls in the other direction. For most people, to use Rust is to use a big pile of deep transitive dependencies that feels like "node_modules for system programmers", and it's very difficult to use Rust *not* this way. And the stdlib itself constantly confronts you with design decisions and opaque magic sitting in layers above the mental model of the language itself, so you either have to rote memorize a bunch of magic patterns, or deeply understand tall stacks of abstractions (which mostly exist to get optimized out). From my perspective, even setting aside my ACAB feelings about the borrow checker, that's a large plate of "thanks, I hate it."
For someone who prefers to use other people's code, or takes that usage for granted, Rust is probably pretty dreamy! For a girl that wants to dive to the bedrock and build from there, not so much.
5/n
So listen, there's a diversity of experiences here. I've actually had a specific privilege in a lot of my career to write code in environments where - aside from a few libraries where you just have to put up with the interfaces they give you, and thankfully the internals are out of sight - it was just me, or me and a small team of other people, figuring out the conventions we wanted to use to build a world on top of a raw language itself.
I don't necessarily mean greenfield, I'm including legacy application maintenance. I mean that we owned most of the stack, and could decide what to do with it, and Greek-philosophers-on-a-hill type discourse in the work chat about what idioms to migrate TO or FROM was a meaningful percentage of the job. Imma say 30%, frankly.
This probably explains a lot about why I think about certain things that other people treat as received wisdom - no shade, but that's why I'm like this.
2/n