9 ms·

It seems they've settled on using a postfix approach. I can't help but feel this is a mistake. Rust is already a weird language to come to from the likes of pyt

by foota 8y ago

It seems they've settled on using a postfix approach. I can't help but feel this is a mistake. Rust is already a weird language to come to from the likes of python, Java, or Javascript, and it feels to me like this relatively unknown approach of putting the operator at the end is a mistake that will add another confusing aspect of the language. I feel like the committee has worried about the wrong things when considering postfix vs prefix. Their main concern seemed to have been the extra syntax required to make prefix work with . And ? (i.e., (await foo).bar() ), but while avoiding this makes for a more optimized language I'm concerned they've missed the impact this will have on new people. Or maybe I'm just a Luddite :)

wtetzner 8y ago
> 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 8y 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 8y 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 8y 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 8y 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 8y ago
        > Rust is, indeed, just syntactically insane to a new learner (honestly, worse than perl ever was). Can you elaborate?
        ajross 8y 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?
  - vedantroy 8y 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 8y 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 8y 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 8y 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.
Twisol 8y ago
For what it's worth, it seems that Rust isn't alone here. C# 8.0 introduced postfix `switch` expressions (https://devblogs.microsoft.com/dotnet/do-more-with-patterns-in-c-8-0/ https://devblogs.microsoft.com/dotnet/do-more-with-patterns-...), which are along the same lines of what's suggested for `match` in Rust further along in the OP. I agree that it looks strange at first. But I think I'll get used to it.
- albru123 8y ago
  Thanks for pointing this out, I had no idea they implemented this for C# 8.0 Also is it just me or the switch pattern really is inspired by Rust match?
  - nixpulvis 8y ago
    Pattern matching syntax across many languages is very similar, most notably inspired by ML I'd say.
  - anp 8y ago
    Pattern matching as is in Rust has many notable precedents that IIRC the C# folks considered as prior art, not least of which being F#.
giornogiovanna 8y ago
Literally everyone else uses prefix await, so this will be a problem. But, - this is a lot easier to chain, which is very useful, and - the "future expansion" might bring a prefix await anyway (although introducing two syntaxes for the same thing might be even worse). I'd prefer "f await" to "f.await" because it feels a lot less magical and lets me stick to my intuition that "." is just for stuff implemented by the library, but maybe that's just me.
- hexane360 8y ago
  My personal preference is for a happy medium between "f await" and "f.await", which is some other character that indicates "special postfix". Sort of like how func() is clearly different from macro!(), we can have "expr->keyword" or "expr.keyword!" to differentiate from "expr.property"
- 62747478182 8y ago
  > Literally everyone else uses prefix await, so this will be a problem. Kotlin uses `.await()`.
- empath75 8y ago
  If you’re able to figure out how to write working rust code, you can learn how to google where ‘await’ goes.
holy_city 8y ago
> Rust is already a weird language Some folks came up with the idea of a "weirdness" budget - arguing that Rust had come close to using it all up. >I feel like the committee has worried about the wrong things There is no "committee" really, and all the worries have been expressed and weighed. The debate over this syntax has been going on for months and had huge community involvement. It's all been summed up in this document: https://paper.dropbox.com/doc/Await-Syntax-Write-Up--AcIbhZ1tPTCloXb2fmFpBTt~Ag-t9NlOSeI4RQ8AINsaSSyJ https://paper.dropbox.com/doc/Await-Syntax-Write-Up--AcIbhZ1... I was definitely in the prefix camp before I read that document.
- foota 8y ago
  Thanks, I'd read the intro but missed that. I don't really see how they refute this argument though? Clearly they state arguments both in favor of postfix and prefix but it feels like some framework for weighing the arguments is missing, otherwise it just comes down to how individuals weigh the arguments.
  - holy_city 8y ago
    That document isn't about arguing one way or the other, it lists all the different options and pros/cons. The post thread is the current stance of the lang team and letting everyone know they're going to make the final decision later this month. Boats' keynote at rust-latam goes into some more detail as well. https://www.youtube.com/watch?v=skos4B5x7qE https://www.youtube.com/watch?v=skos4B5x7qE I'm just a casual observer here, but it seems like just about every argument and position on the subject has been iterated across Github, internals.rust-lang.org, the IRC/Discourse/Zulip chats, Reddit, and now HN. This post by boats is just the next stepping stone alerting the community to the direction the team is leading and that it's going to be over soon.
