7 ms·

> This is a superficial complaint, but I found Rust syntax to be dense, heavy, and difficult to read. I'm not sure this is a superficial complaint. People say

> This is a superficial complaint, but I found Rust syntax to be dense, heavy, and difficult to read. I'm not sure this is a superficial complaint. People say the hard thing about learning Rust is the new concepts, but I haven't found that to be true at all. The concepts are easy, but the combinatorial explosion of syntax that supports them is untenable.

kkoning 4y ago
> but the combinatorial explosion of syntax that supports them is untenable. I wouldn't go quite that far myself, but it's definitely one of the sharper edges of the language currently--particularly because some of the features don't work together yet. E.g., async and traits.
devit 4y ago
How would you change the syntax? I don't think that Rust has much redundant syntax. I guess you could do things like replace &'a Type with Ref<'a, Type> and *Type with Ptr<Type>, and get rid of some sugar like "if let" and print!, but I'm not sure that would have much of an impact.
sidlls 4y ago
Back when I wrote C and C++ for a living I'd occasionally meet someone who thought their ability to employ the spiral rule or parse a particularly dense template construct meant they were a genius. I get the same vibe from certain other groups in this industry, most recently from functional programmers and Rust afficionados, for example. Nobody gives a damn if you can narrate a C spiral or a functional-like Rust idiom. And this syntax density is one of the reasons I stopped advocating for the use of Rust in our systems. First, I don't want to work with languages that attract this kind of person. Second, I don't want to work with languages that require a relatively heavy cognitive load on simply reading the lines of the source code. Units of code (i.e. statements, functions, structures and modules) are already a cognitive load--and the more important one. Any extra bit I have to supply to simply parsing the symbols is a distraction. "You get used to it," "with practice it fades to the background," etc. are responses I've seen in these comments, and more generally when this issue comes up. They're inaccurate at best, and often simply another way the above mentioned "geniuses" manifest that particular personality flaw. No, thank you. I'll pass.
- scythe 4y ago
  >Second, I don't want to work with languages that require a relatively heavy cognitive load on simply reading the lines of the source code. Units of code (i.e. statements, functions, structures and modules) are already a cognitive load--and the more important one. Any extra bit I have to supply to simply parsing the symbols is a distraction. The weird thing about these comments to me (as someone who doesn't use Rust) is that the most difficult syntax in the original examples represents a semantic detail that most languages don't have to deal with: the lifetime. The amount of times I think about the lifetimes of variables I write in Python is zero. Parsing the symbols and understanding the code here aren't separate; that weird apostrophe thing in angle brackets is a symbol I don't use referencing a concept I don't use, which fits. If you replaced the symbols with keywords or something, it would just be longer, not simpler. Also, it's a choice to write your code like he did. You can define local variables that hold intermediate results and subexpressions and give them descriptive names, if you want. You could assign `drop = (|_| ())` for example.
  - mftb 4y ago
    Yea, so pretty much every programmer needs to be aware of thinking about lifetimes. The classic issues are creating a local and then giving a reference to it, to something much longer lived, or even undying. In that last case, if your doing it a lot, with no regard to the objects change in lifetime, your effectively creating a leak (I can guarantee you someone, somewhere, is making this mistake in js right now). Most collection strategies won't touch an object that still has a reference to it. The second issue that became really common when people stopped paying attention to lifetimes, is that many resources you may be using (file handles, db connections, etc...) have very different constraints than memory. So you have to be cognizant of the fact that even though something has gone out of scope, it's lifetime really doesn't end until the gc gets around to collecting it. This is the reason special syntax and functions, like "with" and Dispose had to be added to languages like C# and Java. Python with it's reference counting maybe somewhat less susceptible to this second issue than the others, but it's not immune to it. Finally in many cases being aware of object lifetimes and specifically manipulating them can get you performance speed ups.
- 4y ago
krupan 4y ago
One human needs to figure out how to write a line of code once, and then that line needs to be read and understood by humans over and over. Optimize for readability. Rust doesn't seem to do this.
- ModernMech 4y ago
  It's hard to optimize for readability, performance, and safety. Rust chose to go with performance and safety. In the future, maybe we can have a language that gives all three but not today.
  - eternalban 4y ago
    Same thing that happened with type declarations will need to happen to semantic intent: inference.
  - verdagon 4y ago
    Shameless relevant plug: that's the exact goal of Vale! [0] It turns out, when one removes the borrow checker, they get something that's much more readable, because a lot of Rust's complexity was added to help support the borrow checker. Ironically, we can then add back in a different, easier form of borrow checking to get the speed benefits. [0] https://vale.dev/ https://vale.dev/
    - vrfvr 4y ago
      > Rust is also very difficult. It's as complex as C++, and throws it all at the programmer at once. I thin Rust isnt nearly as complex
      - IshKebab 4y ago
        It definitely is. You've probably just had more time to discover the complexity of C++ (and read about it, since it's actually specified). Of course Rust's complexity is much less dangerous because if you forget some obscure rules you get a compile error instead of UB (in safe Rust at least).
