24 comments

[ 3.7 ms ] story [ 43.7 ms ] thread
I'm not sure if I agree that Rust crates overdo abstraction.

Coming from a Java world with heavy use of annotations and their behind the scenes magic I fear the Rust world that overuses macros.

Don't get me wrong. I understand that the way annotations work in Java is quite different from macros in Rust and you don't need to convince me that Rust macros are a ton better and cleaner and more useful while in a sense being even more lightweight.

I still dread a world with Rust becoming like Java where complicated and impenetrable magic is considered a virtue and not a sin. The main enabler to this is in my opinion is the overuse of macros, as wonderful and magical as might be.

You can already get a Spring like experience in Rust, it is a matter to look on the right place, see Dioxus.

However you will miss the STS tooling.

This feels like it was written by an LLM.
This story reminds of Scala. The language as such is also fine, but has (had?) a cultural problem. There functional programming fundamentalists always promoting the purest solution without solid reasoning - as if god had decided that only pure functional programming is your ticket to paradise. In addition, Scala comes also with powerful language features to build abstractions, like traits, generics, and almost arbitrary names for classes, objects, and functions. All that lead to a culture of unreadably "try to be clever" code. I'm not sure whether the Scala authors paved the way with methods like :\ (fold left) or whether that happened, because the language had the features, but I tend to assume the latter. It is a great responsiblity of a language designer to think about what others might do with the language later. Regarding language features the rule "when in doubt, leave it out" applies. See Go (although not my favorite language).
As I mentioned on another comment, I think there are many Haskell and Scala refugees that eventually migrated to Rust, bringing the same culture.
my hot take is, its because rust is dominated by hobbyist level and not serious work. You get libraries where people are just messing around. Or tbh often don't have experience be writing the libraries they are trying to. That causes you to also to run in to the online community more often, because everything is developed out in public.

i write rust sometimes, python and go mostly. i never even think about "the community" when i use python and go. but so much online stuff seeps into the rust user experience, through libraries and tooling.

I stopped using Rust because of this. I spent more time learning and cursing at other people’s abstractions versus thinking about what the computer is doing.

> the ones who’d use Zig if it weren’t allergic to syntactic sugar

You’re very close to understanding why some people prefer Zig. There is a correlation between language design and how things are built with it.

Personally I find it hard to read thirdparty code written in Rust, maybe because this language requires using traits and trait bounds, where an easier language like C++ can use templates with duck typing.
The article is okay, but the writing is bad chatgpt. Em-dashes in almost every sentence instead of commas. Out of place analogies and metaphors which barely make sense. Randomly sprinkled slang for an audience of teenage redditors.
> But the thing is – nalgebra isn't an isolated example. It’s cultural.

classic llmism

Is there a way in rust to see the "desugared" rust code, e.g. with all macros, traits, generics etc expanded? I feel this would be helpful to cut through the abstractions.
Kind of, some of the stuff you can see on Rust Playground.
> Obviously I don’t understand every library I use – that’d be absurd

Hey, that's a neat idea.

What if we could make a whole useful system that one single person can understand completely down to the bottom (in a single lifetime or less)?

Doesn't mean you have to understand it, but a system that you could if you wanted to. If possible, also, something familiar (in contrast to an esoteric TempleOS like thing).

I read this and the entire time I was thinking of clap. There must be a lot of complexity about parsing arguments that I do not understand, but man can that one library slow down compilation and add heft to the binary size.
Had the same feeling browsing through the Haskell package collection. Felt like and almagamation of PhD theses, none of which were maintained after the author got his degree. Every single one a work of art, but most engeneered so badly that you would only use them begrudgingly.
> And then you hit that moment – you're debugging, you hit "Go to Definition", and suddenly you're free falling through ten layers of traits, macros, and generics just to figure out how a buffer updates.

This isn't unique to Rust. I find exactly the same thing about C++. I will often have to wade through 8 layers of constructors to find where some field is set.

However, I wonder if the "Orphan Rule" makes it worse in Rust. It is not uncommon for you have to create a trivial "newtype" to wrap something because of the orphan rule. A couple of layers of that and you've got an impenetrable mess on your hands.

> over-engineering in Rust is incredibly fun.

TLDR this is the real reason

Anyway I don't use Rust and I just learned that writing generic code is more complicated. It's interesting because in Julia generic code is the simple path: just don't add types and it's generic. Multiple dispatch is a powerful idea and I wish more languages adopted it.

Because many are Haskell or Scala refugees, Rust is more mainstream for their goals, previously that would be the crowd doing C++ metaprogramming with SFINAE and tag dispatching.
The author answered himself:

> Want to do something slightly off-script? That’ll be three trait bounds, one custom derive, and a spiritual journey through src/internal/utils/mod.rs

An alternative is: you want something off-script, go fork the repo with the crate and patch it to accept your use case.

The article isn't wrong, but the focus on Rust is misleading. It isn't a Rust thing. It's a programmer thing, particular an open source programmer thing. Try looking at some of the Python libraries, like Spyne, that rely heavily on introspection some time. Or even React. JSX is accepted not, but at one time mixing HTML and Javascript sounded like a proposal to make a petroleum milkshake. It's happens in every language.

The C obstrufication contest makes an artform out of it. I think that's apt, and honest. Many open source projects are a form of art. People create to art say something about themselves. What better way so say how inventive you are, than to find a novel way to use the programming language?

I'm guilty of it myself. But once I got it out of my system and look back, I have to agree with the author. While these novel constructions are fun to create, that are pain in the arse for others to learn and even worse to maintain.

I don't think that Rust encourages it any more than any other language. The author should try looking at the sins Lisp's macro's and Python's meta classes enabled. Well, except for Rust's macro's. I suspect creative use of Rust's macro's would make the C obfuscation contest look like kindergarten artwork.

Justed wanted to say that it is usually very hard for me to read lengthy articles until the end without getting frustrated. However, I have to say that I have found this post very well written and captivating, and I read it to the end with not effort at all.