I’ve used Python since the 90s. Rust feels very much in the spirit of it to me: a Rust program ends up shaped a lot like the Python equivalent would. Not identical, or it’d just be Python, but similar.
There were some “interesting” issues with a lot of the cheap hardware for a long time though. A classic example was the WinModem. A fast modem for cheap? Sure! But it was cheap because it outsourced a lot of its processing to the CPU, so if your system was loaded up (in the day when CPUs were almost all single-core) meant there wasn’t enough left over to process inbound data in realtime which meant dropped packets and retries and horrendous lag and throughput.
Standard wisdom was to use an Intel EtherExpress Pro card for a long time after onboard Ethernet was available. Lots of server hardware had unused builtin NICs until they got decent.
HP themselves sold Aruba networking equipment with lifetime warranties and then just decided they wouldn’t honor it anymore. So a warranty change after a company acquisition sounds even more plausible in comparison.
I guess they decided no one would take them to court, and if someone did they'd just refund the value of the item (which presumably is low these days).
Which would imply such lifetime guarantee promises are worth very little.
No. My target directory is 329GB at the moment. I wish mine were just 90GB.
(And yet I’m perfectly happy running `cargo clean` periodically in exchange for all the Rust loveliness. Sure, I wish I didn’t need to. Sure, I hope it’ll get better. I can live with the temporary inconvenience though.
Also, I’m developing in a tight auto-build-on-commit loop so I have a gazillion builds.)
These numbers are totally insane. I've never seen a Rust project with a build cache this large.
Do you have 10 different versions of Tokio included in your project or something?
The project I'm currently working on is quite large, and it's locally cross-compiled to 5 different arch/OS combinations, plus a debug build for the local machine. The build dir is 9.1 GB. I've seen it grow to somewhere around 20 GB, but only after a significant number of dependencies were updated, or the compiler version changed.
A clean debug build of Bevy (a game engine, one of the largest Rust projects around) produces a target dir of around 13 GB. By the way, rebuilding Bevy on my machine takes about 1 minute.
Now, these numbers are still much bigger than I would have preferred, but 329 GB? Get out of here.
A complication on a wristwatch is anything other than telling time. Phases of the moon? Tides? Calendars? Complications. They make the innards more complex and fragile and difficult to build and repair. Complexity is the inherent difficulty in building the thing.
Together, what that's saying is that sometimes the minimal baseline complexity is going to be pretty high. If you're making a library to support all of HTTP/2, it's going to have lots of codepaths, and that's unavoidable. It's a complex problem requiring a complex solution. But consider SMTP, the "simple" mail transfer protocol. The protocol itself is stupidly simple. I can use — and have used — telnet to port 25 to send email. But because the protocol is so simple, implementing it is extremely complicated. Were the protocol a little more complex, the implementations could be vastly simpler.
Or perhaps more simply, if you're writing a textual protocol, define it as using UTF-8 encoding and move on. UTF-8 is more complex than simpler encodings like ASCII. Allowing your clients and servers to decide that they'd rather support something goofy, like Shift JIS or UTF-16, just makes everything vastly more complicated. Accept that the complexity of UTF-8 is inherent and sufficient, pay the cost, and then let all of your consumers be much simpler.
I cannot emphasize this enough: if you actually care about performance, forget about 16GB vs 8GB and switch from using the internal SD card and to an external SSD. I wrote up my experience at https://honeypot.net/2023/03/20/upgrade-your-raspberry.html
Once you've done that, and your max latency has dropped to 0.7% of what it use to be (yes, really, the SD card had 140x higher latency than the SSD on my system), carve out 32GB for swap and call it done. This will give you vastly better throughput on any likely use case that's not purely dependent on RAM size alone.
If I were using this as a portable desktop system, like I am with my uConsole, I'd rather have 4GB of RAM and fast storage than 16GB and the SD card. One of them is fine, just a little sluggish sometimes. The other is pretty nice, until it grinds to a halt for minutes at a time. If `apt upgrade` is your benchmark, SSD >> RAM by a wide margin.
Yes, that's what people use to say before they did the math. I have an 8GB Pi with 32GB of swap. I'm currently using 60MB of it. But even if I were hitting it hard, it would take a lot of writes to it before the wear leveling gave up and started throwing SMART warnings. I'm not routinely rebuilding all of Gentoo or something. I just want some extra room to grow on those rare occasions that I need it.
reply