A typical backend developer using C#/Java is likely solving more complicated problems and having all the concerns of an enterprise system to worry about and maintain.
Dismissing a dev or a system because it is enterprisy is a weak argument to make against a language. A language being used a lot in an enterprise to carry the weight of the business is a sign the language is actually great and reliable enough.
I’m not dismissing Java, I’ve spent decades writing it and know what it is capable of, but it is laughable to hear that average Java dev cares more about performance or correctness than Python/JS dev.
All of them explicitly don’t have to care about performance from the start because of VMs + GC, only when scale starts to matter you start to optimize.
Tooling argument is especially funny to me, given how shit tooling ecosystem is. Sure it is ol’ reliable, but average Java dev is so stuck in their ways that they’ve never even tried to dwell out of their Java cave to see what’s out there.
IntelliJ consuming ALL of RAM, literally as much as it can get hands on. Gradle taking what’s left, rebuilds taking minutes to complete or requiring elaborate setup to have proper hot reload. Both TS and Python have far more expressive and powerful type systems than even modern Java. “Production grade tooling” my ass.
Funny to see Java shmucks looking down at JS/Python folks, as if Java at the time wasn’t picked for literally same reasons as Python/JS nowadays.
> It also has TypeScript which pairs well with agentic coding loops
The language syntax has nothing to do with it pairing well with agentic coding loops.
Considering how close Typescript and C# are syntactically, and C#'s speed advantage over JS among many other things would make C# the main language for building Agents. It is not and that's because the early SDKs were JS and Python.
Typescript is probably generally a good LLM language because
- static types
- tons and tons of training data
Kind of tangent but I used to think static types were a must-have for LLM generated code. But the most magical and impressively awesome thing I’ve seen for LLM code generation is “calva backseat driver”, a vscode extension that lets copilot evaluate clojure expressions and generally do REPL stuff.
It can write MUCH cleaner and more capable code, using all sorts of libraries that it’s unfamiliar with, because it can mess around and try stuff just like a human would. It’s mind blowingly cool!!
> C#'s speed advantage over JS among many other things would make C# the main language
Nobody cares about this, JS is plenty fast for LLM needs. If maximum performance was necessary, you're better off using Go because of fast compiler and better performance.
And that was my point. The choice of using JS/TS for LLM stuff was made for us based on initial wave of SDK availabilities. Nothing to do with language merits.
This has always been the case. The Java and C# ecosystems prioritise stability and scale. They wait for ideas to prove themselves in other languages like Erlang, Python, Go, Scala, and so on, and then adopt the successful ones. Last-mover advantage. That said, there are some caveats. Java is still missing value types, while C# has moved quickly with async/await rather than adopting models like goroutines or virtual threads, which can sometimes limit concurrency ergonomics for the developer.
Sadly, this will be the trend with things moving forward. JS is perceived as a good language and LLMs are meant to make them even easier to write. It is not about the mertis of a language. It's about which languages LLMs are "good" at.
A table is a table. It has one core function. An argument can be made that it could be built in a way that a chair can't be pushed against it for example. But the number of such cases for a table are infinitely smaller than the number of edge cases and unexpected interactions a software system can have.
QA is a way to catch those edge cases that a single developer cannot find because of various reasons. One such reason is that devs are very close to their work and they might subconsciously not trigger the unhappy path in their code.
Testing if a table works is vastly different from testing a software system.
The analogy conveys that QA is not inherently necessary to build and ship things that work.
It also paints a picture of a scenario where requiring QA would be more of a red flag than a best practice. It seems a tad silly to imagine a woodworker nailing boards together so they look like a table, then passing to QA to determine if the table is “good enough”, then having QA ship it back with defect reports. But this is exactly what many less-mature teams end up looking like.
You make a good point about unexpected interactions.
I’d argue the question for software isn’t whether QA Bad or QA Good. It’s at what level of complexity does QA become necessary. Most software teams aren’t dealing with all that much complexity (or, more specifically, inherent complexity that can’t be designed away.)
> It’s at what level of complexity does QA become necessary.
This is a good point. My answer would be that it depends on how many depend on the software and what is the tolerance for unintended interactions that users discover?
Based on which domain the software is written/deployed in, this answer will be different.
It is one more voice against the frantic nature of this topic and the corporations desperate to push for it. It is no different than one more post about Claude.md making it to the front page.
It doesn't need to. The author is voicing their opinion on the matter and is not attempting to conduct a scientific study and that is perfectly acceptable.
