I've written this before, but C# is a great language held back by its culture. I'd say that 80% of C# shops I've seen used it because they were started in the late 00s by some IT guy with a surplus HP server and a dream whose whole world was Microsoft products. They were staffed by people with little knowledge of OSS products who self-identify as ".NET developers" instead of software engineers. Almost invariably they seem to have some gnarly legacy monolith that everybody is slowly chipping away at while old-timers continue deploying .NET services to IIS running on Azure VMs because it's a small evolution of what they've been doing for the better part of 20 years.

In the interest of fairness the San Francisco version of this is also a thing: a giant, untyped ball of Rails spaghetti from the same period running on Heroku that everybody has Stockholm Syndrome'd their way into loving because of Ruby's elegance and beauty. The burden is merely shifted from a large Microsoft to a series of small SaaS companies :-)

Exceptions to this rule exist (hence my "80%") and modern .NET is lovely but it seems that the non-Java/Python mindshare is now taken up by the Golangs and Rusts of the world. It's a true shame since I do love C# for basically being a better Java.

>C# feels kinda nice because it's a good balance.

From my experience it's awesome to write C# with AI. But both Opus and GLM usually one shot the modification to the file so I didn't experienced cases lately where AI had to fix compile errors. True, I gave the AI agents the lsp for C#, so maybe that helps.

Yeah C# is fantastic. I also love EF.

I stopped using it because overall it feels like Microsoft has lost the plot with .NET.

You did more than just comment, you fostered an engaging dialog that navigates the intricacies of AI and its pivotal role in the human experience.

Shamelessness is the real unlock.

You're absolutely right!

Now you are not just talking like a debate expert, but a linguistic engineer. This is next level communications.

10/10

Not sure if satire

> Can you please share some insights as to what gives it away.

The article uses too much contrast even if not as obvious as "it's not x, it is y". Also some too punchy or over confident stuff like "that era is over blah blah".

Amusingly, you can feed it to an AI to extract the patterns that gives away that it is AI written.

Copilot is a legacy brand from 2021 (anyone remembers it's free beta? good times) when it was just a rudimentary autocomplete powered by GPT-3. I don't think it aligns with Microsoft's views and priorities now.

It's clearly not the MO that capable engineers want, but it's the MO that is getting funded right now.

Reading code carefully is harder than writing code unless the code is written consistently and clearly in a way that is idiomatic to the reader. And there's way more code to review now, but companies aren't scaling up the number of skilled engineers on staff. So in practice, never reading all of the diffs is the MO that will be built into code we depend on.

There are lots of good use cases for vibe coding (”never reading the code”), prototypes, various explorations and one-offs. I’ve done various kinds of migrations where I didn’t bother to review the code much, just the output.

Possibly also some user-facing tools with a limited task and runtime environment.

Incidentally, these are all use cases where performance isn’t critical, typically, so you might as well write them in Python or Typescript or whatever makes most sense for the task.

Real production code? Yeah, you still need to be able to read it and understand it.

Let's say you get access to a microservice from another team in the company. Do you read through and audit every line of code?

What if it's from an external vendor? A 3rd party SaaS?

At which point do you stop caring about reading every line of code you run?

I’ve always found Ruby to be way more readable, what keeps me using python is the depth of libraries is unmatched.

So unless you’re into burning tokens having AI generate untested libraries, I’d stick to using the most idiomatic tool for the problem you are tackling.

I'd argue that while Rust has a high barrier to writing code due to lifetimes and other type constraints, its still quite easy to read.

(Kind of the inverse of perl)

> But if you want to participate in the writing, debugging, and maintenance, it has to be in a language that a human can read.

I think the idea is that languages like Python and JavaScript make it easier for humans to write the initial implementation, whereas the "hard" languages from the perspective of creating the minimum viable product are the ones that make it easier for humans to maintain the code, and this has historically been a major trade off.

Whereas if you have the AI write the initial implementation...

> I know I am better at Python personally and am going to keep using it until the speed penalty matters to my project,

I hate Python (app distribution is painful), but will still reach for it before I reach for Go. Rust doesn't even enter the equation.

I would not have even needed to reach for Go in about half my programs if Python had mandatory typing and single-file no-dep distribution.

> and then maybe I’ll let an AI rewrite the whole thing in a faster language.

Even then, my reasons for discarding Python when I do discard it is almost never "performance", it's because the problem space requires mandatory typing for complex data types, or concurrency, or easy distribution.

Of course, this requires me to figure out quite early ion a project that those things would be needed.

Did you read the article? I think you're arguing against a strawman.

I had not! Cool to see that there's a established theory about linguistic determinism(great term btw!)

I was only speaking from personal experience, I moved from Sweden to Brazil in my early twenties and after a while I began thinking and dreaming in Portuguese. I noticed then that my thought process changed(actually, I noticed it upon moving back to Sweden, as my thoughts and dreams shifted back to my mother's tongue. The shift the way back was much faster since I already spoke Swedish whereas in Brazil I had to learn the language before beginning thinking in it)

Anyway, I noticed then that I would interpret the world differently depending on which language I used for my internal monologue. Like way different. It was a curious experience!

They don’t express gender, they signify adjective and noun. No genders in Esperanto

[flagged]

Agree.

I am using type hints in Python as much as possible for my hand-coding. And it catches a lot of bugs (especially during code refactoring) that I would not have noticed so easily.

> so it just boils down to strictness even when we're talking LLMs?

The article describes what I've been doing for the past few months - I did small python projects in the past because of the ecosystem: I couldn't possibly write a ton of the stuff required for the things I wanted to do, so I leaned into python because someone already wrote it for me. Quality of deps was mostly ok for the happy paths, but always a chore to patch the broken ones.

Nowadays I tell Claude what I want to build and I always ask it whether rust is a good choice for it. It'll pick up the right crates or choose whether it should DIY, do all the plumbing, nail all the logic, and in ~30m I'll have something very solid that would have taken me 3+ weeks of part-time evening coding in python. I think the article is right and rust is the closest to the "best language" we have for LLM coding at the moment: the strict typing and the tooling dramatically reduce the output space for LLMs, and 99% of errors have a clear, precise explanation that is actionable, and the compiler helps you a lot there too.

I think it also boils down to the fact that you cannot reliably and quickly answer "why is this arg None?" in languages like python without figuring out the call graph and evaluating possible states and inputs/outputs. Rust makes all that explicit and forces you handle it, which I feel dramatically cuts the time an LLM needs to spend figuring out why it's broken or what to do next. EDIT: The fact that you get memory safety on top of all this and it's handled by the compiler is yet another advantage for LLMs: the logic that gets written is simpler to reason about, because if you try to mutably access the same variable in two different places, the compiler will feed this back to the LLM at build time. In other languages that would be a "code smell" or would require static analysis.

Strictness is a quality for software and a chore for humans, and of course the stricter you are at representing your logic and your state machine, the less ways a program can break. LLMs writing in rust give you the strictness without the chore part, and it's a very good deal from my point of view.

If you are using TDD with any recent model and even local models (qwen3.5+), you alleviate most of the issues mentioned.

Note that:

Writing code, then tests

Is not equivalent to:

Writing tests, then code

Haskell is a good language for LLMs! Claude knows it really well, and the type system catches so many mistakes. Just make sure to tell it to model the domain in the type from the start.

Also, Haskell can be really performant and low level, while still keeping the benefits of typing. With the C foreign function interface you can really do anything in Haskell!

Lay it on. I love to collect other's anecdotes and see where they align (or disagree)