Readit NewsTrams in Amsterdam even have two staff of board.
Speed in relation to semi trucks always seemed the most absolute vanity metric on earth!
The trucks are all designed to be driven for the legally mandated maximum of 4.5 hours at highway speeds and to be recharged sufficiently in a 45 minute break to be able to do that again for another 4.5 hours. In particularly adverse conditions a little less driving time before recharging is possible but for an average load the currently available tech works just fine and it is mostly the charging infrastructure that limits adoption.
Oof. That's a lot of coal. ~ 1000 tons of coal/year or the CO2 equivalent of 10 million miles of driving.
Edit: corrected math
I'd guess all the information would already be available on the internet, but is there competitive advantage here?
https://news.ycombinator.com/item?id=43964524
It's true, that paper is nonsense. There's not really much else to say. Preprint servers sometimes publish the sort of stuff that wouldn't pass peer review. (Remember that S.Korean "superconductor" from about two years ago!?) The press should be cautious when writing about it.
However, "macros" are a disaster to debug in every language that they appear. "comptime" sidesteps that because you can generally force it to run at runtime where your normal debugging mechanisms work just fine (returning a type being an exception).
"Macros" generally impose extremely large cognitive overhead and making them hygienic has spawned the careers of countless CS professors. In addition, macros often impose significant compiler overhead (how many crates do Rust's proc-macros pull in?).
It is not at all clear that the full power of general macros is worth the downstream grief that they cause (I also hold this position for a lot of compiler optimizations, but that's a rant for a different day).
I have only used proper macros in Common Lisp, but at least there they are developed and debugged just like any other function. You call `macroexpand` in the repl to see the output of the macro and if there's an error you automatically get thrown in the same debugger that you use to debug other functions.
WasmGC would be the best solution here, yeah, then the VM handles pointers for you.
Otherwise, I could look into the SpillPointers issue for you if you want - optimizations should not remove GC pointers, so that sounds like a bug. If so feel free to file an issue with a testcase. (But WasmGC would be best, avoiding all that.)
Perhaps it could be combined with J (array language), like in the playground https://code.jsoftware.com/wiki/Playground that is using webassembly
It seems to work very well locally without connection to the web.
Of course, another approach would be to use the new wasm GC interface. But that requires defining a new ABI for garbage collected C, writing a new backend for LLVM, etc. So that would also be a lot of work to implement. Right now, there just is no efficient way to run programs that depend on bdwgc on wasm.
I was legit considering getting an F150 lighting for a little while but when I saw how much your range decreases when towing something it became obvious that it’s not really practical. It’s just objectively worse at hauling than a gas car.
Hopefully we see more battery tech breakthroughs that make electric trucks viable work vehicles.