4 ms·

Wasn't there a language where every call was async? Instead of async ... A/returing Future[A] it did/would return A from method calls. If it didn't exist, one

Wasn't there a language where every call was async? Instead of async ... A/returing Future[A] it did/would return A from method calls. If it didn't exist, one can imagine one. A.x = 3 would be wrapped in A.map(_.x = 3) etc. So you write code that would be executed when you finally await a value. No more red/blue world. Would probably need coroutines instead of threads for executing.

icebraining 8y ago
Isn't Haskell somewhat like that, due to being lazy by default?
- _Codemonkeyism 8y ago
  In Haskell you'd have the type signature everywhere I think, mostly as a monad transformer.
  - _Codemonkeyism 8y ago
    Wow, how could this be voted down without comment. Go away trolls!
marcosdumay 8y ago
Just to post it as an answer instead of a question. That's Haskell's IO. It is just one of the lots of concurrency behaviors available in libraries. Also, parallelism is "free" on pure code.
- _Codemonkeyism 8y ago
  From my understanding, this is not Haskells IO - though my time with Haskell is limited. 1. Haskell uses special notation 'do' to handle access to IO wrapped values, e.g. (contrieved example, one would not use do for such simple cases) y = do x <- xWithIO return x + 1 instead of y = x + 1 2. Haskell method signatures do include IO, e.g. doSomething :: Int -> IO Int instead of def doSomething(i:Int):Int 3. Because IO is usually not the only effect managaging monad, as I've said in another comment, the type signature usually uses a type alias that does alias a monad transformer stack like type Result a = ReaderT Env ( ErrorT String ( StateT Integer Identity)) or concurrency mixed in 4. This the same as my Scala code, where I have cats FutureT monad transformers with Scalactic errors OrT Every stacks showing up all over my APIs as a type alias of 'WithErrors'. 5. 'Also, parallelism is "free" on pure code.' Not sure what's that got to do with it, but yes if you have no concurrency problems (concurrent writes to shared data) you don't need to think about concurrency and parallelism is free. But if my understanding is wrong, I'm happy to learn something about concurrency in Haskell without it showing in code and type signatures.
  - marcosdumay 8y ago
    Well, it does not have the exact same syntax of your example. Even more because your example was pure. Haskell does that automatically for pure code too (`y = x + 1` would do exactly what you described) but it's not really relevant. IO code always returns a promise, and the next statement on a `do` block may await the previous promise and yield the execution to whatever other piece of code can run, based on some rules on the compiler, based in large part on data dependency. If I'm reading your comment correctly, that is what you are asking for.
    - _Codemonkeyism 8y ago
      Sorry for being so confusing "Even more because your example was pure." No it wasn't which is the whole point. y = x + 1 means y = x.map(_ + 1) by default with async effects. "same syntax" Which is also the point, that there is syntax for the effects. When everything is async, there should be no special syntax as you have that syntax all over your code and it's redundant.

icebraining 8y ago

Isn't Haskell somewhat like that, due to being lazy by default?

_Codemonkeyism 8y ago
In Haskell you'd have the type signature everywhere I think, mostly as a monad transformer.
- _Codemonkeyism 8y ago
  Wow, how could this be voted down without comment. Go away trolls!

marcosdumay 8y ago

Just to post it as an answer instead of a question. That's Haskell's IO. It is just one of the lots of concurrency behaviors available in libraries. Also, parallelism is "free" on pure code.

_Codemonkeyism 8y ago
From my understanding, this is not Haskells IO - though my time with Haskell is limited. 1. Haskell uses special notation 'do' to handle access to IO wrapped values, e.g. (contrieved example, one would not use do for such simple cases) y = do x <- xWithIO return x + 1 instead of y = x + 1 2. Haskell method signatures do include IO, e.g. doSomething :: Int -> IO Int instead of def doSomething(i:Int):Int 3. Because IO is usually not the only effect managaging monad, as I've said in another comment, the type signature usually uses a type alias that does alias a monad transformer stack like type Result a = ReaderT Env ( ErrorT String ( StateT Integer Identity)) or concurrency mixed in 4. This the same as my Scala code, where I have cats FutureT monad transformers with Scalactic errors OrT Every stacks showing up all over my APIs as a type alias of 'WithErrors'. 5. 'Also, parallelism is "free" on pure code.' Not sure what's that got to do with it, but yes if you have no concurrency problems (concurrent writes to shared data) you don't need to think about concurrency and parallelism is free. But if my understanding is wrong, I'm happy to learn something about concurrency in Haskell without it showing in code and type signatures.
- marcosdumay 8y ago
  Well, it does not have the exact same syntax of your example. Even more because your example was pure. Haskell does that automatically for pure code too (`y = x + 1` would do exactly what you described) but it's not really relevant. IO code always returns a promise, and the next statement on a `do` block may await the previous promise and yield the execution to whatever other piece of code can run, based on some rules on the compiler, based in large part on data dependency. If I'm reading your comment correctly, that is what you are asking for.
  - _Codemonkeyism 8y ago
    Sorry for being so confusing "Even more because your example was pure." No it wasn't which is the whole point. y = x + 1 means y = x.map(_ + 1) by default with async effects. "same syntax" Which is also the point, that there is syntax for the effects. When everything is async, there should be no special syntax as you have that syntax all over your code and it's redundant.