There will be eventually only one faction left using C++ — the legacy too-big-to-refactor one.
The other faction that has lost faith in WG21, and wants newer, safer, nimble language with powerful tooling is already heading for the exits.
Herb has even directly said that adding lifetime annotations to C++ would create "an off-ramp from C++"[1] to the other languages — and he's right, painful C++ interop is the primary thing slowing down adoption of Rust for new code in mixed codebases.
Unfortunately, an option that is both safer and nimble doesn't appear to exist. I'm still hopeful, but at the moment it looks like rust is our future. A fate only marginally better than C++.
Everything out there is nimbler than C++. So you only have to select for safer to get those, and anything with managed memory and Rust are safer. (Not an exclusive set, but you'll need to actually evaluate other options.)
World's response to the climate crisis is already dangerously delayed, and we're at a point where we need anything ASAP. We've ran out of time to massively overhaul infrastructure everywhere.
The US and UK apparently can't even build a single high speed rail line any more.
Car dependency sucks, but we won't be able to fix that in the short term, but at least we can fix its oil dependence.
Cleaner grid will also need a lot of battery storage, and EV demand helps scale that up.
I don't think it's a particularly different timescale to swap from ICE to EV than to drastically reduce car dependence. What makes you think there's a big difference to where swapping to electric cars is easier than avoiding cars?
Credible reduction in car dependence needs well connected fast passenger rail networks, and changing urban sprawl to something denser with more local amenities.
The first one is a major infrastructure project, the latter is largely unpopular with the people already living there (and Republicans react to the concept of 15-minute cities like it was a gulag).
Infrastructure is still built as if it was business as usual, so can easily get blocked and delayed by decades on budgeting, bidding, consultations, NIMBYs, environmental surveys, etc.
OTOH we've already got EVs, we have already been building infrastructure for them, and it's a smaller change more acceptable to people.
I wouldn't be surprised if that created kafkaesque problems with other institutions that require name to match the bank account exactly, and break/reject non-ASCII at the same time.
I know an Åsa who became variously Åsa, Aasa and Asa after moving to a non-Scandinavian country. That took a while to untangle, and caused some of the problems you describe.
In 2013 Google Reader has been shut down, and Google defederated from XMPP. That has been the beginning of the end of "Web 2.0". Before that we were naively thinking all those APIs were free, and only the old enemy Microsoft wanted proprietary protocols and vendor lock-in.
At first, Google was very idealistic in its mission, perhaps even doe-eyed in the manner expressed in the article: no defensive patent portfolio to match their level of innovation (until Apple went "thermonuclear" on Android, and started an internecine patent war); open GTalk XMPP federation (until Facebook extracted GTalk users' "social graph[1]" without giving any data back). No internal data controls so that employees could to innovate quickly, trusting they'd do the right thing (until an engineer harassed SF Bay Area teenagers he knew IRL using their Google data), and so on. No technology can win against the human condition.
1. At a time when the hype for social graphs was a little higher than it is for AI now, and Google viewed its battle with Facebook as existential.
I'm new to GPU programming, and WebGPU and Rust's wgpu seem pretty nice to me (except the bindings!). The API is high-level enough that it's easy to learn. It hasn't grown deprecated parts or vendor-specific extensions yet.
Of course it can change, that's what removal of coherence does.
It seems to me to be a logical impossibility to allow orphan implementations, and allow crate updates, and not have trait implementations changing at the same time. It's a pick-two situation.
Your conclusion is correct. I'm very happy with the two that Rust picked and tired of people pretending that there will be a magical pick three option if we just keep talking about it.
I also think Rust has picked the right default, but I wouldn't mind having an opt in to the other pair of trade-offs. There are traits like `ToSql` that would be mostly harmless. Serde has tricks for customizing `Serialize` on foreign types, and this could be smoother with language support. Not every trait is equivalent to Hash.
Consider Java for example. In Java, interfaces are even more restrictive than traits: only the package which defines the class can implement them for that class, not even the package which defines the interface. But this is fine, because if you want to implement an interface for a foreign class, you create a new class which inherits from it, and it can be used like an instance of the foreign class except it also implements this interface.
In Rust, to the extent this is possible with the new type pattern it’s a lot of cruft. Making this more ergonomic would ease the burden of the orphan rule without giving up on the benefits the orphan rule provides.
Crate A implements Hash(vA) for T
Crate B implements Hash(vB) for T
Crate C has a global HashSet<T>
Crates A and B can both put their T instance in the C::HashSet. They can do it in their private code. Their Hash overrides any external implementation. The trait is used, but not exported.
C::HashSet now has an inconsistent state. Boom!
> and any rest stop that takes more than 10 minutes is no go for me.
You're pretty uncompromising. There are already BEVs that need 18 minutes to recharge. That's close to a 10-minute rest stop + gas station stop.
In real world scenarios good BEVs are currently about 10% slower on long-range road trips than ICE. Not ideal, but also you can relax a bit and not piss in a hurry.
You've been reading some sensationalized headlines. Outside of short-term fluctuations, only the second derivative of EV sales has been dropping — the rate of growth has slowed down, which means the sales are still going up and share of EVs is growing, just not as quickly as it used to.
This problem is already solved in places with more developed infrastructure:
• Workplaces can have chargers in their parking lots. In places where cars are parked for many hours, slow chargers are sufficient, which makes them relatively cheap and easy to install, so they can be plentiful.
• Malls, supermarkets, gyms, restaurants, etc. can have medium and high power chargers. BEVs need 20-30 minutes to recharge from a high power charger. You can do your weekly shopping while your car recharges.
• Charging posts can be installed along roads with on-street parking. In some places even lamp posts can be modified to have charging sockets.
Modern EVs used for commuting need to be charged only about once a week (BEVs are most efficient in city driving, and the median US commute is 1/10th of good BEVs city range).
With the infrastructure in place, daily use of BEVs is more convenient than ICE, because you never need to go to a gas station. BEVs charge unattended, so you don't even spend the 5 minutes refuelling. You plug your car in and leave to do whatever you wanted to do at the destination you were going to anyway.
None of this solves the issue of charging at scale. How would you solve a small town of, say, 20 000 people charging for 20-30 minutes at a mall? Note: peak for "weekly shopping" is usually just the weekend.
For on-street parking (and any parking general) it's still a lot of investment in infrastructure, as it's not just hanging an extension cord from your outlet.
You're talking in hypotheticals, but Norway has 80%+ market share of BEVs, and quite a few towns with 20,000+ residents. There are already many multi-megawatt charging locations built all around UK and Europe. It's an expensive infrastructure, but when there's demand, it pays for itself. When it's busy, they build more. Growth of the grid is also manageable: https://www.youtube.com/watch?v=7dfyG6FXsUU
High-speed charging locations that have very uneven usage with peaks, save costs by using dynamic power sharing (so capacity isn't wasted when a car that has finished charging occupies a dispenser), and have battery storage on site to use a cheaper smaller grid connection, and usually also make extra money from power arbitrage.
> it's not just hanging an extension cord from your outlet.
It almost is! For slow (overnight) AC charging the expensive inverter is in the car. The "charger" on the street is just an extension cord with a network-connected switch and a few temperature sensors for safety. BTW, home "chargers" (EVSE) are overpriced. Many of them are literally a Raspberry Pi and some switches.
I live in a Stockholm suburb. Any infrastructure investments are met with "it's too expensive" and/or "current infra will not support charging infra".
> High-speed charging locations that have very uneven usage with peaks, save costs by using dynamic power sharing (so capacity isn't wasted when a car that has finished charging occupies a dispenser), and have battery storage on site to use a cheaper smaller grid connection, and usually also make extra money from power arbitrage.
That wasn't my point, is it? High-speed charging locations will be congested exactly because of uneven usage with peaks.
The other faction that has lost faith in WG21, and wants newer, safer, nimble language with powerful tooling is already heading for the exits.
Herb has even directly said that adding lifetime annotations to C++ would create "an off-ramp from C++"[1] to the other languages — and he's right, painful C++ interop is the primary thing slowing down adoption of Rust for new code in mixed codebases.
[1]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p34...