- agency 8y ago
  Thanks for the link. As an outsider I also thought it seemed weird given so many other languages use prefix, but it makes sense with this framing that the main concern is the interaction with the ? operator.
jwr 8y ago
> Rust is already a weird language to come to from the likes of python, Java, or Javascript Every time I see a statement like this, I remember a (paraphrased) statement from Rich Hickey: "[musical] instruments are made for people who can play them!". I think unless you are specifically designing a beginner language (like Scratch), you should not take into consideration "ease of use" or "familiarity" arguments.
- joshuamorton 8y ago
  Counterpoint: APL and perl vs. python. Python did take usability into account and familiarity. UX is important. Developers are users. As a language (or in general tool) designer you have a responsibility to make that tool easy to use, and difficult to misuse. Familiarity is a big part of that, although ease of use is bigger (which is probably why python got the traction it did despite being unfamiliar to people who came from braces-land).
  - diggan 8y ago
    Different languages for different purposes. AFAIK, python is made for being easy to use and write, Clojure (Rich Hickey) is a pragmatic language for getting things done. Different languages will focus on different things and I think that's a good thing. If I got to choose between the Clojure I know today VS a Clojure designed for ease of use and being familiar, I'm pretty sure I would chose the first. Just like APL is much better for some tasks compared to Python, and vice versa.
    - joshuamorton 8y ago
      > is a pragmatic language for getting things done What does this mean though? Empirically speaking, a lot more "gets done" today using python than clojure. So, perhaps being easy to use is more pragmatic than whatever Rich means.
    - kazinator 8y ago
      > Clojure designed for ease of use and being familiar I.e. Lisp, basically.
atoav 8y ago
Rust has some existing postifx syntax (shouldn’t it be called suffix?). And to be honest it didn’t threw me of in the slightest when I started with Rust. Using a questionmark at the end to let an error bubble up seems quite intuitive. The most scary thing that threw me off the most were lifetimes (which for beginners sake are gladly not needed all that often). I have trust in the Rust developers and the community that they will choose something very well thought out, because for now the whole language feels incredibly well considered.
axaxs 8y ago
I tend to agree with you. I love what Rust is doing, but can't force myself to use it because it's, to me, not easy to read. As I've grown, I much prefer simpler languages. Go, Python, and to a lesser extent C(while it can be simple, people abuse it in weird ways) all fit the bill. I wonder how many other folks have this simple aversion...

by foota 8y ago

wtetzner 8y ago

> 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 8y 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 8y 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 8y 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 8y 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 8y ago
      > Rust is, indeed, just syntactically insane to a new learner (honestly, worse than perl ever was). Can you elaborate?
      - ajross 8y 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?
- vedantroy 8y 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 8y 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 8y 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 8y 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.

Twisol 8y ago

For what it's worth, it seems that Rust isn't alone here. C# 8.0 introduced postfix `switch` expressions (https://devblogs.microsoft.com/dotnet/do-more-with-patterns-in-c-8-0/ https://devblogs.microsoft.com/dotnet/do-more-with-patterns-...), which are along the same lines of what's suggested for `match` in Rust further along in the OP. I agree that it looks strange at first. But I think I'll get used to it.

albru123 8y ago
Thanks for pointing this out, I had no idea they implemented this for C# 8.0 Also is it just me or the switch pattern really is inspired by Rust match?
- nixpulvis 8y ago
  Pattern matching syntax across many languages is very similar, most notably inspired by ML I'd say.
- anp 8y ago
  Pattern matching as is in Rust has many notable precedents that IIRC the C# folks considered as prior art, not least of which being F#.

giornogiovanna 8y ago

Literally everyone else uses prefix await, so this will be a problem. But, - this is a lot easier to chain, which is very useful, and - the "future expansion" might bring a prefix await anyway (although introducing two syntaxes for the same thing might be even worse). I'd prefer "f await" to "f.await" because it feels a lot less magical and lets me stick to my intuition that "." is just for stuff implemented by the library, but maybe that's just me.

