A final proposal for Rust await syntax

Post by lucideer » Mon, May 06, 2019, 8:47 PM UTC

zokier wrote: post #161

lucideer wrote: post #131

This is way way off-topic but: I have never seen the word "postfix" used in this way. "Suffix" is the normal/common English word for this as far as I've always been aware. A quick search has it listed it as a synonym, but I can't find any usage outside tech and it sure seems like a tech-industry/coding erroneous neologism trying to balance the seemingly logical "post" -vs- "pre". Am I way off the mark here?

Even if it is tech neologism, what would make it erroneous?

Post by majewsky » Mon, May 06, 2019, 8:56 PM UTC

zzzcpan wrote: post #79

majewsky wrote: post #69

Earlier quoted context omitted.

> Obviously core devs of Google backed language cannot do better. They can only gain that trust from users within Google, not outside of Google. That's a non sequitur. Trust is not mandated by company boundaries. I for one trust in the competence of the Go maintainers, while at the same time having absolutely zero trust in Google as a company.

> I for one trust in the competence of the Go maintainers That's fine. But ultimately Go employees do not work for you and cannot put much effort into proving they are good at solving problems for you, since the company doesn't pay them to do it. There will not be a track record in users eyes of their design decisions and not much trust from users they are even capable of doing it well.

Post by majewsky » Mon, May 06, 2019, 9:00 PM UTC

arcticbull wrote: post #165

jkarneges wrote: post #75

I figure the reason the proposed syntax looks gross is because other languages have been using a prefixed await for many years. The Rust decision seems well thought out though, enough to make me wonder if perhaps other languages have been doing it wrong. My first experience with futures was in the form of QFuture ( https://doc.qt.io/qt-5/qfuture.html ), and there you call .result() to block and wait for the result. T…

IMO it's awkward for the following reasons: (1) It looks like a field access, and field accesses are "cheap", method invocations aren't. This breaks the 'conceptual weight' model when you look at a line of code. Field accesses are simple and understood. It becomes impossible to gauge the 'cost' of a line by looking at it unless you're intimately familiar with the workings of 'await' and there's no visual cue. (2) If…

Post by majewsky » Mon, May 06, 2019, 9:03 PM UTC

ajross wrote: post #148

simias wrote: post #107

Earlier quoted context omitted.

I've used perl5 for a long time (although these days I've replaced it with python in my toolchain, although I have my fair share of complaints about python as well) and I think your comparison is unfair. Rust's sometimes complicated syntax is made necessary by the very concept of the language. You need to be able to express lifetimes, you need to be able to express generics, you need to be able to strongly type lambd…

> Rust is noisy because it has to represent concepts that simply don't exist in other programming languages. In a few cases having to do with lifetime management and the borrow checker, that's certainly true. But the example at hand is fundamentally just cloning ideas from Javascript.

Post by kibwen » Mon, May 06, 2019, 9:12 PM UTC

nixpulvis wrote: post #141

gamegoblin wrote: post #129

Earlier quoted context omitted.

I wonder if I would ever find something like my_iter .foo() .bar() .return more appealing than return my_iter .foo() .bar(); I could see it happening, but I'll definitely need some time to get used to it.

See, now this is exactly my issue with this syntax, I generally expect to be able to "chain" things with the "." notation.