Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Update on await syntax in Rust

boats.gitlab.io

Post reply on HN
Print view View original

51–60 of 199 posts

Re: Update on await syntax in Rust

#51

Post by steveklabnik »

k__ wrote: post #49
svnpenn wrote: post #45

Earlier quoted context omitted.

await goes inside the function, at least thats how its done with JavaScript - do you have evidence otherwise? https://developer.mozilla.org/Web/JavaScript/Reference/Opera...

They worte explicitly that Rust went a different way than C#/JS

It's true, but that's around

  let result = do_stuff().await;
vs

  let result = await do_stuff();
not what your parent is talking about.

Re: Update on await syntax in Rust

#52

Post by _v7gu »

anchpop wrote: post #9
Analemma_ wrote: post #4

The fact that discussions over syntax generate pages and pages of furious bickering, while discussions over semantics (which is what actually matters) get a shrug, is the ultimate example of bikeshedding in PL design. Honestly, syntax just doesn't matter . Yes, particular poor choices can impede usability, but that's not applicable here, and ultimately after two minutes or so of learning the new syntax there's no dif…

Syntax may be irrelevant at the end of the day, but nice syntax can make a big difference in usability imo. I'm not following the Rust example, but discussions of it remind me about discussions about UFCS (Universal Function Call Syntax). That's where `foo(a, b)` can be rewritten as `a.foo(b)`. That may seem minor, but look at this code: half_square = divide(square(a), 2) In comparison to: half_square = a.square().di…

I think you can skip the empty () in D. The syntax becomes much more readable when you don't have to return to upper levels of functions. Thankfully pipes exist in functional languages, which makes it feel just right

    half_square =
      a
      |> square
      |> divide(_, 2)

Re: Update on await syntax in Rust

#53

Post by sgrove »

amboo7 wrote: post #48
rileywatkins wrote: post #8

What a milestone! This was the most impressive work in open source decision-making that I have ever followed (in my limited experience). People have contributed thousands of comments discussing this for over a year. It has even caused the team to rethink how discussions like this should be guided in the future beyond comments on GitHub issues. I cannot imagine how difficult it has been to manage it all, and I applaud…

I hope time is spent better in the future: https://wiki.haskell.org/Wadler's_Law , https://en.m.wikipedia.org/wiki/Law_of_triviality

The nuances in this case went well beyond what I was expecting - it's actually more than just syntax, this heavily crosses over into semantics. It's been a very impressive process, and I was surprised at the power of the solution they landed on.

- Rust has to find a syntax that can work with different underlying libraries (Rust can compile to lots of different targets, some will have capability to accommodate larger libraries than others)

- The abstraction can't incur undue overhead (callback-based solutions may cause allocations that are hard to keep under control and will split the language if it spreads too much)

- The syntax should be pleasant to write for at least the majority of people (modeling your entire application as a state machine around async computation is pretty unpleasant)

- The compiler has to be able to give helpful error messages (this was a problem early on I think)

- Language authors had to think about how the borrow checker would work across async points, and whether to invest in changing the language to make that possible.

- and so on and so on

I really loved this talk by Without Boats (the author of the friendly article) going over all this stuff, really gave me a good sense of what they were up against https://www.youtube.com/watch?v=skos4B5x7qE

Re: Update on await syntax in Rust

#54

Post by sagichmal »

ridiculous_fish wrote: post #33
sagichmal wrote: post #22

Earlier quoted context omitted.

You typically don't, as knowing which physical thread you're running in is (thankfully) becoming a relic of the past.

UI programming is one domain where it's important to know this.

Yes, that's fair. My domain is backend.

(I use and love fish shell for many years now; thank you.)

Re: Update on await syntax in Rust

#55

Post by staticassertion »

hyperion2010 wrote: post #39
aerovistae wrote: post #23

Earlier quoted context omitted.

I would say syntax is everything. What's the difference between python and Haskell without syntax?

Lazy vs strict semantics are completely orthogonal to the syntax [0]. (foo a b c) looks the same in a lazy language as it does in a strict language but oh boy are the results surprisingly different if you don't already know what you're in for. 0. Though some would argue that making them completely orthogonal to the point where the user can't tell the difference is a horrible design decision.

> Lazy vs strict semantics are completely orthogonal to the syntax [0]

Alternatively, the syntax in Haskell just lends itself to lazy evaluation, and requires explicit annotation syntax to be strict. Contrasted with Python, which has a syntax that makes strict evaluation an easier default to express.

If all languages can express, with some effort, the same exact semantics as any other language, then the only difference is syntax.

Re: Update on await syntax in Rust

#56

Post by sagichmal »

nostrademons wrote: post #31
sagichmal wrote: post #17

Earlier quoted context omitted.

