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

Local async executors and why they should be the default

maciej.codes

Post reply on HN
Print view View original

311–320 of 327 posts

Re: Local async executors and why they should be the default

#311

Post by jacquesm »

pjmlp wrote: post #307
jacquesm wrote: post #211

Earlier quoted context omitted.

Yes, that one is terrible compared to the alternatives. If there is one thing that really irritates me about the way we go about IT then it is that stuff that works and is reliable and well understood gets tossed and replaced by 'new shiny thing' which then eventually undergoes the same treatment. We are eternally stuck in reinventing wheels, rather than that we make real progress in for instance reliability and are…

On first note, yes that is what happens when a language whose original scope was to be a systems programming language, and now wants to do everything. Regarding Bjarne Stroustrup, he wasn't dragged anything, his C++ is described in "The C++ Annotated Referece Manual" and "The Design and Evolution of C++", everything that happened after that is responsability of WG21, where he only has one vote among 300+ persons. The…

Hm, ok, I admit that bit was from memory, the quote that stuck was 'C++ now has as many additions and ways of doing things as there are ways of pronouncing 'Bjarne Stroustrup'', and stems from the days when his contributions were still much larger, say 20 years ago, whereas the 'remember the Vasa' quote is much more recent.

https://www.theregister.com/2018/06/18/bjarne_stroustrup_c_p...

I positively loved C++ when it was still called 'cfront' and after that it became more and more layers of complexity and tricks. C already had plenty of that (for instance, the weird pointer to a function syntax) and C++ went all out to drag in the various concepts that were present in other programming languages. This wasn't the same as the way say English borrows words and concepts from other languages freely, those are mostly just words and new ways to combinate existing ones. It would be as though English suddenly started using Kanji or logograms, or as if it would start using right-to-left writing or maybe even bottom to top in the middle of 'normal' sentences.

Such inclusivity increases the surface area of the language itself and ultimately makes life harder for everybody using it: you have to learn more because someone else could use these new constructs in their code and you may end up having to interact with it.

I think GvR got that one right with his 'there should be only one way to do it' but even that became a straightjacket.

I'm not saying I have all of the solutions and if Stroustrup wasn't the driving force behind C++'s complexity then I'll be happy to take that back. But I really believe that programming languages should strive for simplicity, just enough to make it all work so that the barrier to entry is small and the amount of gate-keeping can be kept to a minimum. That is the only way to really drive adoption and to hopefully undo some of the crazy fragmentation that we have in the programming language landscape.

Re: Local async executors and why they should be the default

#312

Post by vacuity »

pdimitar wrote: post #210
PoignardAzur wrote: post #123

Earlier quoted context omitted.

Because open-source projects survive on people having fun improving them. There just isn't that many people working on the Rust language as a day job, and they all have their hands full. Some of them have been working on foundational stuff that is required to get async rust to work, but it's work taking place over years. To give an example, the Inside Rust blog recently posted [1] an article about the Rust Trait Syst…

While I commend the effort, I am not sure that an even more complex lifetime syntax is what the Rust devs wanted... We'll see then.

I'm not sure if parent is correct about adding lifetime syntax. To my understanding, the new trait solver will fix bugs and make features more consistent ("why can I put a trait bound here but not there?"). People have mentioned 'self for self-referntial structs but I think that's just wishful thinking right now.

Re: Local async executors and why they should be the default

#313

Post by vacuity »

yencabulator wrote: post #264
pindab0ter wrote: post #57

Earlier quoted context omitted.

This assumes those titles are usable, which they often are not.

Populating the field automatically might nudge people toward doing the right thing, though.