UmbertoNoEco 4y ago
Correct, this is more or less like remarking that having to learn Kanji/Hanzi makes learning Japanese/Mandarin very difficult is a superficial complaint.
perrygeo 4y ago
It's not a superficial complaint but it is relative to one's experience. Something that's "difficult" for me might be "easy" for you and vice versa. I find it very much related to understanding the core concepts. I personally find Rust syntax to be quite enjoyable, or at least it fades into the background quickly - with a few exceptions. The syntax for lifetime annotations can be challenging. And not surprisingly explicit lifetime annotations are a rather unique concept, at least among mainstream languages. IOW the syntax is difficult because it's an entirely new mental model (for me), not because `<'a>` is an inherently bad way to express it.
gxt 4y ago
I use rust weekly and I find it to have the best DX. I have done work with Oracle Java 5-8, IBM XL C99, MSVC++11, CPython 2-3, C# .NET Core 3.1. Stable Rust 2021 is overall the most readable, least surprising, BUT only with the right tool which also makes it the most discoverable, with rust-analyzer. My only gripe is the lack of consensus on strongly typed error handling (anyhow+thiserror being the most sensible combination I found after moving away from bare Results, to failure, to just anyhow).
titzer 4y ago
I find Rust code hard to read...to the point where I don't feel motivated to learn it anymore. Line noise is confusing and a distraction. Random syntactic "innovations" I find are just friction in picking up a language. For example, in the first versions of Virgil I introduced new keywords for declaring fields: "field", "method" and then "local". There was a different syntax for switch statements, a slightly different syntax for array accesses. Then I looked at the code I was writing and realized that the different keywords didn't add anything, the array subscripting syntax was just a bother; in fact, all my "innovations" just took things away and made it harder to learn. For better or for worse, the world is starting to converge on something that looks like an amalgam of Java, JavaScript, and Scala. At least IMHO; that's kind of what Virgil has started to look like, heh :)

kkoning 4y ago

> but the combinatorial explosion of syntax that supports them is untenable. I wouldn't go quite that far myself, but it's definitely one of the sharper edges of the language currently--particularly because some of the features don't work together yet. E.g., async and traits.

devit 4y ago

How would you change the syntax? I don't think that Rust has much redundant syntax. I guess you could do things like replace &'a Type with Ref<'a, Type> and *Type with Ptr<Type>, and get rid of some sugar like "if let" and print!, but I'm not sure that would have much of an impact.

sidlls 4y ago

Back when I wrote C and C++ for a living I'd occasionally meet someone who thought their ability to employ the spiral rule or parse a particularly dense template construct meant they were a genius. I get the same vibe from certain other groups in this industry, most recently from functional programmers and Rust afficionados, for example. Nobody gives a damn if you can narrate a C spiral or a functional-like Rust idiom. And this syntax density is one of the reasons I stopped advocating for the use of Rust in our systems. First, I don't want to work with languages that attract this kind of person. Second, I don't want to work with languages that require a relatively heavy cognitive load on simply reading the lines of the source code. Units of code (i.e. statements, functions, structures and modules) are already a cognitive load--and the more important one. Any extra bit I have to supply to simply parsing the symbols is a distraction. "You get used to it," "with practice it fades to the background," etc. are responses I've seen in these comments, and more generally when this issue comes up. They're inaccurate at best, and often simply another way the above mentioned "geniuses" manifest that particular personality flaw. No, thank you. I'll pass.

