4 ms·

Not as much as in Haskell and/or Erlang.

by thesz 13y ago

bunderbunder 13y ago
Perhaps, perhaps not. My impression has been that of late the top-tier .NET langauges have better support for asynchronous programming when considered from a pragmatic perspective, because a lot more care has been spent on designing the relevant APIs and language features to be accessible and easy to learn. Async/await really is a great abstraction on top of task parallelism; it's easy to understand without having to wade through a zillion blog posts explaining how it's just like burritos, Lego blocks, the OSI model, or homeobox genes, or underpants. Which means that it's something you could actually get away with using in enterprise software development, rather than something that'll earn you a reputation for developing software that your colleagues wouldn't be able to maintain.
- thesz 13y ago
  I don't know. I still struggle to use async/await for, for example, async reading from file. It is not that easy, actually. I have to disagree to you also on the ground that almost everything in Haskell is (and many important things in Erlang are) async without any annotations. Haskell is lazy and that alone makes many operations "asynchronous", so to say. It's run-time system is heavily threaded and employs work stealing to fit millions of green threads into several system threads. You can write your own scheduler [1] for your purposes, if you please. As fine grained as you want it to. [1] http://hackage.haskell.org/package/meta-par http://hackage.haskell.org/package/meta-par In fact, .Net is years behind of Haskell and Erlang. Just because it borrows features from Haskell (and other languages) libraries and bolts them into language. The difference here is that things in libraries are first-class, you can create them at run-time. That does not often apply to language constructs.
  - thirsteh 13y ago
    I'm just being pedantic, but the asynchronous I/O of Haskell isn't really associated with laziness, although it does have lazy I/O (which often is a bad idea.) Go essentially does all the same things (all I/O is asynchronous under the hood using epoll, kqueue, etc.) without being lazy.
    - thesz 13y ago
      We are talking not only about I/O. We are talking about async stuff in general. Lazy evaluation, combined with par/pseq functions and concurrency, is essentially asynchronous computation. You fire the computation, you take result later if you need it at all.

Not as much as in Haskell and/or Erlang.

by thesz 13y ago

Not as much as in Haskell and/or Erlang.

Perhaps, perhaps not. My impression has been that of late the top-tier .NET langauges have better support for asynchronous programming when considered from a pragmatic perspective, because a lot more care has been spent on designing the relevant APIs and language features to be accessible and easy to learn. Async/await really is a great abstraction on top of task parallelism; it's easy to understand without having to wade through a zillion blog posts explaining how it's just like burritos, Lego blocks, the OSI model, or homeobox genes, or underpants. Which means that it's something you could actually get away with using in enterprise software development, rather than something that'll earn you a reputation for developing software that your colleagues wouldn't be able to maintain.

thesz 13y ago
I don't know. I still struggle to use async/await for, for example, async reading from file. It is not that easy, actually. I have to disagree to you also on the ground that almost everything in Haskell is (and many important things in Erlang are) async without any annotations. Haskell is lazy and that alone makes many operations "asynchronous", so to say. It's run-time system is heavily threaded and employs work stealing to fit millions of green threads into several system threads. You can write your own scheduler [1] for your purposes, if you please. As fine grained as you want it to. [1] http://hackage.haskell.org/package/meta-par http://hackage.haskell.org/package/meta-par In fact, .Net is years behind of Haskell and Erlang. Just because it borrows features from Haskell (and other languages) libraries and bolts them into language. The difference here is that things in libraries are first-class, you can create them at run-time. That does not often apply to language constructs.
- thirsteh 13y ago
  I'm just being pedantic, but the asynchronous I/O of Haskell isn't really associated with laziness, although it does have lazy I/O (which often is a bad idea.) Go essentially does all the same things (all I/O is asynchronous under the hood using epoll, kqueue, etc.) without being lazy.
  - thesz 13y ago
    We are talking not only about I/O. We are talking about async stuff in general. Lazy evaluation, combined with par/pseq functions and concurrency, is essentially asynchronous computation. You fire the computation, you take result later if you need it at all.