4 ms·

> actors, futures/promises and async/await style co-routines which are all extremely available in all of the major languages Language features are indeed avail

> actors, futures/promises and async/await style co-routines which are all extremely available in all of the major languages Language features are indeed available. Runtime features backing them are only available in Go, erlang and .NET. If you only need concurrency for CPU bound calculations, even C++ has decent options, e.g. OpenMP works great for my tasks. However, OpenMP offers nothing for IO. The point of go’s co-routines or .NET’s async-await, they allow to run a mix of CPU bound and IO bound code, and do so in parallel utilizing all available hardware threads.

kasey_junk 8y ago
Green thread schedulers are available (and I’ve had direct experience with them) in the JVM & C++ as well.
- Const-me 8y ago
  Scheduling is not enough. For efficient IO you need a scheduler that’s tightly coupled with OS-specific kernel mode APIs for async IO. Java has support for that in java.nio.channels but that’s limited and is not integrated with the rest of their standard library. C++ can do that, too, but quite hard in practice. Runtimes like Go, .NET and erlang already have that stuff included. There’re some limitations (e.g. erlang doesn’t support that on Windows, BTW they call the feature “kernel poll”), but still it works great and very easy to use.
  - kasey_junk 8y ago
    Take a look at quasar for the JVM. In practice I’ve found it outperforms* golang in my workloads. * there is a small fixed overhead increase in memory.
    - Const-me 8y ago
      There’re indeed multiple third-party libraries for that in many languages. E.g. for C++ we have lubuv, boost.asio, etc. However, built-in solutions have upsides. They work out of the box i.e. deployment is simpler. They’re integrated into the language, e.g. most network IO in golang is asynchronous under the hood, compiler and runtime do that automatically. They’re integrated into standard libraries, e.g. in .NET all streams be it files, sockets, or transforms like compressors and encryptors support asynchronous operations. The support is usually better, too.
      - apta 8y ago
        The JVM is getting coroutines with Project Loom. The same Quasar devs are integrating it into the JVM.
    - apta 8y ago
      Quasar is going to be integrated into the JVM by means of project Loom.

kasey_junk 8y ago

Green thread schedulers are available (and I’ve had direct experience with them) in the JVM & C++ as well.

Const-me 8y ago
Scheduling is not enough. For efficient IO you need a scheduler that’s tightly coupled with OS-specific kernel mode APIs for async IO. Java has support for that in java.nio.channels but that’s limited and is not integrated with the rest of their standard library. C++ can do that, too, but quite hard in practice. Runtimes like Go, .NET and erlang already have that stuff included. There’re some limitations (e.g. erlang doesn’t support that on Windows, BTW they call the feature “kernel poll”), but still it works great and very easy to use.
- kasey_junk 8y ago
  Take a look at quasar for the JVM. In practice I’ve found it outperforms* golang in my workloads. * there is a small fixed overhead increase in memory.
  - Const-me 8y ago
    There’re indeed multiple third-party libraries for that in many languages. E.g. for C++ we have lubuv, boost.asio, etc. However, built-in solutions have upsides. They work out of the box i.e. deployment is simpler. They’re integrated into the language, e.g. most network IO in golang is asynchronous under the hood, compiler and runtime do that automatically. They’re integrated into standard libraries, e.g. in .NET all streams be it files, sockets, or transforms like compressors and encryptors support asynchronous operations. The support is usually better, too.
    - apta 8y ago
      The JVM is getting coroutines with Project Loom. The same Quasar devs are integrating it into the JVM.
  - apta 8y ago
    Quasar is going to be integrated into the JVM by means of project Loom.