6 ms·

"Rust code is wonderful to write and read" Writing I'm not sure, reading it's just awful, everytime someone show his project on HN I check github and I'm baffl

by Thaxll 7y ago

"Rust code is wonderful to write and read" Writing I'm not sure, reading it's just awful, everytime someone show his project on HN I check github and I'm baffled how the code looks bad as a human reader. (){}<>''-_

CDSlice 7y ago
Is it really that much worse than C or JS? Most popular languages other than Python use () and {}, <> are just for generics like many other languages, " is used for strings, - is just a minus sign, and _ is just used when you need to ignore something when matching just like it is used in Python. Yes, Rust is a very symbol rich language, but it also is very information dense which makes it easier to read than many other languages once you learn it.
- Crinus 7y ago
  Information density isn't the end goal though, otherwise we'd all be writing into something like APL or its derivatives (K/Q/J/etc). And yeah, if you have ever missed a & in C++ you can easily see why a single character symbol can be annoying (i really prefer C#'s approach where you not only use ref and out in function declarations, but also during function calls - though overall i prefer Pascal's more explicit and verbose syntax).
  - derefr 7y ago
    I think the goal programming languages optimize for is somewhere between, on the one hand, "learnability" / "time to fluency"; and, on the other, "power/expressivity when fluent." When you multiply these measures together, gives you an area measured in "productivity over time of each man-hour invested into the project by population of developers of various stages of fluency with the language" (where for an average developer on the project, any given man-hour is partially spent writing code, and partially spent becoming more fluent in the language.) APL-likes (and Forth-likes, and Lisps when you use the macro features) are a bit too far on the "power when fluent" axis, at the expense of learnability, and so the total area of the product is small. Might be good for one-man projects, but not for large ones. Minimal languages like ASM or Java, where there are just a few primitives and everything else is design patterns, trade high "learnability" for low "power when fluent", and so also have a reduced optimization product. Most languages aim somewhere in the middle, though often with a bias toward the side where they think the optimum might truly lie; for example, Go is slightly on the "learnable" side, and Rust is slightly on the "power when fluent" side, but both seem to be generally more productive per average-programmer-man-hour invested into FOSS projects than languages that more heavily favour just one axis. (Side-note: I'd love to see some real numbers crunched on this. A comparison of rival FOSS projects to implement some shared standard in different languages would make for a pretty good "natural experiment" to look at productivity over. First thing that springs to mind for me personally are the rival Ethereum clients of Geth (= Go) and Parity (= Rust), but I'm sure you can think of your own examples.)
    - Crinus 7y ago
      This isn't about learnability or time to fluency, it is about readability. The & issue i mention for example isn't about how easy it is to learn about references, but about how readable is when, e.g, you are reading some patch in a code review and you miss someone forgetting it when returning a huge collection which can causes severe performance issues. These are mostly orthogonal issues to how easy and/or powerful a language is.
      - derefr 7y ago
        My definition of "fluency" is that it's the point where every well-written piece of code in the language is easily readable to you. ("Fluency" of a spoken language is the point where you can speak it and parse-while-hearing it without thinking, so I think this is a sensible definition.) By this standard, most programmers never achieve 100% fluency in even their favorite programming language, unless their favorite language is one of the dead-simple ones; and there are some programming languages (esolangs, certainly) that nobody is 100% fluent in; and many (the APLs, Forths, etc.) that only a few human beings on earth are 100% fluent in. (That's not to say that there aren't many people who can read and write them—just, not fluently. If you need to look at a programming-language reference more often than you need a dictionary to parse out the meaning of a sentence in your native spoken language, you're not fluent.) A language that's less "readable", by your terming, is just one that takes longer to become fluent in. Given that the programmers working on any given project are going to be in a mixture of phases in their careers, and thus have invested different numbers of man-hours into language fluency, there's going to be a mixture of fluency levels on any project (where less-fluent readers experience the language as "less readable.") Longer time-to-fluency means that the same number of invested man-hours get you less fluency, and so on projects in languages with longer time-to-fluency, but the same distribution of programmer career-levels, you'll see lower average fluency (or a skew toward the bottom of the distribution, really) and thus more complaints of low readability. Mind you, this isn't really a fact about the language itself, but a fact about the project—if everyone on a project are 20-year veterans of the language, any language can be "readable." I would note that we can measure time-to-fluency; it's objective. We can teach people a programming language, test them along the way, and see how many man-hours of study it takes to get 100% on the tests. We can't measure a language's "readability"; it's subjective. But it likely has a heavy correlation to time-to-fluency, so time-to-fluency is the measure you should care about if you care about A-B testing programming language syntax features for their effect on "readability."
