5 ms·
We should be really skeptical of (or perhaps we could charitably say, "We should contextualize these,") speed claims. Akka does well in benchmarks too, until yo
by KirinDave 10y ago
We should be really skeptical of (or perhaps we could charitably say, "We should contextualize these,") speed claims. Akka does well in benchmarks too, until you put significant memory pressure on the VM and find it handles less gracefully under load than a more JVM-natural approach using approaches in java.util.concurrent.
Actor-based approaches with hundreds of thousands of actors are really amazing, powerful and often simpler than equivalent channel based systems, conceptually. But they require special GC considerations to be made "efficient" of a really high level of mechanical sympathy to make sure you aren't creating pathologically bad situations for the garbage collector.
- macintux 10y agoMy favorite conference talk is about the multiple facets of Erlang that combine to make it such a great language. Take an opinionated language, an opinionated VM, and a focus on a specific problem space, and magic happens. Take one or two features from Erlang into another language, and you have meh.
- KirinDave 10y agoI think the Actor paradigm is valuable as a modeling tool and is widely dismissed these days by arguments I don't think are actually very valid. But what doesn't work is trying to slavishly copy the Erlang/Pony style without those considerations.
- vvanders 10y agoConsidering the production system that the Erlang VM has been deployed to(and the length of time it's existed and thrived) it's hard to make an argument to re-invent it in another language. If that's what your domain space needs, use the BEAM and find a way to talk to it for the parts that you can't move to Erlang.
- dgfgfdagasdfgfa 10y agoIt's not hard to justify; that's laughable. It's simple redundancy!
- techdragon 10y agoSometimes the concurrency benefits just don't add up when compared to other business/project concerns. I say this as an big fan of Erlang, truth is, sometimes you just have to accept that your job is to write a python/Django backend without a line of JavaScript in order to serve as a line of business app, and if the load gets bigger, you just throw another server at it. That said, erlang is great, elixir is awesome, and both are 100% worth every developers time to learn.
- dgfgfdagasdfgfa 10y agoI'm not sure where concurrency plays into this at all.
- KirinDave 10y agoWelllllllll... Can I be honest? As a language, Erlang kinda is a cube of frozen barf. It's not messy, but it's certainly not delicious. I do not "love it." I think most people sort of work around this; OTP is so good you put up with a kinda ugly syntactic substrate. Ideas good, array syntax bad, etc.
- mamcx 10y agoChannels will be a better fit inside .NET? >powerful and often simpler than equivalent channel based systems, conceptually Without true experience with any of agents/channels, what make it simpler? I read the GO and compare with Actors in F# or Erlang and for me it easier to understand channels. Mainly because are typed on the data.
- di4na 10y agoThe thing is, Types are really hard to make work in a distributed unbounded non deterministic system like... well any system that is multi threaded. You can try to hide stuff with channels, but most of the time, you will feel the abstraction leaking.
- mamcx 10y agoI maybe can see if we are talking about distributed across machines, runtimes with different versions or languages, but not with multi threaded. Any example?
- di4na 10y agoWhat is the difference between multithread and different machines? Time to get a synchronous response ? At best. But errors happens to and error situations are the same.
- mavam 10y ago(Disclaimer: CAF co-maintainer here.) It's great to see more actor runtimes on the rise. Also interesting to see the actor model implemented in Go, which follows more of a pi calculus design with its channels. With an actor design, the software architecture shifts towards the endpoints of the communication. CAF targets the performance-sensitive C++ community, so sending a message in the same process only costs a single hardware-support CAS operation. We found this scales very well. No GC other than reference counting. For those interested in learning more about actors in the C++ ecosystem, I recently gave a talk about CAF and some performance comparisons to other frameworks in various scenarios: http://matthias.vallentin.net/slides/caf-rise.pdf http://matthias.vallentin.net/slides/caf-rise.pdf
- alexeiz 10y agoI've been using the CAF library for a while, and the experience so far has been very positive. It's surprisingly capable and flexible at the same time. The use of modern C++ in CAF makes your code very clean and idiomatic. Other C++ libraries of this kind are usually quite painful to use (because you know, most people think if it's C++ it has to be hard). CAF is a pleasant exception to this rule.