Half-joke: HN scrapes first few text lines in HTML (in case the very first one isn't the title) and one of them has to be used as the title.

Re: Local async executors and why they should be the default

#314

Post by pjmlp »

jacquesm wrote: post #311
pjmlp wrote: post #307

Earlier quoted context omitted.

On first note, yes that is what happens when a language whose original scope was to be a systems programming language, and now wants to do everything. Regarding Bjarne Stroustrup, he wasn't dragged anything, his C++ is described in "The C++ Annotated Referece Manual" and "The Design and Evolution of C++", everything that happened after that is responsability of WG21, where he only has one vote among 300+ persons. The…

Hm, ok, I admit that bit was from memory, the quote that stuck was 'C++ now has as many additions and ways of doing things as there are ways of pronouncing 'Bjarne Stroustrup'', and stems from the days when his contributions were still much larger, say 20 years ago, whereas the 'remember the Vasa' quote is much more recent. https://www.theregister.com/2018/06/18/bjarne_stroustrup_c_p... I positively loved C++ when it…

The only languages capable of holding down to that simplicity require having some BDFL.

The moment the language evolution is driven by some kind of request for improvement, or similar process, with votes on what goes in or not, the outcome is design by commitee.

Many other languages aren't much better than C++, if you check their current versions and the Features/Year rate, including standard libraries.

Also having BDFL only works out as long as it is the original author, afterwards there is no guarantee that the successor has the same vision for the language.

The tragic long term meaning is to either accept complexity, or reboot the programming language ecosystem every couple of decades.

Re: Local async executors and why they should be the default

#315

Post by Ygg2 »

pjmlp wrote: post #308
Ygg2 wrote: post #85

Earlier quoted context omitted.

And green threads aren't a panacea. They introduce runtimes, which was something Rust avoided on purpose.

And then everyone has to bundle tokio anyway.

Tokio might is not a panacea either. If they pulled it in std, backwards compatibility would kill most evolution.

Re: Local async executors and why they should be the default

#316

Post by Ygg2 »

spinningslate wrote: post #105
Ygg2 wrote: post #85

Earlier quoted context omitted.

And green threads aren't a panacea. They introduce runtimes, which was something Rust avoided on purpose.

True. Rust's mandate for "zero runtime cost abstractions" is one of the better justifications for async/await. Because async/await, too, has significant limitations, notably: 1. Coloured functions 2. Placing the concurrency design decision (async vs not) on the implementer of a function, not the caller 3. Debugging complexity (1) and (2) are mutually, negatively, reinforcing. As the implementer of a library function,…

I'm not fan of async, but I don't like to deny reality by saying just use Structured Concurrency/Green threads/Magic Multithreading Powder. They all have their trade-offs.

And to be fair they are working to solve Colored functions.

However, async is still half-baked because no support for async traits and other corner cases.

Which was again caused by async being in RFC, development hell.

Re: Local async executors and why they should be the default

#317

Post by pjmlp »

Ygg2 wrote: post #315
pjmlp wrote: post #308

Earlier quoted context omitted.

And then everyone has to bundle tokio anyway.

Tokio might is not a panacea either. If they pulled it in std, backwards compatibility would kill most evolution.

At a certain point, one needs to question evolution at any price.

Re: Local async executors and why they should be the default

#318

Post by funcDropShadow »

ahupp wrote: post #150
jerf wrote: post #113

Earlier quoted context omitted.

I really think in the end, in another decade or two, the community consensus is going to be that async as it is conceived of today is simply a mistake, full stop. Think about it. Where did it come from in its current incarnation? Node. Why did Node choose it? Did it have a multiplicity of options and carefully choose the best one based on years of experience with each choice? No. Async was "chosen" because it was the…

I used/worked on a similar async model at FB long before I'd ever touched node. Threads are not really solving the same problem as async. Imagine you are building the FB newsfeed. You have 10 stories and want to fetch them as quickly as possible. The stories are all different types and each refers to other data: profile info, privacy, comments (which depend its own profile fetch), likes, etc. So you have this tree of…

> So you have this tree of dependent data fetches, how do you minimize the time waiting? You could walk the tree node-by-node, but that balloons your wait time. So you kick each bit of work off to a new thread and wait for it to be done. How do you wait for it?

This is exactly the kind of problem that is targeted by Project Loom [1] and structured concurrency [2] on the JVM. Async programming makes a lot of tools not applicable (or at least very cumbersome to use): debuggers, profilers, tracing tools, stack traces, etc.

[1]: https://openjdk.org/jeps/425

[2]: https://openjdk.org/jeps/428

Re: Local async executors and why they should be the default

#319

Post by earthling8118 »

exomancer wrote: post #86
thinkharderdev wrote: post #75

Earlier quoted context omitted.

It is opt-in. If you're using Tokio then you can specify whether you want to use a single-threaded or multi-threaded runtime. Multi-threaded is "default" in the sense that if you just use `#[tokio::main]` then you get a multi-threaded runtime but you can also just do `#[tokio::main(flavor = "current_thread")]` to get a single threaded executor. More to the point, even using a multi-threaded runtime won't spawn thread…

> It is opt-in. If you're using Tokio then you can specify whether you want to use a single-threaded or multi-threaded runtime. Multi-threaded is "default" in the sense that if you just use `#[tokio::main]` then you get a multi-threaded runtime but you can also just do `#[tokio::main(flavor = "current_thread")]` to get a single threaded executor. Doing something extra to get a behavior different than default is the d…

That argument doesn't hold up. Adding `#[tokio::main]` is opting in because it is that extra something that has to be done. Adding that line is opting in to the multithreaded runtime.
Post reply on HN