echelon 7y ago
That's your opinion. I think it looks awesome. Pattern matching, short keywords, types on the right... It accomplishes this beauty while also carrying lifetimes, pointer types, and traits. I personally like it much better then Java or similar static typed languages. You can't compare it to a scripting language because it has type information.
- mrkeen 7y ago
  > You can't compare it to a scripting language because it has type information. What do you mean by this?
  - echelon 7y ago
    Rust requires types, pointer types, lifetime bounds, trait classes, etc. for struct and function declarations. They're also used to disambiguate in other places when type inference isn't possible, such as during method chaining.
    - arcticbull 7y ago
      You could have that in a scripting language, and you could not have that in a compiled language. The difference between the two is the back-end not the front-end.
      - echelon 7y ago
        What are you talking about? A statically typed language would be hard to reason about without types and it would dramatically impact compilation times. Why would you include lifetime annotations in a GC'd scripting language? These are features for the compiler and the human to reason about. The language and compiler are intertwined. While you could divorce the language from the compiler, it would be misguided to do so for many languages and problem domains. You can hold up TypeScript as an example of a scripting language with types that upholds your philosophy, but its advantage is primarily for humans. I'm unaware of any performance benefits or optimizations it provides. It wasn't carefully spec'd out with a compiler in mind. It's a well thought out cross-compiled superset language. This isn't the case with languages designed for bare metal. edit: I can't reply with a comment thread this nested. Compilers absolutely inform language design and vice-versa. Bad language design leads to horrible compilers (C++). A good language design process works in lockstep with its compiler design, with careful attention to the AST, the number of passes, analysis, etc. If we didn't think about compilers, we couldn't design languages that could be compiled.
derefr 7y ago
I feel like, whether with human or computer languages, you can only really say what the experience of reading a language is like once you're fluent in it; and you can only compare the experience of reading a language to another if you're fluent in both of them. Like, to me, the human language of Vietnamese looks like a mess of accents, and I'm baffled by why they're necessary. But I'm not a fluent speaker of Vietnamese; and I can imagine that, for someone who is fluent in Vietnamese, and another sibling language like Chinese, maybe the extra accents actually compare very well and help readability compared to e.g. the reduced set of accents in Chinese pinyin. Likewise, I would suspect that for someone fluent in both C++ and Rust (i.e. someone who knows how to write code that takes advantage of arcane language features in both), Rust might be more readable than C++ because of some of the initially-offputting syntax, whereas C++ might seem less readable because it eschews extra syntax in favor of using template constructors for everything.
- swsieber 7y ago
  This reminds me of a quip relating to evaluating the morality of historical figures (e.g. whether they were basically good or basically bad) - you're a tourist. You're evaluating someone in an entirely different culture. So like you said - same thing with languages. You could probably substitute "Japanese text" or "Arabic text" into the original comment and see a little more clearly that fluency does matter.
- agumonkey 7y ago
  I think there are other factors. I liked lisp without even knowing it. Because my brain wanted the limited amount of syntax possible. Your mental model will affect how you feel about a language.
- Waterluvian 7y ago
  This reminds me of my experience with TypeScript. I kept noticing it and feeling a little irritated by its popularity. God it added so much noise to the code. JavaScript was fine for years. I got stuff done. I caught the bugs and debugged them. Once I finally took the plunge and committed a full project to learning TypeScript, I grokked it. I no-longer saw noise, I saw signal. I saw details about interfaces that I used to have to infer, document, or reverse engineer if I forgot.
