6 ms·

> Rust is already a weird language to come to from the likes of python, Java, or Javascript I think that's a great reason to evaluate new syntax/features on ho

> Rust is already a weird language to come to from the likes of python, Java, or Javascript I think that's a great reason to evaluate new syntax/features on how they will be used, as opposed to how they will attract (or not) new users. New users are already going to be expecting things to be different, and so making this one thing more familiar probably won't make much difference. On the other hand, code lives for a very long time once it's been written, so making the right choice in terms of readability/maintainability seems like the right move.

foota 7y ago
While that's true on an individual basis you can't use that continually to introduce differences, because at some point if someone comes to rust and sees a heap of weirdness they're going to be less likely to adopt the language. I'm mostly a bystander since I've written some rust but not very much, but I think rust is neat and I don't want it to become an esoteric language.
- ljm 7y ago
  If it's an effective solution it will only seem weird until it's proven to be more useful than the status quo approach. I read this post and thought 'async as a prefix is intuitive!', but that's only because I saw it first in C#. Rust already has an immense learning curve despite its ergonomics, I say it should continue to experiment. Same way Haskell does. I do wonder if `.await` could have a sigil equivalent the same way `try!` did with `?`. `…` could work if it's not already used as spread args.
  - ajross 7y ago
    > If it's an effective solution it will only seem weird until it's proven to be more useful than the status quo approach. Perl was a very effective solution. Still lost. And I say that as a long time perl5 nut. Rust is, indeed, just syntactically insane to a new learner (honestly, worse than perl ever was). And it's getting rapidly worse.
    - username223 7y ago
      > Perl was a very effective solution. Still lost. For some version of "lost." It lost to $LANGUAGE_OF_THE_MOMENT for web development, but Perl is still a great text-munging and glue language, and I'll bet I'm not the only one using it for that. It didn't take over the world, but I'll bet that most people interact with a bit of Perl every day. I agree that Rust is syntactically insane. Worse, while a Shell-and-C programmer would have some intuition about Perl syntax, a C++ programmer will almost start from scratch in Rust.
    - pcwalton 7y ago
      > Rust is, indeed, just syntactically insane to a new learner (honestly, worse than perl ever was). Can you elaborate?
      - ajross 7y ago
        Not even if you paid me to have that fight, no. Edit: OK, one tiny crumb: https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html -- Read through that thinking about how other languages express the same fundamentally simple concepts, and consider how Rust invents new syntax for basically everything, and then sticks it all together by re-using syntax from other areas. Why does a parametrized enumerant look like a function call and not a struct? Why is "127.0.0.1" not a String? Why do parametrized enumerants look in rvalues like C++ constructor arguments, which you promised earlier Rust didn't have? Don't tell me the answers to those questions. I know the answers. Just recognize that those are questions that every new reader to that very early page in your docs is going to have. And... did they even need to be questions in the first place?
        simias 7y ago
        You need to tell us which other language you compare it to then. AFAIK most mainstream languages (the ones these hypothetical new readers are most likely to come from) don't have anything like Rust's enums. C++ does have the difference between C-style "const char " and "std::string" which is a bit* similar to &str and String, although &str is obviously massively safer and more ergonomic. If they come from Scala or Haskell then yeah, sure but I'd argue that most programmers these days are likely to come from JS, Python or Java/C#/C++ and copying Scala or Haskell syntax would look even more foreign to them. Rust instead preferred to go for a syntax inspired by C++ >Don't tell me the answers to those questions. [...] And... did they even need to be questions in the first place? So you know the answers but you still think it shouldn't be done that way? Having things like &str instead of forcing everything into a dynamic String is Rust's killer feature. It means that you can write safe code while not being forced into adding any overhead. You pay for what you use, to quote the C++ motto. That means that as Rust matures it becomes a good competitor for replacing C and C++.
  - childintime 7y ago
    > 'async as a prefix is intuitive!', but that's only because I saw it first in C# The analogy made in the post, with the possibility of “expression-oriented” keywords like .match, suggests that `match expr {..}` is equivalent to `expr.match {..}`. So by analogy `await expr` and `expr.await` are also similar. So why was the "prefix await" syntax dismissed right out of the gate? It is the option that needs the best argumentation, because 1) it is familiar and 2) match is currently a prefix (keyword), so await could probably also be. Edit: only the await prefix clearly signals a break in control flow, only the prefix variant emphasizes this. In contrast the dot await syntax hides this.
- vedantroy 7y ago
  I feel like unusual language syntax isn't an issue, as long as the syntax is understandable/readable once the programmer learns the syntax. It doesn't take too long to pick up and become comfortable with a new syntax in a programming language. Imo, the reason some esoteric languages fail are not purely because their syntax is obscure but because even once you learn the syntax, it is still hard to understand the code (example: Brainfuck). With Rust, once you learn the new syntax, you can understand Rust code with relatively little effort.
  - dragonwriter 7y ago
    > Imo, the reason perl failed was not because the syntax was obscure but because even once you learned the syntax, it was still hard to read perl code. IMO, the reason Perl failed is that Perl 6 (which is a fairly awesome language in its own right) sucked up all the energy in moving Perl forward for too long and delivered too late, while competing languages kept providing usable progress (and avoided, as a consequence, looking dead, which may be as important as the actual usable progress itself.)
