I am not sure RAM/fuel prices have much impact here. I have a phone that's about to get 3 generations behind latest one and comparing them side by side, I have 0 reasons to upgrade. Some specs are better, but not enough to notice in daily use.
> A good piece of software would make it hard to do this by accident, and probably should default to having the same behaviour with or without trailing slash.
Django redirects one version to another by default, which achieves that.
Those employees cannot (and are not expected to) code, so dynamic elements are not an option. So what you'll get are mostly either reports or messages. Reports could be created by software (which is how an engineer would do that), messages (like responding to client or manager requests) require more human-facing skills.
Every reasonable language has a Python interop story. All it takes is C FFI. But what Mojo promised early on was the eventuality of compiling a large amount of Python code if not entire wheels as Mojo.
I don't recall they promised that. They promised it'll be a superset, but Mojo introduces new keyword. Mojo could support all Python features today exactly as they're supported in Python and you wouldn't still be able to copy Python code into Mojo and compile it
> threat actors are going to start heading that way as well
bad actors are not the problem, Github priorities and attitude are, so switching solves that. Will other providers have outages? Sure, sometimes. But you'll be able to find one that manages that better.
Will you, though? Compared to PyPi/VSCode, etc GitHub made platform-wide, security changes. Blue Team gets blamed often but you can't dodge an object you don't know is headed your way. The best you can do is mitigate it, and prevent further loss. If an organization exfiltrates data, you can't go back in time and get it back. Also, AI gets tossed around as excuse for things, but it really is finding some obscure vulnerabilities humans wouldn't have. https://fortune.com/2026/04/14/anthropic-mythos-reveals-secu...
Github ignored platform issues (not just performance) because it was busy migrating to Azure, and it wants to bear the cost of ai using its infrastructure now to benefit from that somehow later. Other providers do not have this problem and live mostly from paying customers whose priority is to have stable platform. So yes, it is easy to find someone else whose priorities align with mine and doesn't have GH issues.
> AI gets tossed around as excuse for things, but it really is finding some obscure vulnerabilities humans wouldn't have.
Which is fine, as long those using it do not do so at expense of others. As a paying Github customer, I do not wish to pay for a service that doesn't work because someone else is throwing agents at it. This is largely GH issue, not general problem.
Other people may not be throwing AI agents at those other platforms yet. I doubt it but even if those platforms weren't currently being targeted, they will be.
I assume other platforms will prioritize paying customers over agents (of not paying ones) because they do not have resources to attempt anything else.
> software development becomes a commodity and the job becomes something like a fast food job where practically any adult who wants it can do it
That will never happen. Sure, anyone can program something, but to make it professionally there is bar of quality and competition will push most people out. Similarly anyone can write, draw or sing but only a few do it well enough to be paid for it.
And I am old enough to see many tools that allow "anyone to program". They pop up whenever certain standards (like web) become popular, then programming goes in different direction and they vanish in irrelevance. Soon there will be a large set of skill on top of "using AI" and "chat, make me an app" will go out of the window as viable way to make something others want to use and pay for.
>That will never happen. Sure, anyone can program something, but to make it professionally there is bar of quality
Ever seen most high profile apps in the last 10-15 years? Not to mention regular average apps, which still employ millions of people. Or most enterprise software.
> Ever seen most high profile apps in the last 10-15 years?
No, but the ones I am paying for are few and with rather solid development record. Looking at top android apps, we have some that have very high bar of engineering (firefox, google translate), some just useful dataset (cooking recipes), but again, even the simple ones outcompeted tons of alternatives.
> most enterprise software
I am not saying enterprise software is super complex, but it is very competitive domain.
> What if we built things that are meant to last? Would the world be better for it?
You'd have a better bridge, at the expense of other things, like hospitals or roads. If people choose good-enough bridges, that shows there is something else they value more.
Certainly, "enough" is doing a lot of work and things get blurry, but I think "good enough" is meant to capture some of that. Over building is also a problem. It isn't strictly true that building longer lived things is cheaper over time either, it obviously depends on the specific things getting compared. And if you go 100 years rather than 25 years, you'll have fewer chances to adjust and optimize for changes to the context, new technology, changing goals, or more efficient (including cost saving) methods.
Obviously, there's a way to do both poorly too. We can make expensive things that don't last. I think a large chunk of gripes about things that don't last are really about (1) not getting the upside of the tradeoff, cheaper (in both senses) more flexible solutions, and (2) just getting bad quality period.
It might very well be that building and maintaining a bridge for 100 years costs three or four times as much as building and maintaining one that last 50 years. If demolition costs are not same as cost of bridge well in long run replacing the bridge ever 50 years is cheaper.
On whole it is entirely reasonable optimisation problem. What is the best lifespan of single bridge over desired total lifespan.
"Good enough" bridges still last 50+ years. We could design a bridge to last 200 years but we won't even know if the design we have today will even be needed in 200 years. Maybe by then we all use trains in underground tunnels.
reply