💾 Archived View for gemini.hitchhiker-linux.org › gemlog › mixed_feelings_about_rust.gmi captured on 2023-09-08 at 15:56:59. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
A few months ago, I wrote a blog post on my big-net blog giving some honest feedback about how I felt about the language after five years.
https://jeang3nie.codeberg.page/rust-criticism-from-rustacean/
Now, I was not intending for this post to see a wide audience. I have no way of knowing how many people read what I write there, but based on the lack of feedback I'd guess not many. This time, it was picked up by Rust weekly, from whence it hit HackerNews. You know how they say never read the comments? I read the comments, which were overwhelmingly negative of course.
Now I can deal with criticism just fine. Of course, had I known how many eyes were going to see it I would have spent more time on the post and fleshed out the ideas more. For instance, I devoted a section to griping about Rust's 'std' being dependent on libc, whereas it could have instead been made freestanding by implementing OS specific functionality through system calls. This was roundly criticized and dismissed out of hand by most people as too difficult to maintain because system calls change all the time (they don't actually) while providing little benefit. I could have pointed out that for every architecture that Rust supports on Linux, they are maintaining two separate builds and code paths for Glibc and Musl. I could have further pointed to Bionic Libc, Relibc, PDClib and a lot of other Libc implementations which can potentially work for Linux, and that those would then be supported platforms for Rust right out of the gate with no additional work. Hell, you could have the same toolchain work for both Linux and Android. People rightly pointed out that OpenBSD takes steps to disallow this. I know that already, and disagree with Theo DeRaadt on this particular choice, and it's also pretty easy to have your implementation use a libc backend for certain platforms while using syscalls everywhere else (Zig does this). Point being, my thoughts weren't expressed as well as I'd have liked, but they were definitely not half baked ideas without merit.
Another of my criticisms was Rust macros. I said flatly that they were a mistake. I stand by that. Zig's use of 'comptime' shows that a fully developed language and compiler level type reflection scheme can completely, and cleanly, replace not only macros but a lot of other metaprogramming pains. Generics are a breeze with good type reflection. You can move even more classes of bugs from runtime to compile time. Heck, the comptime concept enables Zig to have their build system written in Zig.
Now, around this same time, @thecompiler was getting ready to present a keynote address at RustConf. Certain members of the Rust core team took it upon themselves to turn this into an awful mess, by reaching out to the conference organizers and implying that the core team had decided as a whole that his talk was not a good fit for the keynote. Did I mention that @thecompiler was one of the editors of the C23 standard, and a massive presence in the programming community? He was insulted and it became a scandal.
I was aware of this scandal when I wrote that blog post, but not of the content of his aborted keynote. It turns out that his talk would have been about the work he had already started, with the intention of completing it and pushing it upstream, into adding powerful reflection capability to the Rust compiler. Basically, I would have loved to hear his talk, and I would have loved even more to see this added to Rust, because it could potentially make macros obsolete. The work is of course also aborted due to the scandal.
At this point I had a thought forming in my head, that perhaps my values are not in alignment with the values of the Rust project.
Fast forward to this week. A Fedora maintainer noticed that the serde project was shipping a binary with their source code. The binary is a pre-compiled version of the serde-derive code, which allows you to add serialization and deserialization to your own types using a big, ugly ball of macros. The reason for shipping this in precompiled form is that the macros just simply take too long to compile. Lots of people complained, loudly, on the bug tracker. The maintainer, DTolnay, basically just dismissed all of their complaints and closed the bug report. WTF?
If you follow my code output at all you may have noticed a significant dropoff in the past few months. There's a reason for this. I'm exploring options. I'm taking a real close look at other languages. Simpler languages. I've been spending a lot of time getting reaquianted with C. I'm not going to immediately throw out everything I've written in Rust, but I may at some point stop writing new code with it. I just don't see the language and community going in a direction I can be on board with.
The pattern that I've noticed, and can't abide, is that any ideas running counter to what the Rust project has decided to be the direction to go, or counter to something they've already put a lot of work into, get roundly dismissed and shouted down. There is also a pattern of the leadership, in whatever form it takes this week, making collossal PR blunders and then dissolving in favor of a new leadership model, which hums along for a little while and just as it's getting established repeats the same thing all over again. I know the language itself is not the community around it, but when you have really good ideas that you just aren't willing to listen to, that's a problem. It's even more of a problem when you're so opposed to contrary ideas being discussed that you torpedo the entire core team in order to block a conference talk because the ideas might mean something you worked on becomes obsolete. Fuck your hubris and ego, people. Leave them at the door.
All content for this site is licensed as CC BY-SA.
© 2023 by JeanG3nie