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.
How can such law be written and how can a lawyer litigate that in court? The way you've phrased it is very subjective. What is an objective measure that a court can use to determine the percentage of quality drop in a product against a timeline?
> Easy, mandate that any UI changes be revertable for the life of the product, or until the company goes bankrupt
I'm aware people are annoyed with big UI overhauls that seemingly do nothing, but I don't think you understand what it would take to support what you wrote. You're describing something that gets exponentially harder to maintain as a product ages. It's completely prohibitive to small businesses. How many UI changes do you think are made in a year for a young product? One that is constantly getting calls from clients to add this or that? Should a company support 100 different versions of their app?
I understand a small handful of companies occasionally allow you to use old UI, but those are cases where the functionality hasn't changed much. If you were to actually mandate this, it would make a lot of UIs worse, not better.
As much as people want to act like there's a clear separation, a lot of UI controls are present or absent based on what business logic your server can do. If you are forced to support an old UI that does something the company cannot do anymore, you are forcing broken or insecure functionality. And this would be in the name of something nobody outside of Hackernews would even use. Most people are not aware there is an old.reddit.com.
2) Stop having rolling feature updates except on an opt-in basis. It used to be that when I bought an operating system or a program it stayed bought, and only updated if I actively went out and bought an update. Rolling security updates are still a good idea, and if they break UI functionality then let the end customer know so that they can make the decision on whether or not to update.
For hosted software, such as Google office, is it really that much more difficult to host multiple versions of the office suite? I can see issues if people are collaborating, but if newer file formats can be used in older software with a warning that some features may not be saved or viewable, then the same can be done with a collaborative document vis-a-vis whatever version of the software is opening the document.
My wife recently went 0patch and some other programs to cover her Win10 when Microsoft stopped updating it. She still got force updated two updates having to do with patching errors in Windows' ESU feature that blocked people from signing up for the 1-year of ESUs. She let those updates happen without trying to figure out a way to block them as they have no other impact on her operating system, but it would have been nice if Microsoft have been serious about ending the updates when it said it was.
I am not a programmer, but come on. This was done in the past with far less computational ability.
This entire subthread is full of people missing the point: no removing features.
You can add them, you can even move them, but you don't get to take back something you already sold me, unless I also get to take back the money I gave you.
Really not super interested in excuses and whining. Either support the features you sold me, or refund my money. It really is that simple... and it really should be the law.
You can wish the thread was about that, but that's a completely different conversation, and you're the first to bring it up. I haven't seen any excuses for it. I don't like when I have something simple like an export tool in my app and it's suddenly gone.
But the question is how do you define what a feature is in networked apps? If you play an online game with a sniper rifle that one-shots people, and the developers nerf it, have they taken a feature from you? But everyone else loved the nerf? How do we support you and the players? Let you continue one-shotting them?
If the app you're paying for could message other users, but now they can block you, is the company supposed to give you a refund because now you can't message some users?
Good questions. I could argue that the game rules can reasonably include clauses such as, "We can adjust weapon/defense parameters at any time." But the addition of a blocklist feature is a bit harder to hand-wave away because it could be said to be economically damaging to spammers. I would say yes, if the ability to message everybody is advertised as a feature, the company would need to refund the spammers (and kick them off.) Hopefully the company will learn to provide clearer terms of service next time.
In general I think the best answer to your objections is to require companies to specify up front exactly what features are being sold, and for how long they are guaranteed to be available. The onus would then be on the consumer to evaluate the list of guaranteed features against their wants and needs. Consumers would hopefully learn, over time, not to buy products that don't provide these guarantees up front.
Right now what they (we) are learning is not to trust anything with an Internet connection, because of abuses from a small number of prominent bad actors. Which is unfortunate.
I'm not trying to be overly negative, it's just hard not to write a lot and respond point by point.
> Have this law only apply B2C.
I don't think limiting it to B2C changes much. Now instead of business customers calling and asking for features, you have swaths of people asking for a feature on the internet.
> I am not a programmer, but come on. This was done in the past with far less computational ability
If by computational ability you mean the actual power of our hardware, this isn't really a computational problem, it's a manpower problem. We have faster computers, but our velocity as developers has been relatively stagnant the past 20 years, if not worse.
Believe me, I'm totally sympathetic to the idea that web apps could support older versions. I have thought of doing it myself if I were to get out of contract work. But I'm aware of how much extra work that is, and it would be something I do for fun, not something that most people would appreciate.
> Stop having rolling feature updates except on an opt-in basis. It used to be that when I bought an operating system or a program it stayed bought, and only updated if I actively went out and bought an update
Having an opt-in doesn't really change what I'm talking about. This is lumping different kinds of software together, and it would be helpful to separate them. There are apps that do local work on your computer, apps that communicate with a network, and the OS itself.
Apps that work locally and don't need to talk to a server can have multiple versions, and they often do. That's a solved problem. I have not been forced to upgrade any third party app on my computer. But I have had AI crammed into Microsoft apps and I hate it.
Apps that communicate with a server, and other users, are the source of a lot of issues I'm talking about. Maintaining versions for these creates cascading problems for everyone.
For OS: I'm all for not being forced to upgrade my OS. But if I don't upgrade, the reality is I will miss security updates and won't be able to use newer apps. That was the case in the 90's, and it's the case now.
> Rolling security updates are still a good idea
That's doing some heavy lifting. It's a good idea, sure, but you can't just sprinkle security updates onto older versions. You're just multiplying how long each security fix takes for all users.
> For hosted software, such as Google office, is it really that much more difficult to host multiple versions of the office suite
In Google's case, it's difficult to maintain one version of an app. They kill apps left and right. You're referencing software from the biggest companies in the world. Reddit manages just one other version, and that's because the core of their app has stayed the same since 1.0. If we required all B2C to always support older versions, we'd essentially make it illegal for small companies to make networked services.
Here's how it plays out for a small company:
- Every security fix has to be backported to every version of the app. This is not free, this is extra work for each version. What if it's discovered Google Docs has a vulnerability that could leak your password and has for 20 years? That's a lot of versions to update.
- If the app interacts with other users in anyway, new features may need to support old versions anyway. How do you add a permissions system to Google Docs if the old version has no permissions? What should happen on the old app when they access a doc they couldn't access before? You have to program something in.
- Support staff has to know 10 different versions of the app. "Have you tried clicking the settings icon?" "What settings icon?"
- Internet Guides? YouTube tutorials? When you Google how to do something, you'd need to specify your version.
- Because we are doomed to support older versions in some capacity, companies will just not work on features that many people want because it's too hard to support the few people on older versions.
This is why apps with "versions" usually have support periods, because it would be impossible for them to support everything.
> This is why apps with "versions" usually have support periods, because it would be impossible for them to support everything.
And that's fine. Just leave it that way and stop with the rolling feature updates that a person can't block because the only way you sell your software is as SaaS.
How would that work in real life though? Now every change made to any program must be tested against an ever growing combination of enabled and disabled UI changes.
I don't know, but I do know that on my web browser I can add and remove various of the buttons and right-click menu options. And on linux I can skin my desktop environment in a variety of ways (Unity stopped working, I went to Gnome which was glitching, and now have something very much like Unity used to be in XFCE and unlike a commercial product I paid nothing for this.).
Adding and removing buttons from the UI is vastly different compared to maintaining a system where which features are enabled/disabled affect the underlying data and potentially interoperability.
Do you want to work on Oracle Database [1]?
By the way, I also don't want the software I use to suffer from quality drop due to new forced "features". I just don't think the way suggested here works well.
Tough. Somehow IKEA is doing fine without being able to break into my house and change the way my furniture works. Devices and software should not be any different.
Well, it would probably need to be part of a physical product and not software alone unless the vendor is dumb and forgot to disclaim the warranty (see https://repository.law.uic.edu/jitpl/vol16/iss2/6/).
Second, it’s not exactly about whether the change constitutes a drop in quality but whether it renders the product unfit for its ordinary purpose. The argument would essentially be that the change is a deliberately introduced defect.
It’s a little weird but a plausible claim given the right facts.
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.