[_Codemonkeyism]

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.

[marcosdumay]

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]

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]

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]

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]

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

[_Codemonkeyism]

In Haskell you'd have the type signature everywhere I think, mostly as a monad transformer.