European countries used to have their local Facebooks and Twitters, but they got wiped out once the US companies got better at localizing their services.
Which is not in itself a natural phenomenon - Spotify for example did not get wiped out by Apple Music or Google Play/YouTube Music. Europe's local Facebooks and Twitters just weren't that good.
Rust’s syntax looks alien to people who are not familiar with it, but the syntax itself is fine.
Some users also blame Rust’s syntax for being complicated when they actually struggle with Rust’s semantics, e.g. borrow checking wouldn’t be any less strict if Rust chose a less weird sigil for lifetime labels.
They're fine even without it if there's infrastructure. Supermarkets around me have fast chargers, so I just recharge during my weekly shopping (BEVs don't need to be plugged every day).
How many hours do you spend at the supermarket? I'm usually in and out in 10 minutes, that isn't much of a charge.
Also, how many charging stations are there compared to the number of parking spaces? The markets I've seen have 2 charging stations with about a hundred parking spaces. The stations are always in use, so they're fairly useless unless you want to hang around for most of the day.
Public DC chargers are orders of magnitude faster than domestic or "destination" chargers.
Modern BEVs typically need 30 minutes to charge from 10 to 80% (it slows down asymptotically above 80).
I have 150kW chargers around here (southwest UK), which add 80 miles of range in 10 minutes. My weekly shopping usually takes longer than the car needs to fully change.
It varies of course. The good one is a recent build of 10x 150kW. Older deployments were 2x 120kW, 1x 50kW, and 4x 11kW AC.
I've had EVs since 2019, and in the meantime the infrastructure in the UK went from one broken charger per city, to every McDonald drive thru having a DC charger. In the western EU it's even better with a good 300kW charger coverage along all highways.
150kW * 10/60 = 25kWh. That's 80mi at 3.1mi/kWh.
Charging used to be dirt cheap before the Russian invasion. Rapid charging prices have increased 4x since then, and per mile they're unfortunately on par with petrol now.
I think these comments are fair. It's true that Rust is rigid.
I've had great success with Rust, but on projects where I knew exactly what I needed to build. Rust's focus on code correctness is great for maintenance of projects, where the priority is in keeping them stable and not causing regressions.
So while I'd say Rust is pretty quick for refactoring of something like a device driver, it's far away from the hot-reloaded time traveling live tinkering IDE.
It's only a fixed 2d arrangement. It isn't any more expressive than the CSS table layout or position absolute+relative combos. It has no ability to react to size constraints in any other way than naive stretching and hitting min-width hard. It can't do anything "responsive" like wrapping items to the next line, or switching a grid from 1x6 to 2x3.
You can't make masonry in autolayout constraints, other than precomputing specific constraints for every item, which won't automatically reflow the items to a new container width.
IMHO Rust got OSString wrong – it indirectly promised that UTF-8 can always be cast to it without any copying or allocations, so on Windows it has to use WTF-8 rather than UCS2/UTF-16. Instead of being OS’s preferred string type, it’s merely a trick to preserve unpaired surrogates.
I wouldn't say it's necessarily wrong; it may be (accidental) foresight. Windows has added a UTF-8 code page, which means you can get as near enough as makes no difference full support with the A functions instead of the W functions.
That said, even now in 2024, it's not clear how much of a bet Windows is making on UTF-8 versus UTF-16.
I would be surprised if the UTF-8 support in Windows was anything deeper than the A functions creating a W string and calling W functions, which is what Rust is doing already.
The question is whether that's all they ever do, or whether gradually some parts of Windows begin to decide to be UTF-8 first and their W functions now translate the opposite way. This must be tempting for some networking stuff, where you're otherwise taking a perf hit compared to Linux.
Huh. Where is the "indirect promise" ? Is there a (conventionally hinted as "free", so it's not good if there's one which isn't very cheap) as function? Like as_os_string or something?
It's because str implements AsRef<OsStr> [0]. The function signature promises that whenever you have a borrowed &'a str, the standard library can give you a borrowed &'a OsStr with the same data.
Since references can't have destructors (they don't own the data like an OsString does), it means that the standard library can't give you a newly-allocated string without leaking it. Since obviously it isn't going to do that, the &OsStr must instead just act as a view into the underlying &str. And the conversion can't enforce any extra restrictions on the input string without breaking backward compatibility.
The overall effect is that whatever format OsStr uses, it has to be a superset of UTF-8.
Indeed, overuse of lifetimes is a common novice mistake. In most real-world programs lifetime annotations are very rarely needed.
The worst disaster of nonsensical <'a> exploding everywhere comes from novices trying to use Rust's references to store objects "by reference" in a struct, without understanding that in Rust references have a completely opposite meaning that forbids storing the data.
C build systems are so cursed. Autotools is obviously horrible, but projects like curl cling to it, because somehow every other C build system sucks too.
It's frankly amazing how deeply fragmented and backwards-looking C is that this continues to be a problem. In the last 30 years, a countless number of C build systems have been created, and yet an ugly pile of obscure macros outlives them all.
