💾 Archived View for bbs.geminispace.org › s › programming › 4583 captured on 2023-09-08 at 16:53:39. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
gemini://gemini.hitchhiker-linux.org/gemlog/mixed_feelings_about_rust.gmi
I've been using Rust for about five years now, but I'm beginning to sour on it. I'm curious about perspectives here.
2023-08-20 · 3 weeks ago · 👍 moddedBear, mediocregopher, DocEdelgas, gemalaya
Every time I try to use Rust, I find it complicated and unproductive. I feel like it "encourages" verbose, nuanced and heavily nested code (hard to read, many git conflicts), like C++, C# or Java.
@dimkr You're so right. The one thing i like about Rust is how performant it is.
@dimkr heavily nested is an interesting observation, and I agree. A lot of that has to do with Option/Result and the way Rust forces you to deal with errors or non-values immediately. I'm itself that's not a bad thing, but it does tend to move the code to the right.
I was hanging out on IRC last night and Drew Devault answered a question on #hare. The question was why the style guide specified tabs for indentation. He replied that it discourages code being nested too far. I find I love this answer.
I'm with you on the community front. Really unfortunate and has me rethinking investing in the language.
ok counterpoint: rust doesn't support abstract classes so you don't need to have stupid conversations with idiots.
2023-08-21 · 3 weeks ago
@jeang3nie My editor of choice has tab width set to 2 spaces. While I think Drew has a lot of good ideas, this one is quiete weak.
I prefer linter. You can have an agreement with your coworkers of how deep a nesting is allowed. If it's too deep, the build fails. And – very helpful sometimes – you can disable checking for a certain block of code, where less nesting would make the code less readable.
I don't like Rust. It's easy to write unreadable code, or to write code, which is much harder to read than it should be.
It helps to understand why Rust or any other language or framework exists.
Rust wants to be a memory-safe C++, and C++ is notorious for leading to harder to understand code. Go, for example, wants to be a memory-safe C, so it became a much simpler language in comparison.
Given a self-professed "clever" developer, Rust becomes a giant footgun which creates loads of technical debt.
@gyaradong indeed!
@michealnordmeyer that's a fair assessment with respect to how Rust and Go came about, and how it affected their development.
I wouldn't say the design becomes a footgun with a clever developer though. If anything, it makes it more difficult to be clever in that way. What it does do, in the hands of that sort, is create type signatures that span across the page and make it incredibly difficult to actually use an API. But "clever" devs don't usually last long with Rust in the first place.
I think there are two larger problems with using Rust, at least for the kind of programming I want to do, that didn't start coming into focus until I went back and starting using C again.
A lot of people complain about binary size when they come to Rust. That's with good reason, too. A simple "Hello World" in Rust, as of just now, comes in at 334128 bytes. In the case of a simple project that is down to compiling in the standard library statically, but the problem compounds as you grow your code, particularly when you add dependencies. There are multiple reasons for this.
Take traits and macros. Every time you use #[derive(Debug)] the compiler writes some code for you. What most people don't get is that when you manually implement the Display trait, the compiler is writing code on your behalf again, even without your knowingly invoking a macro, because there are generics involved in how Display works. Basically any time you implement one of the traits out of 'std' on your types you can expect a disproportionate increase in code size. I don't care for this. I'd rather have only the code I actually wrote.
The other issue I have is the friction you get when working on low level code that has to interact with the OS directly. Funny, but the official way to do most low level things is to use the libc crate. Memory safety goes out the window the moment you use ffi, and yet the moment you try to suggest this is bad there will be an angry mob of rustaceans with torches and pitchforks.
While I'm on ffi, allow me to point out a related gripe. Since Rust is still calling into libc under the hood everywhere in 'std', and the vast majority of Rust devs are using x86_64 Linux with Glibc, by default every other platform is a second class citizen with lots of potential for undefined behavior and regressions on every compiler upgrade. I've seen it plenty of times, and the problem compounds the more you use ffi. It's why I haven't done much with Eva in a long time. I got tired of my code compiling perfectly fine, but on Void with musl it would immediately segfault as soon as Gtk is initialized. Things like that get old.
@jeang3nie What I meant is, nesting is a problem when it makes the code less readable, reduces the team's development velocity and makes it harder to collaborate (when it creates conflicts). When the language encourage nesting, it encourages bad patterns I usually see in code written by people who use C++/Java/C#, or grew in that culture, which sometimes emphasizes 'elegant' OOP and heavy use of namespaces/classes/try blocks/... over readability or easy collaboration.
@gemalaya In many projects, performance doesn't matter enough to make big sacrifices in development velocity, ease of collaboration with new people and general developer experience (good documentation, tooling, stable ecosystem, etc').
@dimkr I agree. What's your favourite language ?
I've just read your article after finding a YT video about Rust... and while it started pretty well... they lost me the moment the guy at the video says "You can write everything in Rust".
Hm, yeah, the same was said of JS, C, C++... and we all know, that not all problems are nails. It made me think "What kind of people are the so called rustaceans" and your article just made my suspicions right.
And yes, the community is important, specially the attitude of the language developers, in how the language itself evolves.
2023-08-22 · 2 weeks ago
@gemalaya I think it's Go. It's not perfect but I love it for various reasons (most of them translate into good productivity) and I have success stories with it at work. I use it when I can compromise on executable size and sacrifice some performance (i.e. when I can't just minimize memory allocations, etc' in hot paths) to gain easy collaboration, easier development overall and a good performance+scalability vs. attention to detail ratio (especially when I mentor a junior developer). Most of my toy projects, including my Gemini client, are still in C I think I should fully translate at least one to Rust (or zig?) instead of giving up at an early stage.
@dimkr Cool. I have nothing bad to say about Go, one of my favourite projects, kubo (IPFS implementation) is written in Go.
I'm into GUI development, this is what i wrote recently (Gemini browser written in QML):
https://gemalaya.gitlab.io/