jononor 7y ago
New users expect things to be a bit different by assuming there are good reasons for change of convention. EDIT: this might very well be the case here though, especially future extension for similar operators and chain-ability.
- wtetzner 7y ago
  Right, which is why I mentioned that focusing on readability/maintainability is the right move in this case. I think we're in agreement.

foota 7y ago

While that's true on an individual basis you can't use that continually to introduce differences, because at some point if someone comes to rust and sees a heap of weirdness they're going to be less likely to adopt the language. I'm mostly a bystander since I've written some rust but not very much, but I think rust is neat and I don't want it to become an esoteric language.

ljm 7y ago
If it's an effective solution it will only seem weird until it's proven to be more useful than the status quo approach. I read this post and thought 'async as a prefix is intuitive!', but that's only because I saw it first in C#. Rust already has an immense learning curve despite its ergonomics, I say it should continue to experiment. Same way Haskell does. I do wonder if `.await` could have a sigil equivalent the same way `try!` did with `?`. `…` could work if it's not already used as spread args.
- ajross 7y ago
  > If it's an effective solution it will only seem weird until it's proven to be more useful than the status quo approach. Perl was a very effective solution. Still lost. And I say that as a long time perl5 nut. Rust is, indeed, just syntactically insane to a new learner (honestly, worse than perl ever was). And it's getting rapidly worse.
  - username223 7y ago
    > Perl was a very effective solution. Still lost. For some version of "lost." It lost to $LANGUAGE_OF_THE_MOMENT for web development, but Perl is still a great text-munging and glue language, and I'll bet I'm not the only one using it for that. It didn't take over the world, but I'll bet that most people interact with a bit of Perl every day. I agree that Rust is syntactically insane. Worse, while a Shell-and-C programmer would have some intuition about Perl syntax, a C++ programmer will almost start from scratch in Rust.
  - pcwalton 7y ago
    > Rust is, indeed, just syntactically insane to a new learner (honestly, worse than perl ever was). Can you elaborate?
    - ajross 7y ago
      Not even if you paid me to have that fight, no. Edit: OK, one tiny crumb: https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html -- Read through that thinking about how other languages express the same fundamentally simple concepts, and consider how Rust invents new syntax for basically everything, and then sticks it all together by re-using syntax from other areas. Why does a parametrized enumerant look like a function call and not a struct? Why is "127.0.0.1" not a String? Why do parametrized enumerants look in rvalues like C++ constructor arguments, which you promised earlier Rust didn't have? Don't tell me the answers to those questions. I know the answers. Just recognize that those are questions that every new reader to that very early page in your docs is going to have. And... did they even need to be questions in the first place?
      - simias 7y ago
        You need to tell us which other language you compare it to then. AFAIK most mainstream languages (the ones these hypothetical new readers are most likely to come from) don't have anything like Rust's enums. C++ does have the difference between C-style "const char " and "std::string" which is a bit* similar to &str and String, although &str is obviously massively safer and more ergonomic. If they come from Scala or Haskell then yeah, sure but I'd argue that most programmers these days are likely to come from JS, Python or Java/C#/C++ and copying Scala or Haskell syntax would look even more foreign to them. Rust instead preferred to go for a syntax inspired by C++ >Don't tell me the answers to those questions. [...] And... did they even need to be questions in the first place? So you know the answers but you still think it shouldn't be done that way? Having things like &str instead of forcing everything into a dynamic String is Rust's killer feature. It means that you can write safe code while not being forced into adding any overhead. You pay for what you use, to quote the C++ motto. That means that as Rust matures it becomes a good competitor for replacing C and C++.
- childintime 7y ago
  > 'async as a prefix is intuitive!', but that's only because I saw it first in C# The analogy made in the post, with the possibility of “expression-oriented” keywords like .match, suggests that `match expr {..}` is equivalent to `expr.match {..}`. So by analogy `await expr` and `expr.await` are also similar. So why was the "prefix await" syntax dismissed right out of the gate? It is the option that needs the best argumentation, because 1) it is familiar and 2) match is currently a prefix (keyword), so await could probably also be. Edit: only the await prefix clearly signals a break in control flow, only the prefix variant emphasizes this. In contrast the dot await syntax hides this.
vedantroy 7y ago
I feel like unusual language syntax isn't an issue, as long as the syntax is understandable/readable once the programmer learns the syntax. It doesn't take too long to pick up and become comfortable with a new syntax in a programming language. Imo, the reason some esoteric languages fail are not purely because their syntax is obscure but because even once you learn the syntax, it is still hard to understand the code (example: Brainfuck). With Rust, once you learn the new syntax, you can understand Rust code with relatively little effort.
- dragonwriter 7y ago
  > Imo, the reason perl failed was not because the syntax was obscure but because even once you learned the syntax, it was still hard to read perl code. IMO, the reason Perl failed is that Perl 6 (which is a fairly awesome language in its own right) sucked up all the energy in moving Perl forward for too long and delivered too late, while competing languages kept providing usable progress (and avoided, as a consequence, looking dead, which may be as important as the actual usable progress itself.)

jononor 7y ago

New users expect things to be a bit different by assuming there are good reasons for change of convention. EDIT: this might very well be the case here though, especially future extension for similar operators and chain-ability.

wtetzner 7y ago
Right, which is why I mentioned that focusing on readability/maintainability is the right move in this case. I think we're in agreement.