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.
I share this fear. Rust macros are _amazing_ and indispensable but their overuse makes understanding third party code extremely difficult. There are cases where macros are used to avoid repetition, I feel like code generation makes more sense here, where crates publish expanded syntax.
My other fear is the fragmentation of standard interfaces. AsyncRead and AsyncWrite are prime examples. If you build an http server you end up using tokio's AsyncRead AND futures AsyncRead - then a bunch of glue code to make them compatible with each other.
I'd love to see the standard library reinforced with crates that are basically default installs for their use cases. Tokio, futures, http, httpparse, maybe a variant of anyhow.
Much of futures' functionality is now in the standard library (core::future). Tokio is quite heavy, and I don't like it: smol is a better "futures standard library", in my opinion. There's async-compat if you need to interop with tokio, so I never have to write glue code (even if I'd rather not have a tokio runtime).
I'm with you on Tokio. I have tried alternative runtimes however the constant interop issues is a very poor developer experience, and difficult to justify when other developers are contributing.
Using hyper with streamed http responses (which depends on tokio::duplex). You're already depending on the futures and async-compat crates to adapt tokio futures. I don't even know how hyper could be set up to use another async backend or what performance penalty another adapter layer would have on performance.
> Much of futures' functionality is now in the standard library (core::future)
In that case, I would love to see Tokio move to depend on the stdlib interfaces rather than exporting their own lookalikes. That way runtimes can be interchangeable. I guess the same goes for utils like task::sleep, channels and fs interactions.
Tokio is fast, but it's huge! Check the size of any library or binary that includes tokio with even minimal features, let alone their recommended default feature set which comes with a complimentary kitchen sink.
If it were dynamically-linked, I'd be more okay with it – but it's statically linked, so every process in memory has its own copy, with slightly different layouts of various structures.
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.
My impression of Rust crates is that most are developed because a standardized solution to the problem didn't exist or didn't meet the author's needs, so they built their own. Many are well designed, but were never used by enough people to become truly usable or robust before they were abandoned.
It seems like outside certain problem domains, there isn't any effort to pool resources to keep projects alive. The few I did find were forks of forks where each subsequent maintainer stopped responding to proposed changes.
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.
If you care about endashes then you'll know that they're not supposed to be used to separate ideas in a sentence, that's what emdashes are for. That makes me think it's not LLM generated because LLMs know how to use emdashes.
Indeed. In English it is an em-dash. Not brackeded by spaces, although you should bracket by thin spaces to make sure you get some separation, optically. And line breaks in apps that are unaware this is a separator.
In many other languages ideas are separated by en-dashes (surrounded by spaces).
In the case at hand the use of en-dashes in English text instead of the correct em-dashes could also be a sign of a non-native speaker caring about micro-typography and just doing the wrong thing. :)
The LLM conclusion doesn't seem well supported either way.
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.
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.
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.
I find it easier to read code that uses Rust generics with trait bounds, since then I have a clear answer about what types it is generic over. Recently I was using a Thrust (CUDA library) function for the first time and I wanted to know what types, exactly, could be accepted as a parameter type to a callable. The docs¹ were not useful, since they only addressed the output type of the callable. I had to ask an LLM and then fact check its sources. This is a much less convenient experience than the information being mandatory in the function signature like in Rust.
C++ optimizes happy path - if you provide an expected type to a piece of template code, all works fine, but if not - you get terrible error messages. Rust requires more boilerplate on happy path, but provides useful hints in case of compilation errors.
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).
This seems to be an antiquated view on Scala and the people working on it and it's tooling. Referring to :\ as foldLeft suggests the parent hasn't seen Scala code since 2018 and scalaz which is nowhere to be found nowadays. I've been working professionally with Scala since 2019 and have never come across the symbol soup that was scalaz.
Programming language choice is a matter of taste to a large degree so it's possible the different people value different traits of languages.
"When in doubt leave it out", is a design decision that can be taken to extremes in some cases and many of us feel crippled and don't enjoy such languages. There can be languages that provide powerful abstractions and rely on its users' trust to use them appropriately. Of coyrde, like every tool it can be misused but that should not be the baseline we use for comparison. Because surely we can find dreadful code in every language.
As a closing paragraph I'll just say that Scala 3 is very nicely designed language that simplifies a lot of the sticky point with Scala 2 and allows for a nice blend of OOP and functional programming. Functional programming in Scala is opt-in and progressive and is a good choice for greenfield projects on the JVM. Also a final note, tooling for Scala and Scala 3 specifically has improved a lot to the point where it just works without arcane invitations of the past. Overly confident opinions to the contrary for people who haven't touched the language since 2018, scala 2.11 and sbt 0.13 are quite out of touch.
I worked in Scala for a little bit and while it is mostly a fine language there are a couple huge problems; the big two off the top of my head are the return statement (legitimately the most wtf moment I've had learning a language???) and implicits (this one is more of a me problem but I really dislike implicits, both the variable passing in and the implicit constructors).
This resonates. I spent a fair bit of time thinking about library design for an OCaml library that didn’t directly expose more complicated language features (like functors and first class modules) where they weren’t needed.
I also find languages like OCaml avoid a lot of this nonsense in their libraries because the ability to build layers and layers of complex abstraction isn’t there in the same way as Haskell, Rust, or any of the LISPs
> 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.
Was curious, so I tried it in several different AI detectors to see what they returned.
Most seemed to believe it was approximately 2/3 AI generated text. Primarily the first several paragraphs. Last, and second to last scored the best as "human". ZeroGPT said it was only 5% likely AI written. Couple sentences.
Not sure if that means its actually AI written, cause there's lots of argument about false positives. Also, it's software. In many ways it seems like a lot of that field / genre produces articles and writers that then have a very "structured" writing style. Read a lot of HN. Write articles that place on HN. Tailor your writing style so it gets upvotes on HN.
It's very similar to the Youtube issues, and people making their intro, thumbnail, and splash screen before even considering article content much. Mr. Beast had a leaked article on the subject. Lots of SEO, Click-Thru-Rate, Average-View-Duration, ect... [1]
It was. You can compare to the author's first blog post, which doesn't have any of the classic LLM giveaways.
I suppose "coauthored" is a more charitable word though. This article wasn't as bad as most slop. I imagine the author passed it through Grammarly or something.
Once you have some experience, phrases like this are a dead giveaway: "and honestly? It’s incredible to watch". Also 30 em dashes in almost as few sentences.
>The real tragedy? Once you see it, you start writing that way too. You start thinking, "Well, maybe I should make this generic in case someone wants to use quaternions instead of matrices..." and suddenly, congratulations – you're building for someone who doesn't exist.
is awful similar to LLM writting. I can't put my finger on exactly where, but that the impression i got.
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.
For generics, no, but you can query this information in your IDE pretty easily. You can also also use `cargo doc` to build the generated documentation, which will show you the list of traits something implements.
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.
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.
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.
> 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.
> 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).
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'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.
> I fear the Rust world that overuses macros
I share this fear. Rust macros are _amazing_ and indispensable but their overuse makes understanding third party code extremely difficult. There are cases where macros are used to avoid repetition, I feel like code generation makes more sense here, where crates publish expanded syntax.
My other fear is the fragmentation of standard interfaces. AsyncRead and AsyncWrite are prime examples. If you build an http server you end up using tokio's AsyncRead AND futures AsyncRead - then a bunch of glue code to make them compatible with each other.
I'd love to see the standard library reinforced with crates that are basically default installs for their use cases. Tokio, futures, http, httpparse, maybe a variant of anyhow.
Much of futures' functionality is now in the standard library (core::future). Tokio is quite heavy, and I don't like it: smol is a better "futures standard library", in my opinion. There's async-compat if you need to interop with tokio, so I never have to write glue code (even if I'd rather not have a tokio runtime).
I'm with you on Tokio. I have tried alternative runtimes however the constant interop issues is a very poor developer experience, and difficult to justify when other developers are contributing.
Using hyper with streamed http responses (which depends on tokio::duplex). You're already depending on the futures and async-compat crates to adapt tokio futures. I don't even know how hyper could be set up to use another async backend or what performance penalty another adapter layer would have on performance.
> Much of futures' functionality is now in the standard library (core::future)
In that case, I would love to see Tokio move to depend on the stdlib interfaces rather than exporting their own lookalikes. That way runtimes can be interchangeable. I guess the same goes for utils like task::sleep, channels and fs interactions.
Heavy in terms of lines of code, or overhead? Where does that come from? Do you have some numbers?
Tokio is fast, but it's huge! Check the size of any library or binary that includes tokio with even minimal features, let alone their recommended default feature set which comes with a complimentary kitchen sink.
If it were dynamically-linked, I'd be more okay with it – but it's statically linked, so every process in memory has its own copy, with slightly different layouts of various structures.
Does everything get included though? I'd assume unused stuff is compiled out.
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.
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.
My impression of Rust crates is that most are developed because a standardized solution to the problem didn't exist or didn't meet the author's needs, so they built their own. Many are well designed, but were never used by enough people to become truly usable or robust before they were abandoned.
It seems like outside certain problem domains, there isn't any effort to pool resources to keep projects alive. The few I did find were forks of forks where each subsequent maintainer stopped responding to proposed changes.
haskell
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.
These are 'en' dashes. Myself and and other people who care about (micro)typography have been using them since forever.
Presumably the author is one of them. Or they simply use a text editing or blogging software that takes care of it.
E.g. Markdown with smarty-pants feature turned on generates them automatically from '--'. 'Em' dashes require '---'.
Coincidentally Rust's `cargo doc` does this for you -- just for example.
The conclusion that a text containing such micro-typographic niceties must be LLM-generated is a fallacy thusly.
Your other 'evidence' sounds like an interpretation to me. Maybe you should quote the sections you mean?
Otherwise your critique seems superficially limited to form, not contents -- an ad-hominem in disguise one may be tempted to conclude.
If you care about endashes then you'll know that they're not supposed to be used to separate ideas in a sentence, that's what emdashes are for. That makes me think it's not LLM generated because LLMs know how to use emdashes.
Indeed. In English it is an em-dash. Not brackeded by spaces, although you should bracket by thin spaces to make sure you get some separation, optically. And line breaks in apps that are unaware this is a separator.
In many other languages ideas are separated by en-dashes (surrounded by spaces).
In the case at hand the use of en-dashes in English text instead of the correct em-dashes could also be a sign of a non-native speaker caring about micro-typography and just doing the wrong thing. :)
The LLM conclusion doesn't seem well supported either way.
[dead]
> But the thing is – nalgebra isn't an isolated example. It’s cultural.
classic llmism
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.
> There is a correlation
Precisely, same for Go. Incentives decide outcomes.
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.
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.
I find it easier to read code that uses Rust generics with trait bounds, since then I have a clear answer about what types it is generic over. Recently I was using a Thrust (CUDA library) function for the first time and I wanted to know what types, exactly, could be accepted as a parameter type to a callable. The docs¹ were not useful, since they only addressed the output type of the callable. I had to ask an LLM and then fact check its sources. This is a much less convenient experience than the information being mandatory in the function signature like in Rust.
1: https://wmaxey.github.io/cccl/thrust/api/function_group__tra...
C++ optimizes happy path - if you provide an expected type to a piece of template code, all works fine, but if not - you get terrible error messages. Rust requires more boilerplate on happy path, but provides useful hints in case of compilation errors.
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).
This seems to be an antiquated view on Scala and the people working on it and it's tooling. Referring to :\ as foldLeft suggests the parent hasn't seen Scala code since 2018 and scalaz which is nowhere to be found nowadays. I've been working professionally with Scala since 2019 and have never come across the symbol soup that was scalaz.
Programming language choice is a matter of taste to a large degree so it's possible the different people value different traits of languages.
"When in doubt leave it out", is a design decision that can be taken to extremes in some cases and many of us feel crippled and don't enjoy such languages. There can be languages that provide powerful abstractions and rely on its users' trust to use them appropriately. Of coyrde, like every tool it can be misused but that should not be the baseline we use for comparison. Because surely we can find dreadful code in every language.
As a closing paragraph I'll just say that Scala 3 is very nicely designed language that simplifies a lot of the sticky point with Scala 2 and allows for a nice blend of OOP and functional programming. Functional programming in Scala is opt-in and progressive and is a good choice for greenfield projects on the JVM. Also a final note, tooling for Scala and Scala 3 specifically has improved a lot to the point where it just works without arcane invitations of the past. Overly confident opinions to the contrary for people who haven't touched the language since 2018, scala 2.11 and sbt 0.13 are quite out of touch.
Given that Zio and Effects are all the rage of topics in what is left of Scala userbase, I would say the opionion is not wrong.
Metals and InteliJ still have issues with Scala 3, and Eclipse plugin is stuck in Scala 2.
As I mentioned on another comment, I think there are many Haskell and Scala refugees that eventually migrated to Rust, bringing the same culture.
I worked in Scala for a little bit and while it is mostly a fine language there are a couple huge problems; the big two off the top of my head are the return statement (legitimately the most wtf moment I've had learning a language???) and implicits (this one is more of a me problem but I really dislike implicits, both the variable passing in and the implicit constructors).
This resonates. I spent a fair bit of time thinking about library design for an OCaml library that didn’t directly expose more complicated language features (like functors and first class modules) where they weren’t needed.
(I presented on it recently: https://www.chrisarmstrong.dev/posts/icfp-wrapup-2025-10-18)
I also find languages like OCaml avoid a lot of this nonsense in their libraries because the ability to build layers and layers of complex abstraction isn’t there in the same way as Haskell, Rust, or any of the LISPs
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.
This feels like it was written by an LLM.
Was curious, so I tried it in several different AI detectors to see what they returned.
Most seemed to believe it was approximately 2/3 AI generated text. Primarily the first several paragraphs. Last, and second to last scored the best as "human". ZeroGPT said it was only 5% likely AI written. Couple sentences.
CopyLeaks, 61.9%. https://app.copyleaks.com/dashboard/v1
GPTZero, 80%, 64/80 sentences. https://gptzero.me/
ZeroGPT, 5%. https://www.zerogpt.com/
Not sure if that means its actually AI written, cause there's lots of argument about false positives. Also, it's software. In many ways it seems like a lot of that field / genre produces articles and writers that then have a very "structured" writing style. Read a lot of HN. Write articles that place on HN. Tailor your writing style so it gets upvotes on HN.
It's very similar to the Youtube issues, and people making their intro, thumbnail, and splash screen before even considering article content much. Mr. Beast had a leaked article on the subject. Lots of SEO, Click-Thru-Rate, Average-View-Duration, ect... [1]
[1] https://www.businessinsider.com/mrbeast-how-production-team-...
It was. You can compare to the author's first blog post, which doesn't have any of the classic LLM giveaways.
I suppose "coauthored" is a more charitable word though. This article wasn't as bad as most slop. I imagine the author passed it through Grammarly or something.
What makes you feel this way? I did not get this impression.
Once you have some experience, phrases like this are a dead giveaway: "and honestly? It’s incredible to watch". Also 30 em dashes in almost as few sentences.
Those question marks? The ones that don't mark questions? Only intonation? I could live without them.
But it was nice to learn a little bit more about why I wouldn't like Rust.
Not parent commentors, but this part
>The real tragedy? Once you see it, you start writing that way too. You start thinking, "Well, maybe I should make this generic in case someone wants to use quaternions instead of matrices..." and suddenly, congratulations – you're building for someone who doesn't exist.
is awful similar to LLM writting. I can't put my finger on exactly where, but that the impression i got.
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.
For macros, yes, `cargo expand`.
For generics, no, but you can query this information in your IDE pretty easily. You can also also use `cargo doc` to build the generated documentation, which will show you the list of traits something implements.
IIRC rust-analyzer lets you view the expanded form of macros (declarative ones at least, maybe procedural too?)
Kind of, some of the stuff you can see on Rust Playground.
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.
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.
> 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.
> 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.
> 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).
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.
[dead]