Sure. Until it wasn't.
Even if Linux was a monopoly that would not necessarily be the case for ever, as the example of the Windows monopoly demonstrates. But Linux isn't even a monopoly today.
8,375 karma · joined November 4, 2010
Even if Linux was a monopoly that would not necessarily be the case for ever, as the example of the Windows monopoly demonstrates. But Linux isn't even a monopoly today.
But even there the issue wasn't the existence of monopoly per se, but with the (ab)use of the monopoly to also capture the emerging Internet browser market.
Huh?
You should reassess how your current understanding of language popularity compares to what's actually going on outside your environment.
Typescript has already surpassed C++ in popularity. [1] [2] [3] [4]
As a primarily C++ dev myself I wish that wasn't the case, but it is.
> aside from a couple of legacy features that don't seem to be commonly used, it can be erased without needing transpilation
"If you ignore the parts that don't need transpilation, it doesn't need transpilation". Well yeah, sure.
But even there, erasing types is still a transpilation, just an error-prone version of it. It's still being run as Javascript at the end, whether you actually compile to Javascript or use a frankentranspilation instead.
[1] https://www.libhunt.com/index [2] https://www.itransition.com/developers/in-demand-programming... [3] https://eu.36kr.com/en/p/3549523189739394 [4] https://survey.stackoverflow.co/2025/technology
No one is forcing you to use Linux any more than anyone is forcing you to use Windows or macOS.
I'm kind of surprised that the Go creators were surprised by this.
Like I know they didn't like C++, but Go is by no means a replacement for C++ despite whatever was said about "building a better C++/Java".
It took so long to pick up generics that Rust was already around and the logical next step for C++ developers by the time that happened. And that's only scratching the surface of why people choose C++.
On the other hand, having a more performant "simple" language that directly supports concurrency and lets you compile to native code without a ton of ceremony could be very helpful indeed if you're a Python dev who need to take an app to the next level without having to learn intricacies of C FFI or the GIL.
It's not as easy as it sounds to put the weight of ordnance required in the very tight windows that would be needed to actually cause more than cosmetic or minor damage to that bridge.
Ukraine did pull off a spectacularly successful operation to destroy a laden fuel truck while it was crossing the bridge (https://en.wikipedia.org/wiki/2022_Crimean_Bridge_explosion)... Russia repaired the damage within months and simply redirected fuel transport to other means.
Russia also has dedicated a large amount of air defense and EM jamming resources to protect the bridge, which increases the difficulty of pulling something off for Ukraine.
For a long time Ukraine didn't have the types of weapons that would be needed to even attempt it outside of saboteur types of actions. Now they have some precise ordnance like Storm Shadow but even these weapons are not destructive enough to take the bridge down except in large quantities, and those are quantities they seem to have decided are best put towards other targets.
Ukraine has recently seen substantial success in finding better weapons, with drones that can engage in "medium-range" scenarios to close off the so-called land bridge from Russia to Crimea. These weapons have also helped in degrading Russia's own defenses, but with this in mind Ukraine may feel it best to leave the Kerch bridge standing for now to allow Russian occupiers to flee across the bridge back to Russia, since Ukraine has the northern land route through occupied territories under much more effective fire control than at any point since 2022.
A more appropriate question might be, where are the armored vehicles now in Russia?
And as it turns out, they have indeed started adding armor to transport craft, including trains: https://en.wikipedia.org/wiki/Russian_armoured_train_Yenisei
And despite Ukrainian strikes earlier, the Russian bridge over the Kerch strait remains standing and in use for some (not all) logistical supply from Russia to Crimea, and this is due in no small amount due to the amount of 'armoring' that is inherent to the design of a bridge that must cross a strait of that size.
It's a question of cost more than anything, the more expensive a transport means becomes to build, the more it makes sense to start including armor to force an attack on that transport to itself have to invest a lot more for success.
The way to get around that is either continually releasing feature upgrades with one-time payments, or paying for access to the software only while you need that access.
Both models have strengths, one is not inherently evil and the other inherently good.
It's easy to say app updates should be bundled into the one-time cost but even that needs to have a time bound on it. When software lasted 3 years that potentially made sense, but now the release velocity is so much higher that there would be an explosion in complexity to try to keep up with all "one-time" releases going back for years.
Even completely Free software packages struggle with the balance with how far back to claim prior releases are under maintenance (e.g. LTS is popular, but so are 'rolling releases'). That's because of the underlying economic complexity with the costs to maintain what has gone before vs. the cost to develop what will come next.
That's just it, it does carry a cost, at the least for security updates and allowing the application to continue to be installed on later OSe or key libraries.
That's why even open-source libraries that in actively being used will get forked if unmaintained too long, because there's always something to do to keep bitrot at bay.
But they don't simply do roster updates, they bring those characters and worlds into new experiences, and they're willing to sit on good games rather than push out yearly new releases with almost nothing different compared to the previous iteration.
And the stability these franchises gives them, allows them to continue to make new IPs that may themselves grow into future tentpoles. So it's not just that they squander those successes, they are often trying to innovate into new things.
The actual equivalent might be something closer to:
inline double algorithm_call(std::span<double const> xs) noexcept {
return std::accumulate(
xs, 0.0,
[](double acc, double volts) {
auto mv = calibrated_mv(volts);
auto err = residual(mv);
return weighted_square(err) + acc;
});
}
Even that is enough to make ranges useful in my mind, but in a codebase which has started to integrate some functional programming techniques, there are also applications for things like views and transforms.
This can make it easier to reason about iteration pipelines in ways you might already be familiar with from POSIX.
That all said, it's C++ so sometimes the error messages get a lot more 'interesting' than they would have with STL-style iterators, especially when mixed with constexpr expressions as you might do with std::format or fmt libs.
So you still have to go to the store but it can be an in-and-out if everything works.
So much of what it is in the past 3 decades is coasting off its Cold War legacy.
Target lists for an Iran scenario should absolutely have been updated before use for combat, but if it turned out they had not been substantively reviewed ab initio in a decade, I'd absolutely believe it.
Software in general is a field quite compatible with initial self-funding, in ways you can't say for other industries.
But even still, investors threw away gobs of money on clearly unsustainable businesses like NFTs, and capitalism in general is happy to sell people the rope they will use to hang capitalists, so it's not even impossible to find investors if you absolutely need them.
Pair the lack of ongoing payments to investors or lenders with the superior execution of worker-led organizations, and companies such as these should pretty clearly mop up their competitors saddled with non-value-added executive management and non-value-added investors.
That is, assuming these roles don't provide any value to companies.
That sort of proves the opposite point, assuming you're referring to Dual EC DRBG, because the flaw was noticed very early on, by people who weren't even involved in its development.
Although my parents weren't rich they still tried to teach right from wrong, respect for others and all the rest.
And not to put too fine a point on it, but there's plenty of examples of rich assholes who act as if money makes them immune from justice.
But at some point hardware does break and if you're going to keep the datacenter open for business you'll need to address turnover of inventory on an ongoing basis, and if you haven't locked in long-term deals for hardware then you'll have to bear current market prices when you do that.
Yes? How else do you think it works? At scale, hardware breaks all the time and must therefore be replaced all the time.
This is true even at Hetzner's scale.
There are markets that can grow fast of course, but once that exceeds the overall economy it can only come from forcing other markets to shrink, and that limits the growth rate to which the fast-growing market can ultimately attain.
This was actually a key feature that was greatly desired by a large organization's HR function when they were working to setup a consolidated enterprise data warehouse a decade back.
It would have made it much easier for retention specialists to be able to do things like answer how much a missed retention bonus should have been once the paperwork had been fixed up.
Likewise for the same organization's board for correction of records, and in general any offices that have to make sense of what the world was like for the computer-based records years ago, and how that would change if certain data would have been different years ago.
Obviously you should talk to people.
But that doesn't lead to guarantees of product-market fit. People can describe their problems, but they usually can't describe the solution. If they already knew the solution they'd likely have already addressed the problem!
> ruthlessness is an asset when it comes to we built the wrong thing. ruthlessness gets us moving on faster.
Sure, I think we are sort of saying the same thing. I'm saying you should work on it even though it may be ruthlessly rejected later, potentially even without ever shipping.
It's part of the game and it's not worth crying over. The ruthless thing is to acknowledge the work you did, that it had value to whoever was paying you to do it, and then move on to the next thing.
But there will still necessarily be things that you build that don't ship, and that's inherent to the problem domain.