I don't think that's a commonly touted benefit of Rust.
You certainly can build a statically linked binary with musl libc (in many circumstances, at least), but it's not the default.
The default is a binary that statically links all the Rust crates you pull in, but dynamically links glibc, the vdso, and several other common dependencies. It's also, IIRC, the default to dynamically link many other common dependencies like openssl if you pull them in, although I think it's common for the crates that wrap them to offer static linking as an option.
Quite a lot of things can get by without needing any other dynamic libraries other than libc; there are some alternatives to using openssl in Rust that are fairly common. There definitely are places I've seen containers used for building/deploying Rust due to the need for dynamically-linked dependencies, but I've also seen it a bit in places where they already are using containers for everything else, and using the same thing for all of their services regardless of whether they're in Rust, Node, Python can can make the process around deployment simpler rather than having a separate way of doing things for each language.
You don’t need non-libc dependencies to run into issues when copying a binary from one host to another: glibc uses symbol versioning, so (unless you jump through some hoops) a binary built one a machine with a newer glibc will fail to run on a machine with an older glibc.
I ran into this last week — I wanted to install the neovim text editor from the official binary distribution, but because the project’s CI distro has a more recent glibc installed, the executable would fail to run on Ubuntu 18.04.
The learning effort thing is a solid point. I think what I play most these days is Super Mario World romhacks. Obviously the level design and whatnot aren't the same as the original, but the controls and physics are and I learned those as a fairly young child in the 90s.
The reason I don't like most other platformers almost definitely isn't because they're actually inferior, it's just because I'm "calibrated" to SMW
...which changes the economics of sending the spam email. Surely some of them will be "valuable" enough to send even with the added cost; however, a measure doesn't need to be 100% effective to be useful.
It's been a bit since I've added it to an existing project, but at least as of a year or so ago, the Rust implementation (tracing + tracing-opentelemetry + opentelemetry-jaeger specifically for that project) was similar.
The impact on compile time and code size wasn't bad (for a project that was large and already pulling in a lot of crates), but it had a huge runtime cost - mostly allocator pressure in the form of temp allocations from what I could see. For a mostly I/O bound workload, it more than doubled CPU utilization and ballooned OS-measured memory consumption by >30%
What? All you need to do is resubmit the request without a Referer header. For me, using Firefox, this meant clicking in the address bar, changing nothing, and hitting enter.
That's hardly "no ability to do anything about it".
I mean people with no ability to alter HN moderation policy.
Consider it like this:
1. I think, "oh, that looks relevant, let me open that link".
2. I get a screenful of objections to HN moderation.
3. I shrug and close the tab.
Since I'm just a normal user who can't change HN moderation, the outcome is that HN doesn't change but I walk away with a worse opinion of the Asahi Linux folks.
Weird: HN is supposed to be technical but the people behind Asahi Linux have proven themselves to be technical wizards; meanwhile HN seems more interested in money and pseudo-libertarian politics than transformitive technical excellence. But such is our age.
I have used it successfully against header files for Win32 COM interfaces generated from IDL which include major parts of the infamous "windows.h". Almost every type is a macro.
Not types, functions. Where the macro is essentially a forward declaration but the implementation is deep inside the code and is not exposed via headers.
You certainly can build a statically linked binary with musl libc (in many circumstances, at least), but it's not the default.
The default is a binary that statically links all the Rust crates you pull in, but dynamically links glibc, the vdso, and several other common dependencies. It's also, IIRC, the default to dynamically link many other common dependencies like openssl if you pull them in, although I think it's common for the crates that wrap them to offer static linking as an option.