The car isn't the problem, but it's tied to an incredibly overvalued stock, which in turn made it possible for Musk to buy massive influence and political power, and wield it irresponsible self-serving ways.
Quite the opposite. Pebble is great at sleep tracking. They manage to do a better job with Pebble's limited sensors than Apple can with all of their hardware. I have both, I use sleep tracking a lot, and I've compared them.
It's a chaotic system (turbulent flow is chaotic). Even tiniest differences between the real and simulated state will add up and amplify over time.
Fluid simulation is a notoriously hard problem. We don't have a solution to Navier-Stokes equations. Practical implementations have limited resolution in time and space, and plenty of simplifying assumptions.
If you don't count manual SIMD intrinsics or inline assembly as C, then Rust and FORTRAN can be faster than C.
This is mainly thanks to having pointer aliasing guarantees that C doesn't have. They can get autovectorization optimizations where C's semantics get in the way.
Buggy unsafe blocks can affect code anywhere (through Undefined Behavior, or breaking the API contract).
However, if you verify that the unsafe blocks are correct, and the safe API wrapping them rejects invalid inputs, then they won't be able to cause unsafety anywhere.
This does reduce how much code you need to review for memory safety issues. Once it's encapsulated in a safe API, the compiler ensures it can't be broken.
This encapsulation also prevents combinatorial explosion of complexity when multiple (unsafe) libraries interact.
I can take zlib-rs, and some multi-threaded job executor (also unsafe internally), but I don't need to specifically check how these two interact.
zlib-rs needs to ensure they use slices and lifetimes correctly, the threading library needs to ensure it uses correct lifetimes and type bounds, and then the compiler will check all interactions between these two libraries for me. That's like (M+N) complexity to deal with instead of (M*N).
Like all ICE engines, it still emits NOx pollution that cities want to get rid of.
It is even less efficient than hydrogen fuel cells. It combines energy-inefficiency of ICE with the energy-inefficiency of hydrogen generation and distribution.
Hydrogen is a worse fuel than gasoline, so these engines are more complex and deliver less power.
Such engines in busses would be more expensive to run, more expensive to maintain, and still have tail-pipe emissions.
In Rust objects can dynamically go in and out of having virtual dispatch. The vtable is only in the pointer to the object, so you can add or remove it. Take a non-virtual object, lend it temporarily as a dynamically dispatched object, and then go back to using it directly as a concrete type, without reallocating anything.
That's pretty powerful:
• any type can be used in dynamic contexts, e.g. implement Debug print for an int or a Point, without paying cost of a vtable for each instance.
• you don't rely on, and don't fight, devirtualization. You can decide to selectively use dynamic dispatch in some places to reduce code size, without committing to it everywhere.
• you can write your own trait with your own virtual methods for a foreign type, and the type doesn't have to opt-in to this.
For a long time Tesla had barely any presence in Europe, and Model S and X were expensive rare cars, from a weird foreign brand. Driving that was a delicate balance between coolness and showing off, and then Musk changed the image from cool to extremely divorced midlife crisis.
Now that EVs are more mainstream, there is already competition from new VW, Kia, Hyundai, Renault, Volvo, BMW, which makes Model 3 kinda bland, and the more popular Model Y looks like Model 3's CAD design stretched vertically by 20%.
Supercharger network doesn't have a significant advantage in Europe, all new cars use the same connector already, so buying a Tesla is a choice. People question why do you buy a car that isn't pretty, isn't cheap, isn't from a "real" car brand, and is associated with Musk's antics.
