The only issue is that Musk vastly overpaid for Twitter, but if he plans to keep it and use it for his political ambitions, that might not matter. Also remember that while many agree that $44B was a bit much, most did still put Twitter at 10s of billions, not the $500M I think you could justify.
The firings, which was going to tank Twitter also turned out reasonably well. Turns out they didn't need all those people.
1. He overpaid by tens of billions. That is a phenomenal amount of money to lose on an unforced error.
2. Enough users, who produce enough content, have left to make X increasingly a forum for porn bots, scam accounts and political activists. It's losing its appeal as the place "where the news happens" and is instead becoming more niche.
3. The firings did not go well. X has struggled to ship new features and appears nowhere closer to the "everything app" Musk promised. It posts strange UUID error codes. The remaining developers seem to implement things primarily client side, to the extent I even wonder if they have lost their ability to safely roll out backend changes.
4. The capture of X by far-right agitators has led to long term brand damage for Tesla, Musk's most important business property.
I can't see any positive outcome from it.
Anyway, what kind of features Twitter (or any social network for that matter) needs after it existed for so many years? Hacker News haven't changed a bit a it does what it does perfectly well
You sound like someone completely oblivious to software development practices who somehow felt compelled to post opinions on software engineering.
Your choice of language is irrelevant if your goal is to maintain software. What matters is systems architecture and institutional knowledge of how things are designed to work. If you fire your staff, you lose institutional knowledge. Your choice of programming language does not bring it back.
This take is, quite bluntly, stupid and clueless. Do you think each commit reflects the volume of institutional knowledge of any individual? Unbelievable.
Sure there had so be some frequent but low impact committers. But implying that people with lowest amount of code contribution must have more impact is ridiculous.
I mean, a staff engineer who stopped committing couple years ago? Yeah could be burnout, or could be some major contribution that's not in the stats. OTOH an IC on their second year in position who hadn't pushed a single line? Nah the institutional knowledge is safe without.