It’s quite the opposite. It may not be worth learning Rust for small simple programs, but it has an entire toolbox of features for dealing with complex problems and large programs.
For example, dealing with multi-threading and low-level memory management without the assistance of thread-safe types and borrow checker adds mental overhead of verifying and upholding all the requirements manually.
You can do that via much simpler message passing instead. No "thread-safe types", no "borrow checkers", no "verifying and upholding all the requirements manually". The downside is you are sacrificing performance.
Rust is for high performance, high concurrency applications where the developer can spend all day building them.
I can believe that it’s just overconfidence and optimism gone too far.
The problems they claim to solve look deceptively easy on the surface. Something like escape analysis (required for automatic borrowing without GC or refcounting) has many easy cases, but also incredibly hard or literally unsolvable edge cases.
They may have been encouraged by progress on the easy cases, and assumed the rest is just a matter of a few bug fixes, rather than hitting the halting problem.
They host and defend an alt-right forum famous for harassing, doxxing, stalking and swatting people. They've been celebrating mass-shooters, and trying to drive transgender people to suicide. The guy who runs this defends this as "free speech".
UB is not an event that happens. It’s an assumption baked into the design of the compiler.
For example, on 64-bit arch if you index arrays by an int, compiler can use CPU’s 64-bit addressing modes even when they don’t overflow when 32-bit int would. The compiler is taking advantage of it all the time. It wouldn’t make sense to warn about every array, but OTOH the compiler can’t know at compile time if your pointer arithmetic will ever overflow an int.
I don't think you can just scale everything linearly by kWh. Total manufacturing emissions need to include all other car components, and there's literally a ton of them, plus overheads of running manufacturing plants, transport, etc.
Plus they're claiming a significant mass reduction, which if true, should mean that the battery doesn't use as much raw material as a simple scaling of older tech would suggest.
It defers to a repealed 97/7/EC, replaced by 2011/83/EU:
> Durable media should enable the consumer to store the information for as long as it is necessary for him to protect his interests stemming from his relationship with the trader. Such media should include in particular paper, USB sticks, CD-ROMs, DVDs, memory cards or the hard disks of computers as well as e-mails.
USB sticks are on the list, but so is paper and e-mail. This USB stick could have been an e-mail.
Binary using clap with all the bells and whistles, even without LTO, is 900KB after strip.
The standard library has 4MB of debug info baked in, which due to its special integration with Cargo is always added, even when you explicitly configure `debug=false`. This is what usually surprises people and makes Rust executables seem huge.
Not quite. Every Rust program will have some code path that may panic, and the default panic handler uses debug formatting, which uses dynamic dispatch, which prevents elimination of the rest of the printing machinery.
There’s panic_immediate_abort unstable setting that makes Rust panics crash as hard as a C segfault, and only then you can get rid of a good chunk of stdlib.
The printing machinery is quite unfortunate. Beyond being large, dynamic dispatch makes any attempt at stack size analysis much harder.
I’ve used Rust for some embedded side projects and I really wish there was a way to just get some unique identifier that I could translate (using debug symbols) to a filename and line number for a crash. This would sort of be possible if you could get the compiler to put the filenames in a different binary section, as you could then just save the address of the string and strip out the actual strings - but today that’s not possible.
The printing machinery alone is quite large when you consider that it includes the code & raw data for Unicode, whether or not similar facilities were already available on the host libc. Though you're not likely to avoid that in any non-trivial Rust program anyway, as even a pretty barebones CLI will need Unicode-aware string processing.
I generally find Rust binaries to be "a few" megabytes if they don't have an async runtime, and a few more if they do. It has never bothered me on an individual program basis, but I can imagine it adding up over an entire distribution with hundreds of individual binaries. I see the very real concern there, but personally I would still not risk ABI hazards just to save on space.
Such comparison exaggerates the difference, because it’s a one-time constant overhead, not a multiplicative overhead.
i.e. all programs are larger by 275KB, not larger by 20x.
Rust doesn’t have the privilege of having a system-wide shared stdlib to make hello world executables equally small.
The overhead comes from Rust having more complex type-safe printf, and error handling code for when the print fails. C doesn’t handle the print error, and C doesn’t print stack traces on error. Most of that 200KB Rust overhead is a parser for dwarf debug info to print the stack trace.
Rust-for-Linux made it more complicated for themselves, because they chose to enable unstable/experimental features of the compiler without waiting until they’re released, so they don’t get the stability and compatibility guarantees that normal Rust projects get.
I was confused when reading this because I was pretty sure that using other allocators had been supported for a while in Rust. From refreshing myself on the details, it seems that replacing the default allocator is stable (https://doc.rust-lang.org/std/alloc/trait.GlobalAlloc.html), but the API for arbitrary allocators (which includes stuff like being able to do "zero-size" allocations) is not yet stable (https://doc.rust-lang.org/std/alloc/trait.Allocator.html). I guess if there were ever a project that needed fine-grained control over how allocators be work, it would be the kernel.
There's also https://docs.rs/allocator-api2/latest/allocator_api2/ -- I end up using this more often than I end up using custom allocators, simply because it has a stable version of the currently-unstable functions for constructing uninitialized Vec<MaybeUninit<u8>>s.
GlobalAlloc can be used for fallible allocations: its functions just return a null pointer on failure, as with malloc() and realloc() in C. The main limitations are around the safe heap data structures in the standard library, which don't stably expose any fallible APIs except for Vec::try_reserve().
Hmm, I'd expect that would mean that it's possible to add those APIs today then rather than requiring the `Allocator` trait. Is the idea that the Allocator a parameter (maybe a generic one) when calling `try_new`, so they don't want to stabilize anything now?
The Allocator type is an unstable parameter on the heap type; Vec<T> is unstably Vec<T, A>, Arc<T> is unstably Arc<T, A>, and so on. (The allocator "A" defaults to Global, which is an Allocator that forwards to the registered GlobalAlloc.) I think the Linux kernel also wants an Allocator trait for other reasons than fallibility, such as allocating different kinds of objects on different heaps.
For example, dealing with multi-threading and low-level memory management without the assistance of thread-safe types and borrow checker adds mental overhead of verifying and upholding all the requirements manually.