Whatever pleasantness may come from that or any other specific example is totally outweighed by the constant overhead of having to remember that there are N ways to do 1 thing. As a primary rule: the best programming grammar has the fewest such ambiguities, ideally zero.

Folks who really believe that program in lambda calculus. In practice, syntax is the UI for a programming language. And just as with any UI, there's a bunch of tradeoffs between how easy the language is to use for a newbie (who knows nothing), how easy it is for casual user (who knows a few core constructs but has to lookup advanced functionality), how productive it is for an expert (who has a vast working memory of…

I think this is a fair summary, but I also think that C++ and Perl can be pretty fairly judged as failures, due to, or in the ways that, you enumerate.

Put another way, it is not true that powerful languages must necessarily be impenetrable.

Put still another way, the amount of typing you do (within certain bounds of reason) is an almost totally irrelevant metric when judging a programming language.

Re: Update on await syntax in Rust

#57

Post by nathcd »

Analemma_ wrote: post #4

The fact that discussions over syntax generate pages and pages of furious bickering, while discussions over semantics (which is what actually matters) get a shrug, is the ultimate example of bikeshedding in PL design. Honestly, syntax just doesn't matter . Yes, particular poor choices can impede usability, but that's not applicable here, and ultimately after two minutes or so of learning the new syntax there's no dif…

Indeed. I'm reminded of http://www.paulgraham.com/identity.html. I think it's just easy to have an opinion on syntax.

I think this also highlights the pitfalls of being community-centric. If Rust were run more like chromium or something, this sort of thing just ceases to be an issue. Major kudos to the Rust team for managing it really well.

Re: Update on await syntax in Rust

#58

Post by [deleted] »

anchpop wrote: post #9
Analemma_ wrote: post #4

The fact that discussions over syntax generate pages and pages of furious bickering, while discussions over semantics (which is what actually matters) get a shrug, is the ultimate example of bikeshedding in PL design. Honestly, syntax just doesn't matter . Yes, particular poor choices can impede usability, but that's not applicable here, and ultimately after two minutes or so of learning the new syntax there's no dif…

Syntax may be irrelevant at the end of the day, but nice syntax can make a big difference in usability imo. I'm not following the Rust example, but discussions of it remind me about discussions about UFCS (Universal Function Call Syntax). That's where `foo(a, b)` can be rewritten as `a.foo(b)`. That may seem minor, but look at this code: half_square = divide(square(a), 2) In comparison to: half_square = a.square().di…

[deleted]

Re: Update on await syntax in Rust

#59

Post by ben509 »

steveklabnik wrote: post #27
yingw787 wrote: post #12

I'm not familiar around the syntax, but I'm interested to know how much of this was a religious battle and how much of it results in meaningful complications for user code down the line. I've heard really good things about the Rust community (like nothing bad at all), until maybe two weeks ago when somebody mentioned this stuff. I'm a really big fan of not having religious battles. Is this syntax for native coroutine…

> I'm interested to know how much of this was a religious battle and how much of it results in meaningful complications for user code down the line. Due to the connotations of "religious battle", it's hard to get a good answer here. Nobody wants to be painted in this light. > Is this syntax for native coroutines? No. > Can it be combined with existing user and stdlib syntax? Yes. > What pathways for syntax developmen…

> Due to the connotations of "religious battle", it's hard to get a good answer here. Nobody wants to be painted in this light.

Haven't we all found ourselves lined up as one of a pair of camps over some heated dispute over a bit of minutiae? The whole time you know it's a bit silly, but not entirely and you feel compelled to continue to argue.

Using a term like "religious battles" with tongue firmly in cheek is recognizing that we're prone to such things because we're human beings, by putting a lampshade on it.

Re: Update on await syntax in Rust

#60

Post by jerf »

staticassertion wrote: post #55
hyperion2010 wrote: post #39

Earlier quoted context omitted.

Lazy vs strict semantics are completely orthogonal to the syntax [0]. (foo a b c) looks the same in a lazy language as it does in a strict language but oh boy are the results surprisingly different if you don't already know what you're in for. 0. Though some would argue that making them completely orthogonal to the point where the user can't tell the difference is a horrible design decision.

> Lazy vs strict semantics are completely orthogonal to the syntax [0] Alternatively, the syntax in Haskell just lends itself to lazy evaluation, and requires explicit annotation syntax to be strict. Contrasted with Python, which has a syntax that makes strict evaluation an easier default to express. If all languages can express, with some effort, the same exact semantics as any other language, then the only differen…

I'd submit the key difference in Haskell syntax is actually currying, not laziness. Haskell syntax privileges currying, and an executed function is just a curried function that has all of its parameters. By contrast, currying in languages with Algol-descended syntax always requires more rigamarole. It's possible, of course, in a lot of them, but it's harder than just a function call missing some of its arguments.
Post reply on HN