💾 Archived View for bbs.geminispace.org › s › programming › 4583 captured on 2023-11-14 at 08:35:40. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-11-04)
-=-=-=-=-=-=-
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.
Aug 20 · 3 months 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.
🦀 jeang3nie · Aug 20 at 20:24:
@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.
🐉 gyaradong · Aug 20 at 21:12:
I'm with you on the community front. Really unfortunate and has me rethinking investing in the language.
🐉 gyaradong · Aug 21 at 07:13:
ok counterpoint: rust doesn't support abstract classes so you don't need to have stupid conversations with idiots.
🍵 michaelnordmeyer · Aug 21 at 07:57:
@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.
🍵 michaelnordmeyer · Aug 21 at 08:04:
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.
🦀 jeang3nie · Aug 21 at 13:59:
@gyaradong indeed!
🦀 jeang3nie · Aug 21 at 14:10:
@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.
🦀 jeang3nie · Aug 21 at 14:31:
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 ?
🦉 ResetReboot · Aug 22 at 12:37:
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.
@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/
i have been written similar comment recently in other thread (even 3 comments) but let me try to express myself again.
i am someone who was talking about safe programming and strong typing for at least 20 years.
we had ada, modula-2, modula-3, oberon, well even pascal freepascal or gnu pascal are much safer than c/c++ and these pascal implementations had modules.
nobody was even trying to use these languages.
today go is successful in part because it has google, and rust is successful in part because it has corporate promotion.
it is good that people started to care about safety. i personally like go (it is very much inspired of oberon, and i like oberon) and i personally dislike rust.
i dislike rust because it is slow to compile. it takes days on pinebook, and that is a bad sign for me. i don't want to use something that builds long. and i build everything i use on my laptops.
go builds very fast. the compiler itselg builds in 2 minutes.
my oberon compiler builds itself in seconds and most of the time is wasted by gnu tools behind it.
recently there was a thread on openbsd mailing list. why openbsd project would not write more in rust or rewrite some code in rust? and one of the answers was by theo - the founder and leader of the project: rust even cannot build itself on x86 because it needs more memory than 32 bit address space allows.
so i would say, if you are interested in modern and safe programming then
if you need libraries, big community, or master skills that can help to get a job then take a look at go - i am glad it exists.
i am not glad that rust exists.
otherwise if you want to tinker with interesting modern tech (even if it is from 80ies it is modern and some badly designed things today aren't, those are just contemporary) then take a look at ada (it is a big language for some people's taste) or modula-3. modula-3 is a small language which has everything programmers usually want: parallelism in language, exceptions, oop.
if you want even something smaller then oberon is a great language.
here as a side note some words about contemporary pascal. i dislike it because the de facto standard (not iso) was driven by a company, and it had to market it, add features, closely tie to an ide, etc.
i like that there is floss compiler fpc, and though it mostly (but not always) follows the language standard defined by a company behind delphi, it has many valuable properties and it is very underappreciated (though not as much as ada, modula and oberon).
you'll see in the table 5 (pareto optimal sets for different combination of objectives) that there is always c on the first line, but also there go twice and there is pascal three times.
time & memory: winners are: c, pascal go
energy & time: c alone
energy and memory: c and pascal (pascal is better than c if we take only memory usage)
energy, time and memory: all three share the first line; c, pascal, go.
you dont need anymore to change your program because underlying ui toolkit gets deprecated: community updates the lcl (lazarus component library) backend, lets say it also supports not only gtk2 but gtk3, or newer version of qt, you just recompile your program and you get a version which works with newer or different ui toolkit.