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.
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.
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.
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.
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]
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.
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.
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.
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.
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).
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.
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.
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.
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.
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-...
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.
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.
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.
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.
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).