logo

blog

My website can't be that messy, right? git clone https://anongit.hacktivis.me/git/blog.git/

Rust sucks as a system language.xhtml (4385B)


  1. <article xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" class="h-entry">
  2. <a href="/articles/Rust%20sucks%20as%20a%20system%20language"><h1>Rust sucks as a system language</h1></a>
  3. <p>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)</p>
  4. <h2>There is no system libs</h2>
  5. <p>There is only Static Linking… another thing where a lot of stuff was thrown around, my take about linking is:<ul>
  6. <li>Dynamic Linking is great for shared libraries on a managed system so you can fix something once a for all</li>
  7. <li>Static Linking is great for distributing binaries on unknown systems (Netscape still runs with official static binaries today, it's hopeless with dynamic)</li>
  8. <li>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)</li>
  9. <li>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)</li>
  10. </ul></p>
  11. <p>Additionally as far as I know, there is also no shared location on the system for static libraries (<code>.a</code> files in C) nor source code either (instead of binaries it could be the source).</p>
  12. <p>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.</p>
  13. <h2>npm-like scene for libraries</h2>
  14. <p>In npm you often end up with way too much parts, <code>node_modules</code> directory in my install of mastofe has <code>1063</code> 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.</p>
  15. <p>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 <del>two</del> three ways I currently know on how Rust is packaged:<ul>
  16. <li>Network fetching by cargo: Applying it is going to be a mess but you have no reproductibility anyway so you could cheat a bit</li>
  17. <li>Fetch done by the packaging system: Applying the patch should be possible</li>
  18. <li>integrated in the tarball: Applying the patch might be a mess as they might have slightly modified the code</li>
  19. </ul></p>
  20. <h2>Extra: The main and only de-jure complete implementation is unstable</h2>
  21. <p>You probably heard it before "Rust has no specification", which means that <code>rustc</code> 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 <code>rustc</code> 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.</p>
  22. <h2>Conclusion</h2>
  23. <p>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.</p>
  24. <p>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.</p>
  25. <p><a href="https://queer.hacktivis.me/objects/330a87a6-a925-49a3-bbaf-146fd87ef3e3">Fediverse post for comments</a>, published on 2019-08-28T16:35:00Z, last updated on 2019-08-28T17:00:00Z</p>
  26. </article>