On Fri, Mar 14, 2014 at 1:35 PM, Raoul Duke <rao...@gmail.com> wrote:
> i am probably out of my depth here, i do not have extensive real-world > experience with the various ways to approach parallelism and > concurrency (to be distinguished of course), more run of the mill > stuff. so if i sound like i'm missing your point or am clueless i ask > for your patience :-) > > > What's the sequential fraction of an arbitrary erlang program, can you > even > > know (I don't know erlang, so I'm honestly asking)? > > who cares? or rather, each person has to only care about their own > program & situation. maybe their stuff fits erlang. maybe it fits > better with something else e.g. LMAX. it. all. depends. :-) > > everything depends on context. Martin's talk even included the part > where he bemoaned that people don't just stay single-threaded and fix > their crappy code first. running to concurrency and parallelism is > often a cop-out the way i hear him. that could be seen as arguing > 'against' erlang. > > so there are places where your program is mostly sequential and things > like "does the GC act like a GIL" do not matter as much as the > situation where you are trying to be more concurrent + parallel but > not distributed. in those sequential situations, maybe erlang becomes > a square peg for the round hole. (although i personally, through > suffering as a maintenance programmer, am a *huge* lover of the > recursive single assignment "turn" based approach to things, and i > love clojure's idea of having a consistent view of the world; most OO > people shoot me in the foot a year after they've left the company, > with their crappy macaroni code.) > > > Shared memory pretty darn convenient, and we don't have hundred-core+ > boxes > > yet. > > i'm confused in that i thought you wrote shared memory ~= message > passing. so why talk about shared memory when that is a lie? just like > Martin said, RAM is a lie. why not realize everything is really > message passing in the long run, model it as such, understand the > issues as such? i do not have a chip on my shoulder about this, i'm > just sounding it out / exploring the thought. > > Well, yes it's a lie, it's an abstraction, we love those as programmers :-). The question is, is it worth the trouble and under what conditions? IMO, we don't understand message passing well enough to be great at programming or characterizing distributed concurrent systems. I wonder how this changes when you're writing erlang. I would guess that certain classes of programs are really easy to write in erlang compared to other languages, and I wonder at what cost? Clojure appealed to me because I was studying computer architecture in grad school, and I think it has a great answer for cores<100 shared-memory concurrency, but at some point I acknowledge that might not be good enough. I'm very interested in Netkernel's approach, actually: http://www.1060research.com/products/ It sort of marries the notion of immutable data with distribution and message passing. URLs as pointers. > sincerely. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
