4 ms·

I think it's because async. means nothing if you don't specify how, where and when something is async. For starters you can't use languages that don't share mem

by bullen 10y ago

I think it's because async. means nothing if you don't specify how, where and when something is async. For starters you can't use languages that don't share memory between threads if you wish to see any improvements by adding async. threading to your non-blocking network code. So Python, Go, Ruby, Javascript, Erlang are all out of the argument when talking about async. Only C (C++, etc.) and Java (C#, etc.) families of languages that share memory between threads can scale better with async. on multicore processors when it comes to network related performance. Edit: Please comment if you downvote. Edit: Now I can't comment, the site tells me I'm writing too fast.

kjksf 10y ago
FYI: Go, Python and Ruby do share memory between threads. JavaScript doesn't have threads so the point is moot. Only Erlang doesn't share memory between processes.
- bullen 10y ago
  Ok, didn't know that, can you point to some pages that explain how you can reference the same memory from two threads in the same process with these languages?
  - kornish 10y ago
    Here's a snippet of Go code, with comments, which spins up different goroutines (lightweight thread primitives) to read and write values in a shared map: https://gobyexample.com/mutexes https://gobyexample.com/mutexes
    - bullen 10y ago
      Can goroutines run on separate cores? Because I'm pretty sure go explicitly decided to not share memory between threads because google thinks async. is too hard to understand for programmers...
      - geoka9 10y ago
        You probably mean channels - yes they let you avoid dealing with synchronization of shared memory access explicitly, but they still use mutexes underneath, so you can use those directly if you want (instead of/along with channels).
      - fzzzy 10y ago
        Yes, goroutines run on separate cores. Go uses an M:N threading model. goroutines (M) which are ready to run are scheduled on a thread pool of POSIX threads (N) which I believe is sized to match the number of cores in the processor. Nothing stops those goroutines from racing on shared memory. However, there is a convention that before accessing some shared memory, goroutines synchronize themselves using channels. ("Do not communicate by sharing memory; instead, share memory by communicating.")
- kevin_thibedeau 10y ago
  > Only Erlang doesn't share memory between processes. Nim doesn't share memory either.
  - KirinDave 10y ago
    Are you sure? I thought nim could use shared memory semantics if you wanted to? My understanding was it (cleverly) makes a subset of the language for concurrent work that requires you to be explicit about that activity.
petre 10y ago
You can do async/event based programming using coroutines instead of threads, thus achieving non blocking behaviour. Nginx does that for instance.
- bullen 10y ago
  Sure, but then you are not having all cores contributing to the same solution. Each nginx request is then distinct from every other request. And really then it's easier to scale with separate machines like google does in it's completely synchronous environment.
  - petre 10y ago
    So you start a number of workers and distribute the load among them. At least that's one way to solve the problem in Perl/Python/Ruby. You can contribute to the same solution by passing data to a master process, or using shared memory. In Erlang and Scala you can solve it even more ellegantly using actors and chanels. Go has goroutines and channels. All of these can span multiple cores.
KirinDave 10y ago
Important point: Promises, ContT monadic constructions[1], Threads, and Actors all are just variations on how to structure sequential computation with asynchronous events. You can prove this to yourself via construction: you can write an interpreter that simulates threads (and even pre-emption) with Promises, Actors, or a more formal monadic style. You can repeat this feat for any single member of the set and if you do it carefully that's a proof by construction. Related reading, somewhat famous: https://pdfs.semanticscholar.org/2948/a0d014852ba47dd115fcc70202c840d71cac.pdf https://pdfs.semanticscholar.org/2948/a0d014852ba47dd115fcc7... Essentially what you choose to implement is arbitrary and should be informed by your underlying performance requirements coupled with your preferences. And, as people have noted: your post seems confused. Everyone benefits somewhat uniformly from asynchronous operations. Java's implementations are often a little bit more tunable because the programmer can provide the threadpool for async workers. Of all of the languages you named, Erlang is the most distinct as it offers an abstraction (and cost) of 1 heap per actor from the perspective of the garbage collector. This decision (made in a time when GC algorithms were quite a bit worse than they evolved to be) lead Erlang to something they want to keep: an abstraction that makes remote and local computation identical. Other languages that follow in Erlang's footsteps (Pony comes to mind, yay Pony!) do not do things this way. [1]: Okay EitherT ContT. Sure. Get picky. P.S., You cannot comment because your overall karma is too low, putting you in a rate-limited category. It generally clears up in a few hours. However, I do not think there is much more of value to say other than to thank that one poster for a few pretty cool papers!
- bullen 10y ago
  I have written my own async. webserver and on top of that my own distributed database: https://github.com/tinspin/rupy https://github.com/tinspin/rupy Here you can read about how async. works in my system: https://github.com/tinspin/rupy/wiki/Fuse https://github.com/tinspin/rupy/wiki/Fuse I might not be stroking the HN community in the right direction but trust me, I'm not confused.
  - KirinDave 10y ago
    Would you prefer I use the phrase "completely incorrect about the memory models of the majority of languages you named and the erroneous conclusions you reached from them?" That is certainly more accurate, but seemed needlessly confrontational in my first draft, so I opted for the more generic phrase "confused post", which implied maybe the post itself was simply jumbled up and didn't clearly offer your intent to the audience. You did ask after all. I was trying to give a non-confrontational way to explain why I almost downvoted your post for being very misleading, and opted instead to respond with a slightly more correct post. HN needs less fighting and more knowledge. I thought what you were trying to say was, "parallelism is not the same as concurrency" but that it got jumbled up. That is a correct statement.
deleted 10y ago
[deleted]

by bullen 10y ago

kjksf 10y ago

FYI: Go, Python and Ruby do share memory between threads. JavaScript doesn't have threads so the point is moot. Only Erlang doesn't share memory between processes.

bullen 10y ago
Ok, didn't know that, can you point to some pages that explain how you can reference the same memory from two threads in the same process with these languages?
- kornish 10y ago
  Here's a snippet of Go code, with comments, which spins up different goroutines (lightweight thread primitives) to read and write values in a shared map: https://gobyexample.com/mutexes https://gobyexample.com/mutexes
  - bullen 10y ago
    Can goroutines run on separate cores? Because I'm pretty sure go explicitly decided to not share memory between threads because google thinks async. is too hard to understand for programmers...
    - geoka9 10y ago
      You probably mean channels - yes they let you avoid dealing with synchronization of shared memory access explicitly, but they still use mutexes underneath, so you can use those directly if you want (instead of/along with channels).
    - fzzzy 10y ago
      Yes, goroutines run on separate cores. Go uses an M:N threading model. goroutines (M) which are ready to run are scheduled on a thread pool of POSIX threads (N) which I believe is sized to match the number of cores in the processor. Nothing stops those goroutines from racing on shared memory. However, there is a convention that before accessing some shared memory, goroutines synchronize themselves using channels. ("Do not communicate by sharing memory; instead, share memory by communicating.")
kevin_thibedeau 10y ago
> Only Erlang doesn't share memory between processes. Nim doesn't share memory either.
- KirinDave 10y ago
  Are you sure? I thought nim could use shared memory semantics if you wanted to? My understanding was it (cleverly) makes a subset of the language for concurrent work that requires you to be explicit about that activity.

petre 10y ago

You can do async/event based programming using coroutines instead of threads, thus achieving non blocking behaviour. Nginx does that for instance.

bullen 10y ago
Sure, but then you are not having all cores contributing to the same solution. Each nginx request is then distinct from every other request. And really then it's easier to scale with separate machines like google does in it's completely synchronous environment.
- petre 10y ago
  So you start a number of workers and distribute the load among them. At least that's one way to solve the problem in Perl/Python/Ruby. You can contribute to the same solution by passing data to a master process, or using shared memory. In Erlang and Scala you can solve it even more ellegantly using actors and chanels. Go has goroutines and channels. All of these can span multiple cores.

KirinDave 10y ago

Important point: Promises, ContT monadic constructions[1], Threads, and Actors all are just variations on how to structure sequential computation with asynchronous events. You can prove this to yourself via construction: you can write an interpreter that simulates threads (and even pre-emption) with Promises, Actors, or a more formal monadic style. You can repeat this feat for any single member of the set and if you do it carefully that's a proof by construction. Related reading, somewhat famous: https://pdfs.semanticscholar.org/2948/a0d014852ba47dd115fcc70202c840d71cac.pdf https://pdfs.semanticscholar.org/2948/a0d014852ba47dd115fcc7... Essentially what you choose to implement is arbitrary and should be informed by your underlying performance requirements coupled with your preferences. And, as people have noted: your post seems confused. Everyone benefits somewhat uniformly from asynchronous operations. Java's implementations are often a little bit more tunable because the programmer can provide the threadpool for async workers. Of all of the languages you named, Erlang is the most distinct as it offers an abstraction (and cost) of 1 heap per actor from the perspective of the garbage collector. This decision (made in a time when GC algorithms were quite a bit worse than they evolved to be) lead Erlang to something they want to keep: an abstraction that makes remote and local computation identical. Other languages that follow in Erlang's footsteps (Pony comes to mind, yay Pony!) do not do things this way. [1]: Okay EitherT ContT. Sure. Get picky. P.S., You cannot comment because your overall karma is too low, putting you in a rate-limited category. It generally clears up in a few hours. However, I do not think there is much more of value to say other than to thank that one poster for a few pretty cool papers!

bullen 10y ago
I have written my own async. webserver and on top of that my own distributed database: https://github.com/tinspin/rupy https://github.com/tinspin/rupy Here you can read about how async. works in my system: https://github.com/tinspin/rupy/wiki/Fuse https://github.com/tinspin/rupy/wiki/Fuse I might not be stroking the HN community in the right direction but trust me, I'm not confused.
- KirinDave 10y ago
  Would you prefer I use the phrase "completely incorrect about the memory models of the majority of languages you named and the erroneous conclusions you reached from them?" That is certainly more accurate, but seemed needlessly confrontational in my first draft, so I opted for the more generic phrase "confused post", which implied maybe the post itself was simply jumbled up and didn't clearly offer your intent to the audience. You did ask after all. I was trying to give a non-confrontational way to explain why I almost downvoted your post for being very misleading, and opted instead to respond with a slightly more correct post. HN needs less fighting and more knowledge. I thought what you were trying to say was, "parallelism is not the same as concurrency" but that it got jumbled up. That is a correct statement.

deleted 10y ago

[deleted]