💾 Archived View for nytpu.com › gemlog › 2021-04-13.gmi captured on 2024-07-08 at 23:57:08. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

rust sucks, edition 42069

april 13, 2021

Yet another entry in the “rust sucks” book.

So, vaguely prompted by a conversation on the mailing listᵃ I decided to look at gemserv, a Gemini server written in rust.

We're going to be comparing Gemserv and Molly Brown, they're almost exactly equivalent in advertised features, but the former is written in rust and the latter is written in Go.

Gemserv's source

Molly Brown's source

First, let's look at gemserv. My computer was already tarnished with rust when I accidentally installed it as a dependency, so I decided to poke around in the package since cargo was already polluting my hard disk anyways. I decided to run a simple `cargo tree`, and oh my, what a mistake that was.

We're going to pause right here for a second and refresh ourselves on a few facts about Gemini's design. Gemini is a protocol designed around /simplicity/ (at least relative simplicity). It shouldn't take that much work to write a server or client. A basic but conformant client can be written in ~200 lines of C, and a server not much more than that. Going back to gemserv's dependency tree, just look for yourself:

[459.0kib] a screenshot of the output of `cargo tree`. the screenshot is comically tall, it was over three monitorfulls when i took it.

Why should something as simple as Gemini need over 100 dependencies?ᵇ

For reference, Molly Brown uses one (1) dependency, and it doesn't even have anything to do with the server itself, all it pulls in is a TOML parser for configuration!

molly brown's only external dependency.

Now, assuming you don't mind using excessive amounts of other people's unaudited code hosted in an npm-style ceramic vase of a registry, then you can excuse that, the code itself probably isn't using much of those libraries, any decent compiler will strip out all the extraneous stuff, right?

I've complained before about Go making massive fucking binaries. Even if you count in the runtime which adds some heft, the compiler just doesn't seem to be that efficient at stripping away unneeded stuff. The molly-brown binary is 5.8MB despite it being pretty simple code. However, the compiled gemserv binary is /36 fucking megabytes/! For something like a game where there's bundled assets that's reasonable, but in gemserv's case that is raw compiled machine code. What could even be in there to make it so massive is beyond my understanding. Rust has no runtime, how could the code itself be so massive?

UPDATE: YES I WAS USING A DEBUG BUILD STOP HARASSING ME ABOUT IT. I MADE ONE MISTAKE IT DOESN'T INVALIDATE EVERYTHING ELSE IN THIS POST

BTW the repo is over 500MB of source code when dependencies are vendored. Both the compiled binary and the vendored source code are significantly larger than the repo and compiled binary for my full-featured Qt application written in Go that I'm working on. How a full GUI app including bundled resources is smaller than a simple server for a simple protocol is beyond comprehension.

For a “““““systems programming language””””” rust certainly doesn't seem to have any of the qualities of one. No real architecture support beyond the most common desktop arches, massive binaries that would barely fit on anything with even moderately constrained sources. It certainly follows the web dev motto of “never write anything when you can pull in a random unaudited library instead” though.

[a]

[b]: excluding the top line saying the program name, that means that gemserv has 112 fucking dependencies. cargo tree deduplicates dependencies, so that's 112 /unique/ dependencies.

⁂

↩ go back to index

also available on the web

contact via email: alex [at] nytpu.com

or through anywhere else I'm at

backlinks