This whole ideology of "the user should get all their software from their Linux distribution" and it's implicit consequence: there's no clear difference between system software (internal tooling) and application software installed by the user (Audacity and friends) should just die already.<p>I want my OS to just provide a decent interface over which I can install application packages myself, packages that I get from my own sources, just like on Windows. if those packages are statically linked, fine. I know most Linux users disagree, but I don't want the relationship between software vendor and user to be distorted by some distro maintainer, or having to be limited to a package manager. I want to be able to store application installers in my filesystem.<p>I also want my distribution to hide it's Python binary from me so I can install my own Python without breaking the OS.<p>Basically: stop assuming that I want to live under your wing. I just want you to give me a nice desktop environment, a terminal and a well docomented way to install third party software.<p>I know distro developers don't owe me anything, and it's fine if they do something else, but this is the actual reason why Linux isn't used in the desktop.
The article is pretty interesting and I learned quite a few things, but it looks like the author is knowingly not answering the issue they raise by themselves.<p>In my opinion, the most important thing distros does that is incompatible with how rust currently works, is handling security/bug updates.<p>The one libjpeg.so for everyone is meant to fix libjpeg flaws for everyone. And it has many security flaws. And it has many users. There is no denying the way this is done by distros is good.<p>Now, to pick author's code, one of its dependency is a CSS parsing, which is prone to flaws. (Maybe not /security/ flaws, but still) The question is, how is the distro supposed to handle that?<p>I know rust has tooling for that, but it seems to me that with the perfect version match crate build system, every dependency will happily break API. So let's say author no longer has time to develop rust librsvg, and cssparser crate has a major flaw, which is fixed only in a new API rewrite branch, then what? Distro are supposed to fix that themselves? Sounds like much more work for them.
This is a bunch of nonsense. Rust prefers static linking because it is predictable. These supposedly "huge" binaries are laughably small on a modern >1TB hard drive. If you're building a tiny embedded system, by all means optimize your builds system-wide, you have total control! But for a desktop, is this really a concern?
Wouldn't it be possible to have a C-like language that is somewhat backward compatible with C, and have the nice security features of Rust?<p>I get that Rust is awesome, but I'm not certain you need to make an entire new language just to have the security stuff.<p>Of course it might be complicated to do, but in the end, aren't there linters or other validators that can give the same security results rust has, but with C or even C++?
Not an expert, but if you want a stable Rust-to-non-rust ABI, you can use the C ABI as the article mentions. If you want a stable rust-to-rust ABI for FFI there's a crate for that
<a href="https://crates.io/crates/abi_stable" rel="nofollow">https://crates.io/crates/abi_stable</a><p>It seems somewhat unrealistic to expect a really new language commit across the board to the same sort of ABI stablility as a decades-old language such as C.
With everything slowly( or sometimes rapidly) moving into containers (docker, systemd portable services, flatpak, snaps) I think the concept of system library will probably become irrelevant at some point not that far into the future.
> While C++ had the problem of "lots of template code in header files", Rust has the problem that monomorphization of generics creates a lot of compiled code. There are tricks to avoid this and they are all the decision of the library/crate author.<p>Is there any research on having compilers do some of these tricks automatically? A compiler should, at least in principle, be able to tell what aspects of a type parameter are used in a given piece of code. Such a compiler could plausibly produce code that is partially or fully type-erased automatically without losing efficiency. In some cases, I would believe that code size, runtime performance (due to improved cache behavior), and compile times would all improve.
In a way I'm happy rust does not have a stable abi. Swift does, but the stability is 'whatever apple swift emit'. Very little documentation, that what's there is out of date, so the only practical language that can interact with swift is swift. To be able to interact from another language, one would have to parse swift, make the semantics of all types and generics match exactly to be able to do the simplest things. (For example array and string, two core types are stock full of generics and protocols)<p>I'd hate to have the same happening for rust.
It might simply be the time to invent a more modern ABI.<p>If for some reason modern languages insist on monomorphization, we should be able to design an ABI that suits that need.<p>Rough sketch:<p>A modern shared library is code that generates code (very much like a dynamic linker is actually code that links code).<p>The interface of the library would consist of:<p>a) a description language for the shape of data types (not types themselves, mind you)<p>b) a list of generators for functions<p>c) a list of function applied to shapes as a requirement<p>The job of the modern dynamic linker would then be to invoke all the functions to the necessary shapes, put the resulting code into memory and link it. It might be useful to support this with some kind of caching mechanism.
There's a lot of either/or false dichotomy being discussed in here. Distro packaging (or not) comes with various tradeoffs of course, some good or bad depending on perspective.<p>To get to the point, I quite prefer the package manager way of installing software to "hunt down a single release" app installers of Windows/Mac. The only issue is that sometimes software is a bit out of date. That's what the snap/flat pack/appimage projects are trying to solve.<p>As soon as one of those three get their user-hostile issues fixed, it will be a software paradise. :D
The optimized and stripped library in rust was about 8 times the size of the C version. While 9MB is not a lot by itself, if a significant portion of libraries decide they want to switch to rust that would explode disk usage!<p>Though I think my problem with rust is that they make breaking changes in their compiler and spec every release. People regularly building on rust unstable to get features not yet released. This all makes things complicated for a distro.<p>But the points at about making breaking changes at the bottom resonated with me. Stability is what has allowed the Linux ecosystem to grow so well. Many interconnected parts all moving in unison. Not being able to fix a bad design decision because of this does suck. Still, having everything work and sadly is more important than perfect design.
Why are people even using Rust and Go, aside from employer say-so? They're not formally defined, there aren't multiple functioning implementations, it's just not a good idea.
Two issues with the post:<p>- An ABI is not a PL feature, but a platform feature, I.e., it is not that Rust does not have a stable ABI, but that eg Linux does not have a stable ABI for Rust (it has one for C and you can use this ABI from Rust).<p>- You can export generic Rust APIs with a stable C ABI by using trait objects, and it is often very easy to do this. So the claim that Rust and C++ are on the same boat wrt generics / instantiations is not true.
Off-topic but it seems the quotes around the title don't render on the front page, but they do render on this page? It flips the entire tone of this article.<p>Initially on reading the title I just eye-rolled, but clicking through and seeing it was a response to that, and was actually the quote in quote marks made much more sense!!
"Why do distros expect all the living organisms on your machine to share The World's Single Lungs Service, and The World's Single Stomach Service, and The World's Single Liver Service?"<p>This has been debated for years, and parts of the answers is right above. Also, software is not a collection of biological organisms. And the local variables are not shared, so WTF anyway. The analogy makes no sense. Everybody is already neatly separated.<p>Proponent of everything static have yet to show non toy / very specialized systems where everything is actually static.<p>Let's avoid the strawman anyway and in this case, yes, some static linking can have its use, especially for some small utility / metaprog / etc. packages, although it has and will always have drawbacks to, especially for higher level feature support (e.g. a codec). You have to go into the specifics to understand which are more important depending on the context. Probably a mix is needed.<p>For a Linux distro, I suspect some people will go crazy if the fix for a security vuln of a small piece of code ends up downloading hundreds of MB, but maybe there are advantages so great that this is something we can live with. The net perf impact is extremely hard to predict and measure. You will duplicate tons of code, but arguably e.g. the cache overhead might not be extremely bad, we now have tons of memory, so maybe we can waste some, etc.<p>Note however that if a Linux distro is competing with other kind of plateforms, there is the risk to put the Linux distro at a disadvantage if the static vs. dynamic (maybe on a package per package basis) is chosen improperly, because other platforms make the distinction between platform and application, their platform typically provides a very large API, and they won't go the insane way and switch to static.<p>The lack of proper dynamic linkage story for Rust is a problem that needs to be fixed to enable some kind of usages. Not something that can always be worked-around (sometimes it can, and for some crate you really want static to begin with anyway)