hexane360 8y ago
My personal preference is for a happy medium between "f await" and "f.await", which is some other character that indicates "special postfix". Sort of like how func() is clearly different from macro!(), we can have "expr->keyword" or "expr.keyword!" to differentiate from "expr.property"
62747478182 8y ago
> Literally everyone else uses prefix await, so this will be a problem. Kotlin uses `.await()`.
empath75 8y ago
If you’re able to figure out how to write working rust code, you can learn how to google where ‘await’ goes.

holy_city 8y ago

> Rust is already a weird language Some folks came up with the idea of a "weirdness" budget - arguing that Rust had come close to using it all up. >I feel like the committee has worried about the wrong things There is no "committee" really, and all the worries have been expressed and weighed. The debate over this syntax has been going on for months and had huge community involvement. It's all been summed up in this document: https://paper.dropbox.com/doc/Await-Syntax-Write-Up--AcIbhZ1tPTCloXb2fmFpBTt~Ag-t9NlOSeI4RQ8AINsaSSyJ https://paper.dropbox.com/doc/Await-Syntax-Write-Up--AcIbhZ1... I was definitely in the prefix camp before I read that document.

foota 8y ago
Thanks, I'd read the intro but missed that. I don't really see how they refute this argument though? Clearly they state arguments both in favor of postfix and prefix but it feels like some framework for weighing the arguments is missing, otherwise it just comes down to how individuals weigh the arguments.
- holy_city 8y ago
  That document isn't about arguing one way or the other, it lists all the different options and pros/cons. The post thread is the current stance of the lang team and letting everyone know they're going to make the final decision later this month. Boats' keynote at rust-latam goes into some more detail as well. https://www.youtube.com/watch?v=skos4B5x7qE https://www.youtube.com/watch?v=skos4B5x7qE I'm just a casual observer here, but it seems like just about every argument and position on the subject has been iterated across Github, internals.rust-lang.org, the IRC/Discourse/Zulip chats, Reddit, and now HN. This post by boats is just the next stepping stone alerting the community to the direction the team is leading and that it's going to be over soon.
agency 8y ago
Thanks for the link. As an outsider I also thought it seemed weird given so many other languages use prefix, but it makes sense with this framing that the main concern is the interaction with the ? operator.

jwr 8y ago

> Rust is already a weird language to come to from the likes of python, Java, or Javascript Every time I see a statement like this, I remember a (paraphrased) statement from Rich Hickey: "[musical] instruments are made for people who can play them!". I think unless you are specifically designing a beginner language (like Scratch), you should not take into consideration "ease of use" or "familiarity" arguments.

joshuamorton 8y ago
Counterpoint: APL and perl vs. python. Python did take usability into account and familiarity. UX is important. Developers are users. As a language (or in general tool) designer you have a responsibility to make that tool easy to use, and difficult to misuse. Familiarity is a big part of that, although ease of use is bigger (which is probably why python got the traction it did despite being unfamiliar to people who came from braces-land).
- diggan 8y ago
  Different languages for different purposes. AFAIK, python is made for being easy to use and write, Clojure (Rich Hickey) is a pragmatic language for getting things done. Different languages will focus on different things and I think that's a good thing. If I got to choose between the Clojure I know today VS a Clojure designed for ease of use and being familiar, I'm pretty sure I would chose the first. Just like APL is much better for some tasks compared to Python, and vice versa.
  - joshuamorton 8y ago
    > is a pragmatic language for getting things done What does this mean though? Empirically speaking, a lot more "gets done" today using python than clojure. So, perhaps being easy to use is more pragmatic than whatever Rich means.
  - kazinator 8y ago
    > Clojure designed for ease of use and being familiar I.e. Lisp, basically.

atoav 8y ago

Rust has some existing postifx syntax (shouldn’t it be called suffix?). And to be honest it didn’t threw me of in the slightest when I started with Rust. Using a questionmark at the end to let an error bubble up seems quite intuitive. The most scary thing that threw me off the most were lifetimes (which for beginners sake are gladly not needed all that often). I have trust in the Rust developers and the community that they will choose something very well thought out, because for now the whole language feels incredibly well considered.

axaxs 8y ago

I tend to agree with you. I love what Rust is doing, but can't force myself to use it because it's, to me, not easy to read. As I've grown, I much prefer simpler languages. Go, Python, and to a lesser extent C(while it can be simple, people abuse it in weird ways) all fit the bill. I wonder how many other folks have this simple aversion...