It has similar features to ZIP: supports multiple files and directories with random access, in-place updates, and has a central directory. But it also can optionally merge consecutive file bodies for improved cross-file compression, and/or define a shared dictionary to tune compression for a particular set of files.
I think it can also be an interesting option for custom package/bundle formats that need an archive, and would either use compressed tarballs (awful parsing, no random access) or ZIP (worse compression).
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.
The shared dictionary support is for HTTP compression[1]: https://datatracker.ietf.org/doc/draft-ietf-httpbis-compress...
I think it can also be an interesting option for custom package/bundle formats that need an archive, and would either use compressed tarballs (awful parsing, no random access) or ZIP (worse compression).