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

A final proposal for Rust await syntax

boats.gitlab.io

Post reply on HN
Print view View original

231–240 of 265 posts

Re: A final proposal for Rust await syntax

#231

Post by kazinator »

diggan wrote: post #83
joshuamorton wrote: post #59

Earlier quoted context omitted.

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 c…

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 i…

> Clojure designed for ease of use and being familiar

I.e. Lisp, basically.

Re: A final proposal for Rust await syntax

#232

Post by kazinator »

jwr wrote: post #114
13415 wrote: post #109

Earlier quoted context omitted.

I wouldn't use a programming language whose designer had this attitude.

Would you also refuse to play a musical instrument, because the designers had this attitude? Pretty much all musical instruments are "hard to play" and you have to learn them, sometimes for many years.

Professional grade, expensive instruments are highly playable compared to the junk.

Re: A final proposal for Rust await syntax

#233

Post by z1mm32m4n »

IngoBlechschmid wrote: post #33
wbl wrote: post #29

Earlier quoted context omitted.

Do notation solves that problem!

Came here to say that. I think do notation (and applicative idioms) are easily one of the most-underappreciated features outside the Haskell community.

It’s even nicer in Haskell because not only does do-notation make code look clean, await is a function, not an operator.

Want prefix await? Go for it!

    res
Want postfix? You can have that too!

    res
Being “just a function” means it composes with everything else in the language, something the Rust languages designers have held in high regard when designing this.

(But I also fully appreciate the design constraints that prevent Rust from using “just a method” or ”just a macro”)

Re: A final proposal for Rust await syntax

#234

Post by bobbylarrybobby »

jerf wrote: post #30
wbl wrote: post #28

Earlier quoted context omitted.

From what I've seen of Scheme they dont have this problem. Everyone implemented the feature they want or forks an implementation. And no one argues about syntax.

"And no one argues about syntax." No one argues about the syntax, because everybody "wins" and gets their own syntax as a result, which is often held up as a key part of the explanation for why the Lisp family languages are wonderful and fun and mind-expanding and just awesome in every way... yet rarely escape from "niche" status and are yet to even threaten to break into the really top-tier languages. Because langua…

http://winestockwebdesign.com/Essays/Lisp_Curse.html

Re: A final proposal for Rust await syntax

#235

Post by Const-me »

bvinc wrote: post #229
Const-me wrote: post #227

Language syntax and futures is only a half of the problem. IMO actual async IO implementation is harder. Too many incompatible platform-specific APIs: epoll and AIO on Linux, kqueue on BSD and OSX, IOCP and new thread pool API on Windows. I’m pretty sure I forgot couple others, and each of them have non-trivial amount of quirks, bugs, and performance-ruining edge cases. Also these APIs are not directly compatible to…

Most of the work you're talking about has been completed for a long time in the crate "mio". It abstracts out all of the platform dependent async io operations into a single consistent interface.

Are you sure about that?

I've looked at the library, it doesn't support anything besides epoll and IOCP, i.e. no BSD or OSX support, no AIO on Linux (the kernel one, not POSIX).

You probably don't want to consume IOCP API on Windows anymore, Vista introduced higher level and easier to use StartThreadpoolIo and friends.

Also on Windows, even with IOCP, you don't want to split async IO from thread pool. The OS kernel manages them both at the same time. Work stealing or other custom scheduling is usually slower than what kernel does.

Re: A final proposal for Rust await syntax

#236

Post by trashface »

As an old salty programmer, I don't understand why people are upset at this. Sure the syntax is unusual, but they had good reasons for it, and people are adaptable and get used to things.

Personally I like the fact that ".await" emphasizes that you are dealing with something fundamentally different from other language constructs, because futures _are_ fundamentally different.

Re: A final proposal for Rust await syntax

#237

Post by steveklabnik »

dbrgn wrote: post #208
ajross wrote: post #148

Earlier quoted context omitted.

> 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.

Actually JS just cloned those ideas from C# and Python.

... and when you get down into the details, there are significant differences in what Rust is doing as opposed to these languages, even if the high level idea is roughly the same.

Re: A final proposal for Rust await syntax

#240

Post by kazinator »

jerf wrote: post #30
wbl wrote: post #28

Earlier quoted context omitted.

From what I've seen of Scheme they dont have this problem. Everyone implemented the feature they want or forks an implementation. And no one argues about syntax.

"And no one argues about syntax." No one argues about the syntax, because everybody "wins" and gets their own syntax as a result, which is often held up as a key part of the explanation for why the Lisp family languages are wonderful and fun and mind-expanding and just awesome in every way... yet rarely escape from "niche" status and are yet to even threaten to break into the really top-tier languages. Because langua…

That's just a meme from that Lisp Curse article and wherevernot; it's not spread by people who have actually worked in a Lisp code base.
Post reply on HN