The only real connection to Tesla is that it's a Tesla-funded employee shuttle to a station on Tesla factory property. The trains are indeed Siemens Miero B and the line is operated by Niederbarnimer Eisenbahn.
I'd say that purchasing a train that runs (at least?) 3x per day and allowing the public to ride for free isn't nothing?
Definitely just a money + PR contribution though, I'd be curious of this is just advertising something that was a requirement from local lawmakers for building the factory in the first place.
The headline makes it sound like it's a Tesla-made train.
If it had been made by Tesla, they would have hyped it into the ground, tried to put it underground, and inspectors would notice a suspicious amount of hacks done just to keep it running. And Elon would have promised a self-driving mode that inexplicably doesn't work with a vehicle that only goes forward and backwards.
All I can find is that the new train replaces a diesel train, and that Tesla took flack last year for running a diesel-electric train as their employee shuttle.
Yes, the train is a Siemens Mireo, and I can't find anything that says that Tesla was involved in the development of this specific train at all... so Tesla provided branding, I guess.
What’s funny (or sad?) is seeing attacks on social media tearing down the idea of a battery powered train just because it is associated with Elon Musk.
Elon may be a shit person (though what billionaire isn’t a megalomaniac), and electric cars may be a poor long term solution for the environment (the spontaneous combustion and destructive mining of lithium are… less than desirable) but trains are cool, people should lay off them, in fact we need more of them.
Instead, let’s talk about what Elon promised would be better than trains: The χLoop (formerly Hyperloop).
Rust is its own thing, but use of algebraic data types + pattern matching and type inference makes it feel closer to OCaml than C++. The original Rust compiler has been written in OCaml, so that's definitely an influence.
You can get some of this speed back with HTTP/3 0-RTT start, and use 103 Early Hints to make browsers preload assets early. This combo has an advantage of being semantically backwards-compatible with HTTP/1 (reverse proxies, load balancers).
Rust is much better suited to static analysis and formal verification than C++, primarily thanks to stricter pointer aliasing, immutability without loopholes of const, and thread safety annotations in the type system.
Most things that are advanced correctness verification in C++ are regular compiler errors in Rust.
I think it would make more sense to support the existing implementation than to start yet another one.
As for why jxl-oxide can't be used yet — it just isn't mature enough yet. They're still finding unimplemented or incompatible features, and have some unoptimized code.
JPEG XL is big and complex – it is designed to have every feature of every competing codec (from vector graphics to video), and beat them all on compression in every case, so it's a half a dozen of different codecs in a trench coat.
This is a great news for JPEG XL. Web standards need two independent implementations of every feature – this proves that the spec is actually possible to implement, and makes it possible to verify that the implementations are interoperable.
It makes uses in the wild much less likely to depend on bugs in a particular implementation, which makes it possible to upgrade or replace implementations without creating bug-compatibility problems.
I believe that there are already several decoder implementations that pass the ISO conformance test for JPEG XL. I don't remember which one's exactly but I believe at least both jxl-oxide and libjxl do.
Another implementation is still unlikely to have the exact same bugs. Especially rewrite in Rust will force the code to be structured differently (Rust is very opinionated about that).
The spec is big enough that the team won't be able to just write the exact same implementation from memory.
I don't disagree that it's sufficient, but also, ideally different people would implement the spec. If you have a particular mental model or understanding of a part of the spec that doesn't match what the spec actually says, that is likely to translate identically when writing a second implementation.
Rust has used reaserch from 80s and 90s languages. The result may seem novel because the programming language theory and languages that Rust copied are not well known among systems programmers. The ideas are old, Rust added the polish and packaging of the features with a focus on practical non-reaserch use.
Rust isn't that new any more. 1.0 has been released almost a decade ago.
What features do you rely on? This is effectively the opposite of my experience, which is why I am curious: even our embedded OS at work is almost free of nightly features, and everything higher in the stack has been on stable for a long time. Always interested in learning how experiences differ!
Yes, for that OS we’re using asm_const, which is almost stable, naked functions, and used_with_arg, which is linker related. We also use array_methods but that could be polyfilled, if the other three were stable.
crates.io sees about 13% of requests from nightly compilers, although that may be biased by CI tests that just check for future compatibility rather than needing nightly features.
For application development nightly hasn't been necessary for many years now. Places where people use nightly are increasingly just nice to haves and small optimizations.
To me Drew's article is a "bless your heart" answer that tells Rust users to go away, and keep themselves busy with something that nobody else will care about.
`cargo check` that does all the parsing, type system checks, and lifetime analysis is pretty fast compared to builds.
Rust compilation time spends most time in LLVM, due to verbosity of the IR it outputs, and during linking, due to absurd amount of debug info and objects to link.
When cargo check isn't fast, it's usually due to build scripts and procedural macros, which are slow due to being compiled binaries, so LLVM, linking, and running of an unoptimized ton of code blocks type checking.
With a little care, you can get the same code size as you'd get in C.
https://github.com/johnthagen/min-sized-rust