Readit NewsNobody 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.
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.
Why not something like c#: native, fast, crossplatform, strongly-typed, great tooling, supports both scripting (ie single file-based) and compiled to a binary with no dependency whatsoever (nativeAOT), great errors and error stacks, list goes on.
All great for AI to recover during its iterations of generating something useful.
Genuinely perplexed.
What the user you're replying to is saying the Bun acquisition looks silly as a dev tool for Node. However if you look at their binding work for services like s3[0], the LLM will be able to interact directly with cloud services directly (lower latency, tighter integration, simplified deployment).
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.)
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’s equally possible for a different woodworker to build a table which will collapse when deployed in a customer’s dining room.
The difference comes down to which woodworker I’ve hired, and how they’ve been trained.
If you can’t trust a woodworker to ship a table that stands under its own weight, layering on third-party QA isn’t really going to fix the underlying problem.
That said, cargo culting the “no QA” model is ill-advised. If a particular dev shop needs QA today, they’ll probably need it tomorrow.
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.
No, your "dear leader" didn't buy intel.
You're on HN not some crappy FB group. The bar is higher around here.
This is all just so silly now.
[1] https://www.thesaturdaypaper.com.au/news/2025/11/29/inside-t...
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.