Diggsey 7y ago
Rust is very middle of the road when it comes to using weird symbols all over the place. Just take a look at some C++ or Objective C code... I think this is more a problem with what you're used to. You see the same criticisms of every language: Basic dialects are too wordy, Lisp dialects too bracketty, C dialects too symbolly, etc. etc. It's hardly the measure of a language.
- wil421 7y ago
  Learning Python on the side right now and I can’t help but add {} or ;’s all over the place. I have to stop my self a lot. Coming from JavaScript (and a little java) myself it’s much more pleasant to use Python. You mean I can just indent a function? Java was the language I learned during CS101 in school and I always hated the “don’t worry about this part right now just write static main void... or the equivalent”. Python code is cleaner too look at but Java has it’s reasons for the verbosity.
  - tyre 7y ago
    until you realize that you can't do multi-line lambdas because whitespace sensitive languages are awful. Note how no new language chooses to follow this nonsense. The braces allow you to be explicit with what you want. Rust's {} are a feature. They let you see exactly which scope you're in. With Rust's memory management, you then know exactly when a variable will go out of scope and be cleaned up.
    - wil421 7y ago
      I’ll have to remember that for later use. The reason I am learning Python is to setup some home automation using Raspberry Pis and a flask based api/app to complement the data they collect. You peaked my interest. Guido van Rossum on the subject: > But the complexity of any proposed solution for this puzzle is immense, to me: it requires the parser (or more precisely, the lexer) to be able to switch back and forth between indent-sensitive and indent-insensitive modes, keeping a stack of previous modes and indentation level. Technically that can all be solved (there's already a stack of indentation levels that could be generalized). But none of that takes away my gut feeling that it is all an elaborate Rube Goldberg contraption. https://www.artima.com/weblogs/viewpost.jsp?thread=147358 https://www.artima.com/weblogs/viewpost.jsp?thread=147358 As a side note, there are more than 100x the number of jobs with Python in the description vs rust. Out of the 30 or so jobs with Rust in the description most are for automotive techs.
TheChaplain 7y ago
Then we are two, I'm afraid. I really would like to learn it and have tried multiple times but it just isn't aesthetically pleasing to read. Python on the other hand is awesome, and I also begun looking at Go which seem to be quite okay.
munmaek 7y ago
I must be in the minority then, because rust's syntax doesn't bother me in the least. The only exception is the method::<Type>() that's sometimes necessary. When I write or read rust code the symbols just sort of disappear.
- fluffything 7y ago
  I actually like `method::<Type>()`, but I did not used to like it when I started learning Rust. Nowadays every time I have to go back to C++ and read `method<Type>()` I need to parse whether this is `(method < Type) > ())` or something else. Luckily for me, C++ introduced the `method.template <Type>()` syntax... but over that I prefer `::<Type>`. I also prefer ::<Type> over Scala and D's syntaxes for some reason. I find Scala syntax for this more complex, and I find D syntax too simple.
- rapsey 7y ago
  Reading countless rust threads has left me with the opinion that some people are just unadaptable. They cling to what they consider right way too hard. It is not that they are wrong, their knowledge is right for the sphere they work in, but they extrapolate it too far and refuse to get out of their comfort zone.
whateveracct 7y ago
Do you know Rust at all? Or is that your take knowing how to program in general & not being able to jump in and read at a glance?
deleted 7y ago
[deleted]
crispinb 7y ago
Do you know Rust though? "wonderful to .. read" doesn't connote being readable to people who don't program in Rust. Some famously 'readable' languages (Go, Python) can be scanned by the non-fluent, but this is an additional quality which becomes less relevant as you learn the language. I find Rust readability a mixed picture. Being a Rust novice I sometimes find the details hard to follow precisely (as in: I often wouldn't be able to reproduce the code without error myself). But the type system, stdlib & generics make it sufficiently expressive that it's usually pretty easy to understand broadly how things work. In my journey so far I've been able to follow large library codebases more easily than in other languages I've used.
empath75 7y ago
I'm not really a rust programmer, but I find it quite readable for the most part, one you get used to the unusual data structures.
pcwalton 7y ago
That's the punctuation that every C-like language uses.

by Thaxll 7y ago

CDSlice 7y ago

Is it really that much worse than C or JS? Most popular languages other than Python use () and {}, <> are just for generics like many other languages, " is used for strings, - is just a minus sign, and _ is just used when you need to ignore something when matching just like it is used in Python. Yes, Rust is a very symbol rich language, but it also is very information dense which makes it easier to read than many other languages once you learn it.

Crinus 7y ago
Information density isn't the end goal though, otherwise we'd all be writing into something like APL or its derivatives (K/Q/J/etc). And yeah, if you have ever missed a & in C++ you can easily see why a single character symbol can be annoying (i really prefer C#'s approach where you not only use ref and out in function declarations, but also during function calls - though overall i prefer Pascal's more explicit and verbose syntax).
- derefr 7y ago
  I think the goal programming languages optimize for is somewhere between, on the one hand, "learnability" / "time to fluency"; and, on the other, "power/expressivity when fluent." When you multiply these measures together, gives you an area measured in "productivity over time of each man-hour invested into the project by population of developers of various stages of fluency with the language" (where for an average developer on the project, any given man-hour is partially spent writing code, and partially spent becoming more fluent in the language.) APL-likes (and Forth-likes, and Lisps when you use the macro features) are a bit too far on the "power when fluent" axis, at the expense of learnability, and so the total area of the product is small. Might be good for one-man projects, but not for large ones. Minimal languages like ASM or Java, where there are just a few primitives and everything else is design patterns, trade high "learnability" for low "power when fluent", and so also have a reduced optimization product. Most languages aim somewhere in the middle, though often with a bias toward the side where they think the optimum might truly lie; for example, Go is slightly on the "learnable" side, and Rust is slightly on the "power when fluent" side, but both seem to be generally more productive per average-programmer-man-hour invested into FOSS projects than languages that more heavily favour just one axis. (Side-note: I'd love to see some real numbers crunched on this. A comparison of rival FOSS projects to implement some shared standard in different languages would make for a pretty good "natural experiment" to look at productivity over. First thing that springs to mind for me personally are the rival Ethereum clients of Geth (= Go) and Parity (= Rust), but I'm sure you can think of your own examples.)
  - Crinus 7y ago
    This isn't about learnability or time to fluency, it is about readability. The & issue i mention for example isn't about how easy it is to learn about references, but about how readable is when, e.g, you are reading some patch in a code review and you miss someone forgetting it when returning a huge collection which can causes severe performance issues. These are mostly orthogonal issues to how easy and/or powerful a language is.
    - derefr 7y ago
      My definition of "fluency" is that it's the point where every well-written piece of code in the language is easily readable to you. ("Fluency" of a spoken language is the point where you can speak it and parse-while-hearing it without thinking, so I think this is a sensible definition.) By this standard, most programmers never achieve 100% fluency in even their favorite programming language, unless their favorite language is one of the dead-simple ones; and there are some programming languages (esolangs, certainly) that nobody is 100% fluent in; and many (the APLs, Forths, etc.) that only a few human beings on earth are 100% fluent in. (That's not to say that there aren't many people who can read and write them—just, not fluently. If you need to look at a programming-language reference more often than you need a dictionary to parse out the meaning of a sentence in your native spoken language, you're not fluent.) A language that's less "readable", by your terming, is just one that takes longer to become fluent in. Given that the programmers working on any given project are going to be in a mixture of phases in their careers, and thus have invested different numbers of man-hours into language fluency, there's going to be a mixture of fluency levels on any project (where less-fluent readers experience the language as "less readable.") Longer time-to-fluency means that the same number of invested man-hours get you less fluency, and so on projects in languages with longer time-to-fluency, but the same distribution of programmer career-levels, you'll see lower average fluency (or a skew toward the bottom of the distribution, really) and thus more complaints of low readability. Mind you, this isn't really a fact about the language itself, but a fact about the project—if everyone on a project are 20-year veterans of the language, any language can be "readable." I would note that we can measure time-to-fluency; it's objective. We can teach people a programming language, test them along the way, and see how many man-hours of study it takes to get 100% on the tests. We can't measure a language's "readability"; it's subjective. But it likely has a heavy correlation to time-to-fluency, so time-to-fluency is the measure you should care about if you care about A-B testing programming language syntax features for their effect on "readability."

echelon 7y ago

That's your opinion. I think it looks awesome. Pattern matching, short keywords, types on the right... It accomplishes this beauty while also carrying lifetimes, pointer types, and traits. I personally like it much better then Java or similar static typed languages. You can't compare it to a scripting language because it has type information.

mrkeen 7y ago
> You can't compare it to a scripting language because it has type information. What do you mean by this?
- echelon 7y ago
  Rust requires types, pointer types, lifetime bounds, trait classes, etc. for struct and function declarations. They're also used to disambiguate in other places when type inference isn't possible, such as during method chaining.
  - arcticbull 7y ago
    You could have that in a scripting language, and you could not have that in a compiled language. The difference between the two is the back-end not the front-end.
    - echelon 7y ago
      What are you talking about? A statically typed language would be hard to reason about without types and it would dramatically impact compilation times. Why would you include lifetime annotations in a GC'd scripting language? These are features for the compiler and the human to reason about. The language and compiler are intertwined. While you could divorce the language from the compiler, it would be misguided to do so for many languages and problem domains. You can hold up TypeScript as an example of a scripting language with types that upholds your philosophy, but its advantage is primarily for humans. I'm unaware of any performance benefits or optimizations it provides. It wasn't carefully spec'd out with a compiler in mind. It's a well thought out cross-compiled superset language. This isn't the case with languages designed for bare metal. edit: I can't reply with a comment thread this nested. Compilers absolutely inform language design and vice-versa. Bad language design leads to horrible compilers (C++). A good language design process works in lockstep with its compiler design, with careful attention to the AST, the number of passes, analysis, etc. If we didn't think about compilers, we couldn't design languages that could be compiled.

derefr 7y ago

I feel like, whether with human or computer languages, you can only really say what the experience of reading a language is like once you're fluent in it; and you can only compare the experience of reading a language to another if you're fluent in both of them. Like, to me, the human language of Vietnamese looks like a mess of accents, and I'm baffled by why they're necessary. But I'm not a fluent speaker of Vietnamese; and I can imagine that, for someone who is fluent in Vietnamese, and another sibling language like Chinese, maybe the extra accents actually compare very well and help readability compared to e.g. the reduced set of accents in Chinese pinyin. Likewise, I would suspect that for someone fluent in both C++ and Rust (i.e. someone who knows how to write code that takes advantage of arcane language features in both), Rust might be more readable than C++ because of some of the initially-offputting syntax, whereas C++ might seem less readable because it eschews extra syntax in favor of using template constructors for everything.

swsieber 7y ago
This reminds me of a quip relating to evaluating the morality of historical figures (e.g. whether they were basically good or basically bad) - you're a tourist. You're evaluating someone in an entirely different culture. So like you said - same thing with languages. You could probably substitute "Japanese text" or "Arabic text" into the original comment and see a little more clearly that fluency does matter.
agumonkey 7y ago
I think there are other factors. I liked lisp without even knowing it. Because my brain wanted the limited amount of syntax possible. Your mental model will affect how you feel about a language.
Waterluvian 7y ago
This reminds me of my experience with TypeScript. I kept noticing it and feeling a little irritated by its popularity. God it added so much noise to the code. JavaScript was fine for years. I got stuff done. I caught the bugs and debugged them. Once I finally took the plunge and committed a full project to learning TypeScript, I grokked it. I no-longer saw noise, I saw signal. I saw details about interfaces that I used to have to infer, document, or reverse engineer if I forgot.

Diggsey 7y ago

Rust is very middle of the road when it comes to using weird symbols all over the place. Just take a look at some C++ or Objective C code... I think this is more a problem with what you're used to. You see the same criticisms of every language: Basic dialects are too wordy, Lisp dialects too bracketty, C dialects too symbolly, etc. etc. It's hardly the measure of a language.

wil421 7y ago
Learning Python on the side right now and I can’t help but add {} or ;’s all over the place. I have to stop my self a lot. Coming from JavaScript (and a little java) myself it’s much more pleasant to use Python. You mean I can just indent a function? Java was the language I learned during CS101 in school and I always hated the “don’t worry about this part right now just write static main void... or the equivalent”. Python code is cleaner too look at but Java has it’s reasons for the verbosity.
- tyre 7y ago
  until you realize that you can't do multi-line lambdas because whitespace sensitive languages are awful. Note how no new language chooses to follow this nonsense. The braces allow you to be explicit with what you want. Rust's {} are a feature. They let you see exactly which scope you're in. With Rust's memory management, you then know exactly when a variable will go out of scope and be cleaned up.
  - wil421 7y ago
    I’ll have to remember that for later use. The reason I am learning Python is to setup some home automation using Raspberry Pis and a flask based api/app to complement the data they collect. You peaked my interest. Guido van Rossum on the subject: > But the complexity of any proposed solution for this puzzle is immense, to me: it requires the parser (or more precisely, the lexer) to be able to switch back and forth between indent-sensitive and indent-insensitive modes, keeping a stack of previous modes and indentation level. Technically that can all be solved (there's already a stack of indentation levels that could be generalized). But none of that takes away my gut feeling that it is all an elaborate Rube Goldberg contraption. https://www.artima.com/weblogs/viewpost.jsp?thread=147358 https://www.artima.com/weblogs/viewpost.jsp?thread=147358 As a side note, there are more than 100x the number of jobs with Python in the description vs rust. Out of the 30 or so jobs with Rust in the description most are for automotive techs.

TheChaplain 7y ago

Then we are two, I'm afraid. I really would like to learn it and have tried multiple times but it just isn't aesthetically pleasing to read. Python on the other hand is awesome, and I also begun looking at Go which seem to be quite okay.

munmaek 7y ago

I must be in the minority then, because rust's syntax doesn't bother me in the least. The only exception is the method::<Type>() that's sometimes necessary. When I write or read rust code the symbols just sort of disappear.

fluffything 7y ago
I actually like `method::<Type>()`, but I did not used to like it when I started learning Rust. Nowadays every time I have to go back to C++ and read `method<Type>()` I need to parse whether this is `(method < Type) > ())` or something else. Luckily for me, C++ introduced the `method.template <Type>()` syntax... but over that I prefer `::<Type>`. I also prefer ::<Type> over Scala and D's syntaxes for some reason. I find Scala syntax for this more complex, and I find D syntax too simple.
rapsey 7y ago
Reading countless rust threads has left me with the opinion that some people are just unadaptable. They cling to what they consider right way too hard. It is not that they are wrong, their knowledge is right for the sphere they work in, but they extrapolate it too far and refuse to get out of their comfort zone.

whateveracct 7y ago

Do you know Rust at all? Or is that your take knowing how to program in general & not being able to jump in and read at a glance?

deleted 7y ago

[deleted]

crispinb 7y ago

Do you know Rust though? "wonderful to .. read" doesn't connote being readable to people who don't program in Rust. Some famously 'readable' languages (Go, Python) can be scanned by the non-fluent, but this is an additional quality which becomes less relevant as you learn the language. I find Rust readability a mixed picture. Being a Rust novice I sometimes find the details hard to follow precisely (as in: I often wouldn't be able to reproduce the code without error myself). But the type system, stdlib & generics make it sufficiently expressive that it's usually pretty easy to understand broadly how things work. In my journey so far I've been able to follow large library codebases more easily than in other languages I've used.

empath75 7y ago

I'm not really a rust programmer, but I find it quite readable for the most part, one you get used to the unusual data structures.

pcwalton 7y ago

That's the punctuation that every C-like language uses.