Rust sucks as a system language

I've been ranting against rust on social media from time to time and I quite want to put down why I just basically ban rust and specially consider it harmful as a system language, by that I mean stuff like libraries, as I might have to grow okay with rust for applications… (or maybe not, for now I'm ignoring update/new stuff done in rust, specially with rust as an argument)

There is no system libs

There is only Static Linking… another thing where a lot of stuff was thrown around, my take about linking is:

• Dynamic Linking is great for shared libraries on a managed system so you can fix something once a for all
• Static Linking is great for distributing binaries on unknown systems (Netscape still runs with official static binaries today, it's hopeless with dynamic)
• Static Linking isn't well integrated in packaging systems (it's more often used for a minimalist rescue system, which tends to be a completely separated system)
• Dynamic and Static Linking have both points for security and it all goes down if the system/environment is controlled or not (and any code in a broken environment is going to be broken anyway)

Additionally as far as I know, there is also no shared location on the system for static libraries (.a files in C) nor source code either (instead of binaries it could be the source).

So we end up with applications packages that are easy to spread out but difficult/impossible to maintain in the long term… I would call that a virus, good or evil.

npm-like scene for libraries

In npm you often end up with way too much parts, node_modules directory in my install of mastofe has 1063 modules, this is basically the amount of stuff you get on a basic (but not minimalist) Linux system. Rust has a quite similar way of ending up with a pile of dependencies for a simple application.

Now I want you to imagine that there is a patch or bump to be done on a library almost everyone uses, it will have to be applied on each dependent of the software (see previous section), which is probably going to take a very long time (like 2 weeks for a slow validation of a package maintainer and add a bit of QA testing time), there is two three ways I currently know on how Rust is packaged:

• Network fetching by cargo: Applying it is going to be a mess but you have no reproductibility anyway so you could cheat a bit
• Fetch done by the packaging system: Applying the patch should be possible
• integrated in the tarball: Applying the patch might be a mess as they might have slightly modified the code

Extra: The main and only de-jure complete implementation is unstable

You probably heard it before "Rust has no specification", which means that rustc is the de-facto only implementation of rust, the rest is something similar to reverse-engineering (like clang/LLVM has to do on some GCC extensions but it's the whole language instead). It also happens that rustc tends to break a lot, I often end up editing it's code for it to work with LibreSSL or other C issues almost no software has these days, funny for a language which tends to be branded as a C replacement.

Conclusion

So we end up with code than cannot be realistically be updated in a timely manner for security, yet there is C/C++ libraries moving to Rust (with a Foreign Function Interface to keep API compatibility), I would quite appreciated if libraries wouldn't do that of all the things.

Also, there is nothing in here specifically about the language, I didn't learn it, I don't consider it to be something I would want to use. Go has been in the same position for me until the modules came and I'm quite glad there is a more high-level language which is great with networking and parsing because for me that's been a pain point in C.

Fediverse post for comments, published on 2019-08-28T16:35:00Z, last updated on 2019-08-28T17:00:00Z