scythe 4y ago
>Second, I don't want to work with languages that require a relatively heavy cognitive load on simply reading the lines of the source code. Units of code (i.e. statements, functions, structures and modules) are already a cognitive load--and the more important one. Any extra bit I have to supply to simply parsing the symbols is a distraction. The weird thing about these comments to me (as someone who doesn't use Rust) is that the most difficult syntax in the original examples represents a semantic detail that most languages don't have to deal with: the lifetime. The amount of times I think about the lifetimes of variables I write in Python is zero. Parsing the symbols and understanding the code here aren't separate; that weird apostrophe thing in angle brackets is a symbol I don't use referencing a concept I don't use, which fits. If you replaced the symbols with keywords or something, it would just be longer, not simpler. Also, it's a choice to write your code like he did. You can define local variables that hold intermediate results and subexpressions and give them descriptive names, if you want. You could assign `drop = (|_| ())` for example.
- mftb 4y ago
  Yea, so pretty much every programmer needs to be aware of thinking about lifetimes. The classic issues are creating a local and then giving a reference to it, to something much longer lived, or even undying. In that last case, if your doing it a lot, with no regard to the objects change in lifetime, your effectively creating a leak (I can guarantee you someone, somewhere, is making this mistake in js right now). Most collection strategies won't touch an object that still has a reference to it. The second issue that became really common when people stopped paying attention to lifetimes, is that many resources you may be using (file handles, db connections, etc...) have very different constraints than memory. So you have to be cognizant of the fact that even though something has gone out of scope, it's lifetime really doesn't end until the gc gets around to collecting it. This is the reason special syntax and functions, like "with" and Dispose had to be added to languages like C# and Java. Python with it's reference counting maybe somewhat less susceptible to this second issue than the others, but it's not immune to it. Finally in many cases being aware of object lifetimes and specifically manipulating them can get you performance speed ups.
4y ago

krupan 4y ago

One human needs to figure out how to write a line of code once, and then that line needs to be read and understood by humans over and over. Optimize for readability. Rust doesn't seem to do this.

ModernMech 4y ago
It's hard to optimize for readability, performance, and safety. Rust chose to go with performance and safety. In the future, maybe we can have a language that gives all three but not today.
- eternalban 4y ago
  Same thing that happened with type declarations will need to happen to semantic intent: inference.
- verdagon 4y ago
  Shameless relevant plug: that's the exact goal of Vale! [0] It turns out, when one removes the borrow checker, they get something that's much more readable, because a lot of Rust's complexity was added to help support the borrow checker. Ironically, we can then add back in a different, easier form of borrow checking to get the speed benefits. [0] https://vale.dev/ https://vale.dev/
  - vrfvr 4y ago
    > Rust is also very difficult. It's as complex as C++, and throws it all at the programmer at once. I thin Rust isnt nearly as complex
    - IshKebab 4y ago
      It definitely is. You've probably just had more time to discover the complexity of C++ (and read about it, since it's actually specified). Of course Rust's complexity is much less dangerous because if you forget some obscure rules you get a compile error instead of UB (in safe Rust at least).

UmbertoNoEco 4y ago

Correct, this is more or less like remarking that having to learn Kanji/Hanzi makes learning Japanese/Mandarin very difficult is a superficial complaint.

perrygeo 4y ago

It's not a superficial complaint but it is relative to one's experience. Something that's "difficult" for me might be "easy" for you and vice versa. I find it very much related to understanding the core concepts. I personally find Rust syntax to be quite enjoyable, or at least it fades into the background quickly - with a few exceptions. The syntax for lifetime annotations can be challenging. And not surprisingly explicit lifetime annotations are a rather unique concept, at least among mainstream languages. IOW the syntax is difficult because it's an entirely new mental model (for me), not because `<'a>` is an inherently bad way to express it.

gxt 4y ago

I use rust weekly and I find it to have the best DX. I have done work with Oracle Java 5-8, IBM XL C99, MSVC++11, CPython 2-3, C# .NET Core 3.1. Stable Rust 2021 is overall the most readable, least surprising, BUT only with the right tool which also makes it the most discoverable, with rust-analyzer. My only gripe is the lack of consensus on strongly typed error handling (anyhow+thiserror being the most sensible combination I found after moving away from bare Results, to failure, to just anyhow).

titzer 4y ago

I find Rust code hard to read...to the point where I don't feel motivated to learn it anymore. Line noise is confusing and a distraction. Random syntactic "innovations" I find are just friction in picking up a language. For example, in the first versions of Virgil I introduced new keywords for declaring fields: "field", "method" and then "local". There was a different syntax for switch statements, a slightly different syntax for array accesses. Then I looked at the code I was writing and realized that the different keywords didn't add anything, the array subscripting syntax was just a bother; in fact, all my "innovations" just took things away and made it harder to learn. For better or for worse, the world is starting to converge on something that looks like an amalgam of Java, JavaScript, and Scala. At least IMHO; that's kind of what Virgil has started to look like, heh :)