5 ms·

I think Akka is sort of heading in the right direction in its ubiquitous language. Akka talks about itself in terms of solving the "distribution problem" - not

I think Akka is sort of heading in the right direction in its ubiquitous language. Akka talks about itself in terms of solving the "distribution problem" - not necessarily across machines but machines OR cores. It talks about "location transparency" as a first principle meaning that an actor/worker that processes a message can be either on another CPU or another physical machine and the location of that actor is transparent from the perspective of the code - it's a deployment/configuration concern. It's convenient that multicore utilization is a scale problem at the same that utilizing networked compute resources (ie in the cloud) is scale problem resources because we might be able to treat them as similar problems. Yes the network introduces some other unique qualities (https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...) but apart from reliability assertions it's an interesting observation that they can be treated similarly if message passing mechanics are abstracted. eg they both fit asynchronous, event driven paradigms. both need elimination of shared state to not make errors in your code (required over the network). Multicore concurrency in code isn't too hard but threads/locking are probably the wrong abstraction. Similarly, functional approaches might be a better "default" approach for a concurrent world.

tracker1 11y ago
Functional approaches are definitely better regarding concurrency, and distribution... if you can ship the state and the operation/function where there is availability, it can run anywhere. More complex OO relationships aren't as portable. Of course MQ systems have their own cost, on-system or across systems. That said, the fastest computers over the past 5 years or so aren't much faster, but the power usage is much less... For example, the i5-6200u is an absolute beast of a machine for its' power consumption. This is great for server-side computing, where virtualization and other isolation strategies for allowing shared resources work well. I don't know that we really need too much more in terms of "faster" ... the problems to be solved at this point are absolutely in systems solutions that are distributed and those communication channels. Google can deliver results of a query amazingly fast... We're going to reach a point where communication networks reach nearly every inch of livable space, and all information is (virtually) within arms length. (divergent rambling ahead) There are bigger issues at hand... that being physical transportation... we (in the U.S. and many other places) have more pavement for cars that we do housing space. There are optimizations to be had in the physical world that are far more pressing than if computing can get another 4-5 cycles out of moore's law. The costs of food, medication are growing kind of insane the past few years. We're pushing for younger education to the point that little kids are washing out and doing worse, instead of being little kids. On the flip side, they're so isolated that they can't handle genuine pressure/stress later in life. It's a messed up world.
paulddraper 11y ago
Akka is sold as a concurrency abstraction that works great ay any level: one core, multicore, multi-host. After using it for years, I can say it does work, but only with a high complexity overhead. Failure conditions, retry logic, serialization and delivery guarantrees are a concern of multi-host parallelism, but not really multicore (same process) parallelism. I'm not sure I've ever seen an abstraction over memory-separated concurrency that doesn't add a lot of complexity. It may be that such a difference is fundamental and isn't meant to be abstracted over. In any case, unless you are sure that you want to design for distributed parallelism, I recommend conventional thread pools, etc. Also, https://www.chrisstucchio.com/blog/2013/actors_vs_futures.html https://www.chrisstucchio.com/blog/2013/actors_vs_futures.ht...
yo-code-sucks 11y ago
Akka is Cacca.
hansihe 11y ago
Erlang/OTP is based on the idea of location transparency to the core, I would recommend you have a look at it. If the Erlang syntax is too weird, Elixir allows you to use ruby-like syntax on the Erlang VM. It also comes with an absolutely amazingly powerful lisp-like macro system.

tracker1 11y ago

Functional approaches are definitely better regarding concurrency, and distribution... if you can ship the state and the operation/function where there is availability, it can run anywhere. More complex OO relationships aren't as portable. Of course MQ systems have their own cost, on-system or across systems. That said, the fastest computers over the past 5 years or so aren't much faster, but the power usage is much less... For example, the i5-6200u is an absolute beast of a machine for its' power consumption. This is great for server-side computing, where virtualization and other isolation strategies for allowing shared resources work well. I don't know that we really need too much more in terms of "faster" ... the problems to be solved at this point are absolutely in systems solutions that are distributed and those communication channels. Google can deliver results of a query amazingly fast... We're going to reach a point where communication networks reach nearly every inch of livable space, and all information is (virtually) within arms length. (divergent rambling ahead) There are bigger issues at hand... that being physical transportation... we (in the U.S. and many other places) have more pavement for cars that we do housing space. There are optimizations to be had in the physical world that are far more pressing than if computing can get another 4-5 cycles out of moore's law. The costs of food, medication are growing kind of insane the past few years. We're pushing for younger education to the point that little kids are washing out and doing worse, instead of being little kids. On the flip side, they're so isolated that they can't handle genuine pressure/stress later in life. It's a messed up world.

paulddraper 11y ago

Akka is sold as a concurrency abstraction that works great ay any level: one core, multicore, multi-host. After using it for years, I can say it does work, but only with a high complexity overhead. Failure conditions, retry logic, serialization and delivery guarantrees are a concern of multi-host parallelism, but not really multicore (same process) parallelism. I'm not sure I've ever seen an abstraction over memory-separated concurrency that doesn't add a lot of complexity. It may be that such a difference is fundamental and isn't meant to be abstracted over. In any case, unless you are sure that you want to design for distributed parallelism, I recommend conventional thread pools, etc. Also, https://www.chrisstucchio.com/blog/2013/actors_vs_futures.html https://www.chrisstucchio.com/blog/2013/actors_vs_futures.ht...

yo-code-sucks 11y ago

Akka is Cacca.

hansihe 11y ago

Erlang/OTP is based on the idea of location transparency to the core, I would recommend you have a look at it. If the Erlang syntax is too weird, Elixir allows you to use ruby-like syntax on the Erlang VM. It also comes with an absolutely amazingly powerful lisp-like macro system.