I love Rust to tears but it produces fairly huge binaries even in release mode and even with some symbols stripping.
So if Alpine also plans to include various Rust tools I'd hope that this will prompt the core team to also work on reducing the sizes of the final Rust binaries.
I don't want to sound entitled! I am very thankful to the entire Rust team. And Rust is hugely important nowadays. It's just that when it comes to distributing stuff in Dockerfiles (and fly.io, and several others) the Rust binaries stick out like a sore thumb. :\ They're fairly big.
If you do link rusts stdlib dynamically, then you end up with binaries that are equivalent to C++ binary sizes with an external libc++, where rusts stdlib is approximately the same size as libc++, and the release mode stripped binaries are also comparable (within ~1kb of each other, and in the range of 10kb for a standard unix pipeline style application which does some basic stream processing of IO).
It's my view that as deployment moves more and more to containers and even to the "microkernel + your app only" model then being able to fit binaries in CPU caches will become crucial for the viability of such cloud hosting. (Although to be fair, when we're talking about Rust + the Linux kernel, running something in 25ms vs 5ms can't be a huge deal for 98% of all apps, right?)
For comparison, without LTO and stripping I've had a fairly small hobby project easily compile to ~3MB and with them it's now ~800KB which is nearly 400% improvement. Nice.
I’m not saying they’re not small and haven’t done a fantastic job, but my impression is that this is due to being mostly minimal in the default install;
The reason I say this (and I could be wrong) is because the use of musl for the libc means each binary kinda needs to include it’s own libc statically.
This must make the binaries huge!
Also, you can easily make small rust binaries, it’s Golang (of the two) that produces very large binaries.
If you just follow the first two bits of advice from: https://github.com/johnthagen/min-sized-rust you’ll reduce your binary sizes to near C++ levels.
This is factually incorrect. Musl supports dynamic linking and if you run `ldd` on any binary in Alpine you can see that it dynamically links against musl libc.
I am simply wondering if this would prompt more interest in reducing Rust's final binary sizes, that's all.
This is such a great way to phrase this activity; I really hope it catches on with other projects.
Apart from that, I find it strange that people are so brazen with the whole "rewrite stuff in Rust" agenda.
As for the agenda of re-write everything in Rust, I cannot comment; as a software engineer I love re-writing things in my new favourite language of the day, so my judgement is clouded.
They used to, but these days they calmed down a lot, and most actively fight against the RIIR (Rewrite It In Rust) meme. I think part of it is because lots of people were exposed to low-level programming through Rust. I know that when I first started working with legacy/old code, I had the urge to rewrite everything. It took me some time to gain respect and trust in the code that was already running. On the other hand, sometimes my insights as a newcomer were valuable. It's a balance you have to strike between the new and the old, as with all things. Young people have the energy and new ideas, old people have the experience and stability. Both are needed. They'll sometimes clash against each other, but with time everyone will gain respect for the other party. I feel like it's what happened with the Rust community. These days it's less "rewrite everything in Rust!" and more "Rust is an option here. Does it makes sense? What are the alternatives?". The language is not even 10 years old at this point. Same thing for the community. They've already matured a lot.
My guess is this means “help fuel the advancement of…” but I’m having a slow day.
I get that there’s also a pun there I think?
Though technically oxidization can either strengthen or weaken a surface, so it's not a perfect phrasing, if so
Edit: https://wiki.mozilla.org/Oxidation is an example of the history of the term, though amusingly it doesn't show up on https://en.wikipedia.org/wiki/Rust_(programming_language)
There was a fair amount of back and forth about version pinning—it affected a lot of builds.
Even the issue on the crypto package about it was fairly tense. Iirc, the dependency was rolled back.
[1] https://github.com/docker/compose/issues/8105#issuecomment-7...
The OpenWrt community learned this the hard way.
I am fairly certain it was not, e.g. see this comment (or just notice that there's still rust code in the codebase)
https://github.com/pyca/cryptography/issues/5771#issuecommen...
(Edit: Changed link to a better one)
We did not roll back our dependency, no, although our current release (3.4.x) allows you to disable Rust compilation via an environment variable specifically so we could understand where in the ecosystem challenges would occur. Our next release (now 35.0 based partially on feedback from the community around our unusual versioning) will hard depend on it for all X509 ASN.1 parsing. During the months since we did our first rust release, however, the `musllinux` specification and implementation has been finished so we expect to be able to ship binary wheels for Alpine very shortly. I am actually working on that today, with the only remaining blocker being an update to warehouse to allow wheel upload.
The reason is that python is meant to run on Linux systems with glib, but Alphine has musl instead. It's a common source of compatibility issues not limited to python.
Note that pip wheels are only specified and only built for glibc compatibility, so the limitations extends to all python packages.
I’m struggling to see the benefit of moving from community to main. It seems more symbolic and geared towards making certain guarantees for end users, but it’s hard to grok that
I think this is about using Rust in the Alpine distribution itself and having core components actually use Rust.
Ansible is a python software and Python doesn't support Alpine.
If you mean binary wheels, PyPA packaging added support for Alpine wheels a few months ago (https://github.com/pypa/packaging/pull/411), and auditwheel support for the same just shipped today.
