There's a common misconception here that Akka is an actor library. It isn't.
Sure... Akka started (back in the day) as Scala-OTP, and was an attempt to re-imagine Erlang's own OTP library on the Java platform. Nowadays, it's more of a melting pot of higher-level concurrency primitives. Not just actors, but also Futures, agents, dataflow, etc. When Scala gets a native reactive library, you can also be sure that it'll be part of Akka. Due to the Akka/Scala association, it's also commonly misconceived that Actors are *the* concurrency paradigm for Scala, which is also false. You'll note that I took care to list multiple concurrency models in my post :) Akka may well be the poster child for Scala, just as JSPs are the poster child for Java web apps, but that's certainly not the end of the story! After all, a great many people on this list would beg to differ if Java as somehow seen to be defined by JSPs or JSF or any other such isolated model. As for typing... What you don't want is Java's. Granted, you have to look in depth at something esoteric like arrays to see where it's broken, but broken it is (just google "java array covariance" or "ArrayStoreException" for more info. Better still, watch this: http://www.youtube.com/watch?v=wbp-3BJWsU8) A stronger type system with declaration-site variance can fix it, and dynamic typing makes it into the correct behaviour, but there's little that Java can do now. On 21 February 2014 18:36, Josh Berry <tae...@gmail.com> wrote: > > > > On Fri, Feb 21, 2014 at 6:08 AM, Kevin Wright <kev.lee.wri...@gmail.com>wrote: > >> ntel have already released the 15-core Xeon and the 72-core Knight's >> landing processors. Concurrency is only getting more prevalent as time >> passes, and people need to grasp it by the horns now. >> > > While I can't help but agree with the general idea, I can also say that I > want back the responsive systems I recall from the past. I know some of > that is rosy glasses, but not all. > > And this isn't just in the realm of computers, per se. Having suffered > through taking pictures with my phone and waiting for the bloody thing to > respond to my wanting a new picture is painful. And makes using a DSLR > that much more refreshing. > > > Lambdas help, fork/join helps, but these don't go far enough. >> You want easy immutability, you want higher-level concurrency models >> (STM/async/reactive/actors/parallel collections/etc), you want syntax able >> to manipulate and compose functions, If you're dealing with object >> hierarchies on the JVM then you want some way (such as pattern matching) to >> deal with the expression problem. >> > > Programming techniques today jump to concurrency at a potentially massive > expense of memory. Shared nothing architectures are great; when they are > in areas that are well known and often actually have real boundaries > between systems. Shared nothing architectures in your shared everything > system often just leads to slow systems. > > There has been a dream for ages that the compilers can hide mutability > behind immutability. It seems that the gulf between that dream and reality > has only widened. Is there good evidence that it is doing otherwise? > > And actors scare me now more than otherwise. There was an interesting > point made in the Akka section of the last coursera class about how Akka > seeks to make distributed implementations easy, by making all > implementations distributed like. Contrast this with a very salient quote > by Torvalds, (apologies on the look of this, not sure the best way to do > block quotes in this forum) > > The fundamental result of access space separation is that > you can't share data structures. That means that you can't > share locking, it means that you must copy any shared data, > and that in turn means that you have a much harder time > handling coherency. All your algorithms basically end up > being distributed algorithms. > > And anybody who tells you that distributed algorithms > are "simpler" is just so full of sh*t that it's not even > funny. > > Microkernels are much harder to write and maintain > exactly because of this issue. You can do simple > things easily - and in particular, you can do things where > the information only passes in one direction quite easily, > but anythign else is much much harder, because there is > no "shared state" (by design). And in the absense of shared > state, you have a hell of a lot of problems trying to make > any decision that spans more than one entity in the > system. > > > Obviously, this is from a debate on microkernels and such. I have thus > far failed to see how this does not apply to most other items, as well. > > For an interesting perspective on highly sensitive coding semantics in a > codebase, I recommend a current exchange happening in the linux kernel > threads.[1] Going off of threads such as we have here, one would think > that the kernel should use all of these new techniques. That is, to listen > to folks like you, concurrent programming is impossible with locks and > other traditional tools. This seems to show otherwise. > > I am intrigued by the assertion that you either want dynamic typing or > heavy typing. > > > > [1] https://lkml.org/lkml/2014/2/14/709 > > > -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To unsubscribe from this group and stop receiving emails from it, send an email to javaposse+unsubscr...@googlegroups.com. To post to this group, send email to javaposse@googlegroups.com. Visit this group at http://groups.google.com/group/javaposse. For more options, visit https://groups.google.com/groups/opt_out.
