3 ms·

I like this proposal, a lot. I believe the prevailing languages of the next decade will solve the colored function problem not by removing colors but by integra

by dcow 5y ago

I like this proposal, a lot. I believe the prevailing languages of the next decade will solve the colored function problem not by removing colors but by integrating the concept into the syntax so as to achieve the appearance thereof. In other words: make calling either one a simple matter of context which the compiler should carry 99% of the time and the user should only worry about when there's a reason to do so (when the compiler cannot infer or the alternate context is needed explicitly). If the user wants an async runtime, so be it. If the user has no need for one, that should work too. The magic will be in making this seamless so that neither camp feels left out.

bsder 5y ago
At this point, I'm pretty convinced that "async" in 10 years is going to be like "object oriented" is now. A gigantic dead end that we're barrelling down for the wrong reasons--in this instance because everything web must be Javascript and work around all its warts. Every time someone talks about async, they always forget that you need an Executor, and those executors always have problems because they don't have the boundedness of Javascript. Using Javascript means your executors can only fire on a very constrained set of events that are completely prescribed. The moment you use something like Rust, that assumption is out the window and now your executor can't just do a couple of sockets and some DOM things. It has to accommodate sockets, timeouts, message queues that might wakeup by getting a message from another threads, character file descriptor devices, a terminal screen refresh, a video card vertical blanking event, etc. In short, your Executor has to accommodate an infinite variety of events when using async outside of the bounds of Javascript. Effectively everybody has to write their own personal Executor the moment they do something other than an IP socket. That's not an "improvement" in programming. That's a step backwards.
- eloff 5y ago
  I'm not certain you're wrong, but not for those reasons. There are still threads for all the long tail of synchronous operations. It's easy enough to do from Tokio or other async frameworks. However, the go approach of making async look like sync code is certainly much easier to write and read code for. I'm skeptical that async is really superior to that.
  - asimpletune 5y ago
    Futures and channels I think are abstractions that solve different problems. Channels for instance are really good for producer/consumer problems. Futures on the other hand can be extremely elegant and flexible in ways that channels aren’t great at.
    - eloff 5y ago
      That is true, but not the point making. I'm talking about goroutines versus async/await. Both have an async runtime under the hood, but goroutines feel just like normal programming.
- dcow 5y ago
  That's why I like the idea of scoped executors rather than trying to have a global executor do everything. Libs should provide their own executors and manage their own async event handling while allowing the user to provide their own implementation if needed (e.g. for single threaded test code where performance is not a problem or e.g. in a production environment where you can heavily optimize the executor if your requirements demand it). If you don't call any of the async overloaded functions in a lib, then you don't get any of the async code compiled in, including the runtime.
- pdpi 5y ago
  I don’t think any of this is about bringing the JS execution model to other languages. Rather, it’s about making it easier to build the next nginx.
jayd16 5y ago
A major consumer of async needs those seams. You often need the coloring because in many situations you want explicit control of what will yield execution. You might want to hold on to a UI thread or a specific OS thread for interop. A choice of all sync or all async is not good enough either. There might be some better syntax with scopes but Kotlin hasn't been able to do away with the off the UI thread problem. I won't say we'll never solve it but I don't think the solution is here yet.
- dcow 5y ago
  I'm not suggesting one or the other all in and neither does the article. I think you'd be quite happy with the full proposal. You can control whether you get the async or sync version by calling from an async or sync closure, respectively, essentially.
  - jayd16 5y ago
    Yes, I think we mostly agree. I was trying to add some context to the problem. I apologize that my slightly more pessimistic take on where we currently are was construed as disagreement.
- saurik 5y ago
  This problem was already solved a long time ago: asynchronous execution is a monad (as is error handling and list comprehension and any number of other fun features), and do syntax is that syntax sugar people are looking for that lets you decide to dip below the abstraction on a case by case basis... only no one seems to want to build support for monads into their language as they think they are too complicated or smell like haskell (is that even a bad thing?!) or something (and then you get awkward stuff like Rust deciding to take the data structure from a popular monad--Either, as Result--but providing none of the scaffolding or behaviors or synergistic language features to make it pleasant to use :/).

by dcow 5y ago

bsder 5y ago

At this point, I'm pretty convinced that "async" in 10 years is going to be like "object oriented" is now. A gigantic dead end that we're barrelling down for the wrong reasons--in this instance because everything web must be Javascript and work around all its warts. Every time someone talks about async, they always forget that you need an Executor, and those executors always have problems because they don't have the boundedness of Javascript. Using Javascript means your executors can only fire on a very constrained set of events that are completely prescribed. The moment you use something like Rust, that assumption is out the window and now your executor can't just do a couple of sockets and some DOM things. It has to accommodate sockets, timeouts, message queues that might wakeup by getting a message from another threads, character file descriptor devices, a terminal screen refresh, a video card vertical blanking event, etc. In short, your Executor has to accommodate an infinite variety of events when using async outside of the bounds of Javascript. Effectively everybody has to write their own personal Executor the moment they do something other than an IP socket. That's not an "improvement" in programming. That's a step backwards.

eloff 5y ago
I'm not certain you're wrong, but not for those reasons. There are still threads for all the long tail of synchronous operations. It's easy enough to do from Tokio or other async frameworks. However, the go approach of making async look like sync code is certainly much easier to write and read code for. I'm skeptical that async is really superior to that.
- asimpletune 5y ago
  Futures and channels I think are abstractions that solve different problems. Channels for instance are really good for producer/consumer problems. Futures on the other hand can be extremely elegant and flexible in ways that channels aren’t great at.
  - eloff 5y ago
    That is true, but not the point making. I'm talking about goroutines versus async/await. Both have an async runtime under the hood, but goroutines feel just like normal programming.
dcow 5y ago
That's why I like the idea of scoped executors rather than trying to have a global executor do everything. Libs should provide their own executors and manage their own async event handling while allowing the user to provide their own implementation if needed (e.g. for single threaded test code where performance is not a problem or e.g. in a production environment where you can heavily optimize the executor if your requirements demand it). If you don't call any of the async overloaded functions in a lib, then you don't get any of the async code compiled in, including the runtime.
pdpi 5y ago
I don’t think any of this is about bringing the JS execution model to other languages. Rather, it’s about making it easier to build the next nginx.

jayd16 5y ago

A major consumer of async needs those seams. You often need the coloring because in many situations you want explicit control of what will yield execution. You might want to hold on to a UI thread or a specific OS thread for interop. A choice of all sync or all async is not good enough either. There might be some better syntax with scopes but Kotlin hasn't been able to do away with the off the UI thread problem. I won't say we'll never solve it but I don't think the solution is here yet.

dcow 5y ago
I'm not suggesting one or the other all in and neither does the article. I think you'd be quite happy with the full proposal. You can control whether you get the async or sync version by calling from an async or sync closure, respectively, essentially.
- jayd16 5y ago
  Yes, I think we mostly agree. I was trying to add some context to the problem. I apologize that my slightly more pessimistic take on where we currently are was construed as disagreement.
saurik 5y ago
This problem was already solved a long time ago: asynchronous execution is a monad (as is error handling and list comprehension and any number of other fun features), and do syntax is that syntax sugar people are looking for that lets you decide to dip below the abstraction on a case by case basis... only no one seems to want to build support for monads into their language as they think they are too complicated or smell like haskell (is that even a bad thing?!) or something (and then you get awkward stuff like Rust deciding to take the data structure from a popular monad--Either, as Result--but providing none of the scaffolding or behaviors or synergistic language features to make it pleasant to use :/).