19 ms·

Ask HN: What equivalents of Erlang/OTP exist for other languages?

81 points by proveanegative 11y ago

anonyfox 11y ago
Elixir/OTP. :)
Gonzih 11y ago
pulsar for clojure
flippant 11y ago
JVM: Quasar http://www.paralleluniverse.co/quasar/ http://www.paralleluniverse.co/quasar/ Scala/Java: Akka http://akka.io http://akka.io Haskell: Cloud Haskell http://haskell-distributed.github.io/ http://haskell-distributed.github.io/
- virtualwhys 11y ago
  FWIW, one of the above is widely used in production systems. and none of the above have solved preserving types across machine boundaries (or at least not in a stable/non-experimental let's-bet-the-bank-on-this release). Quasar looks pretty insane at first blush; if Java 9 or 10 delivers on the missing piece [1] for this library, watch out. [1] "Quasar fibers are implemented by creating and scheduling continuation tasks and since the JVM doesn’t (yet) support native continuations, Quasar implements them through selective bytecode instrumentation: methods that can block a fiber currently need to be explicitly marked through annotations so that Quasar can insert the continuation suspension and resumption hooks."
  - hyperpape 11y ago
    I'm not familiar with Erlang: what does preserving types across machine boundaries mean in this context?
    - vezzy-fnord 11y ago
      Probably referring to the external term format used in multi-node distributed message passing: http://erlang.org/doc/apps/erts/erl_ext_dist.html http://erlang.org/doc/apps/erts/erl_ext_dist.html
    - crocal 11y ago
      When you build highly distributed systems, making sure a value is properly transferred across different types of machine is actually not a trivial task because sender and receiver may encode values differently at the bit level (for example, because different endianess system is used). Erlang VM take care of this naturally, and the language offers built in functions to encode / decode binary representations that can be sent over basic transmission channels (like TCP / IP sockets). If Erlang is not your cup of tea, look at htons() and nstoh() functions to have another example. My trade is in real time distributed systems applied to the automatic control of trains. You wouldn't believe the number of times I have had to fix this issue in multiple codes, both new or legacy. And my example is limited to individual values, not data structures. Think about how ugly things can turn if you have things like lists or dictionaries. When you consider that Erlang adds on top of this built-in marshalling and demarshalling of data structure. As of today, I haven't found a more efficent environment to do this kind of stuff safely.
      - MichaelGG 11y ago
        How's that different than using a well defined binary serialization format (protobufs?) and having a controller daemon that makes sure everyone reports the same version or has the same serialization contracts loaded before adding them to discovery? Or is it just that Erlang has this all batteries included, the way Python's popular with scientific programming?
        crocal 11y ago
        You are spot on. You can do what Erlang does in many ways. It's the combination of all this, built into a coherent architecture, that makes OTP unique.
        pron 11y ago
        You call it coherent, I call it a small ecosystem with limited choices, limited development resources behind it, and disappointing performance.
  - pron 11y ago
    Main author of Quasar here. Quasar's bytecode instrumentation is really very gentle -- no class fields/methods are added/removed and object state isn't changed in any way. It is far, far less intrusive than, say, JRebel. While Java 9 sadly won't include native JVM fibers or continuations, it will probably make the instrumentation process 100% transparent.
    - BenoitP 11y ago
      Java 9 will introduce the G1 GC as default. How do the emulation of continuations behave regarding this GC? Is is possible to obtain truly pauseless behavior with Quaser and G1?
  - tekacs 11y ago
    Akka preserves types across machine boundaries, at least inasmuch as the External Term Format does, AFAIK. Would you say that it's missing something?
    - virtualwhys 11y ago
      Akka production release is all about `Any`, as in it's untyped, and you have to pattern match on the receiver to the expected type. That's a far cry from Akka Typed [1], the recently released experimental branch, which allows you to match on the "real" type; as a result distributed code is compile time checked...a dream scenario ;-) [1] http://doc.akka.io/docs/akka/snapshot/scala/typed.html http://doc.akka.io/docs/akka/snapshot/scala/typed.html
      - tekacs 11y ago
        Yup, I've been using Akka Typed myself recently. Having said that it doesn't change the fact that Akka preserves types in most arbitrary hierarchies today, across machine boundaries.
  - codygman 11y ago
    > and none of the above have solved preserving types across machine boundaries (or at least not in a stable/non-experimental let's-bet-the-bank-on-this release). What about Static Pointers[0]? Do you feel the solve the problem or are likely to if you characterize them as non-stable and/or experimental? 0: https://ocharles.org.uk/blog/guest-posts/2014-12-23-static-pointers.html https://ocharles.org.uk/blog/guest-posts/2014-12-23-static-p...
ispaceman 11y ago
VS C++: Generic Parallel Computing (GPC) API http://parallect.codeplex.com http://parallect.codeplex.com
- MCRed 11y ago
  You could implement a half written, buggy version of erlang in C++... but GPC isn't even close to erlang/OTP. What I'm learning here is that people don't understand what erlang/OTP is.
markonthewall 11y ago
I suggest you take a look at Elixir, it's an incredibly well designed and powerful languages. FWIW, I am pretty sure that it will take off exponentially in the coming years... the support for concurrency is amazing, and it also allows for simpler software to be developed easily. Definitely worth taking a look at it.
- jflatow 11y ago
  For those unaware, Elixir is a language that runs on the Erlang VM, so its amazing concurrency is the same as Erlang's.
  - akhilcacharya 11y ago
    Yup, syntax wise it's like if Ruby was mixed with Erlang.
    - rue 11y ago
      I was deeply disappointed with the syntax… there are so many compromises because of underlying semantics that the ‘rubyish’ layer on top is very clunky. It does cut down on a lot of Erlang boilerplate, so it’s still a better option… but I’m hoping someone will give it a third try.
      - jtwebman 11y ago
        They are making it better everyday though.
      - e_proxus 11y ago
        Totally agree. What they have improved on is a nice macro system, and a coherent (so far) standard library. Both, which Erlang lacks. The syntax itself is slightly disappointing though. Optional parentheses around argument calls doesn't really add much except confusion, and the extra cruft around blocks and functions make things like pattern matching quite a bit clunkier.
    - 11y ago
Gepsens 11y ago
Go https://golang.org/ https://golang.org/
- MCRed 11y ago
  Unfortunately, I think you're serious. And you're probably one of many who think this way. Which shows that people really don't understand what it means to do concurrency (as go doesn't support it really.) Look the erlang syntax is not that hard.
  - amelius 11y ago
    Could you explain what Go is missing, then?
    - kungfooguru 11y ago
      These posts cover some of that: http://blog.erlware.org/some-thoughts-on-go-and-erlang/ http://blog.erlware.org/some-thoughts-on-go-and-erlang/ http://vagabond.github.io/rants/2015/06/05/a-year-with-go/ http://vagabond.github.io/rants/2015/06/05/a-year-with-go/
    - nevergo 11y ago
      Could you tell us what not?
  - Rapzid 11y ago
    Unfortunately, I think you're serious. And you're probably one of many who think this way. Which shows that people really don't understand what it means to do concurrency (as go does support it, really.)
nevergo 11y ago
Scala with Akka. http://www.scala-lang.org/ http://www.scala-lang.org/ http://akka.io/ http://akka.io/
jeffdavis 11y ago
My claim is that Erlang/OTP is a cluster OS, not a language. It supports two languages: Erlang and Elixir.
- chops 11y ago
  The idea that Erlang/OTP is an OS is something promoted by Garrett Smith in this talk (https://www.youtube.com/watch?v=0ZGHzI9F5YE https://www.youtube.com/watch?v=0ZGHzI9F5YE), and the idea that it is intentionally OS-like has been promoted by the Robert Virding and Joe Armstrong (https://twitter.com/rvirding/status/386612140242915328 https://twitter.com/rvirding/status/386612140242915328) And two different lisps: * Lisp Flavored Erlang (http://lfe.io/ http://lfe.io/) * Joxa (http://joxa.org/ http://joxa.org/)
- zeckalpha 11y ago
  It's also kinda like a Smalltalk image, too, given that a program can be seen like a paused virtual machine image.
- zarkone 11y ago
  Erlang on Xen: https://github.com/cloudozer/ling https://github.com/cloudozer/ling
Rantenki 11y ago
Clojure/JVM: core.async, but moreso pulsar: https://github.com/puniverse/pulsar https://github.com/puniverse/pulsar
- MCRed 11y ago
  Not even close. And that your claim seems to be widely believed shows me that people don't understand what erlang/OTP are and what makes them unique (so far.)
  - kasey_junk 11y ago
    Maybe you could enumerate some of the things that are unique or impossible to replicate instead of just saying "nope that's not it"
  - nevergo 11y ago
    Then why is it so unique?
pixelmonkey 11y ago
Apache Storm[1] isn't exactly like Erlang/OTP, but it definitely aims to achieve similar goals. Though Storm is written in Java and Clojure, the infrastructure it provides is usable across languages thanks to something it calls the "multi-lang protocol". I work on a Storm library for Python that's called streamparse[2], and the goal of the project is to allow us to easily achieve Erlang OTP-style reliable processing atop open source infrastructure while still writing pure Python code. I also gave a PyCon talk about streamparse which you can find on YouTube[3]. It describes the motivation for the project -- which is to solve a large-scale real-time analytics problem with Python and do so in a reliable way, while beating Python's multi-core limitations (the GIL, etc.) [1]: https://storm.apache.org/ https://storm.apache.org/ [2]: https://github.com/Parsely/streamparse https://github.com/Parsely/streamparse [3]: https://www.youtube.com/watch?v=ja4Qj9-l6WQ https://www.youtube.com/watch?v=ja4Qj9-l6WQ
- virtualwhys 11y ago
  > to easily achieve Erlang OTP-style reliable processing that reliability wasn't the case for at least one of the internet heavyweights, quite the opposite [1] [1] http://blog.acolyer.org/2015/06/15/twitter-heron-stream-processing-at-scale/ http://blog.acolyer.org/2015/06/15/twitter-heron-stream-proc...
  - pixelmonkey 11y ago
    I have a more cynical view of the Heron announcement. But let's remember that Twitter ran Storm in production for over 4 years at massive scale, and whatever improvements Heron represents, they thought the abstraction was important enough to reimplement the entire Storm API in the new system.
- fernandotakai 11y ago
  not sure if this exists right now, but i would love to see a good tutorial/article on storm showing how to use it to solve real life problems instead of "hey here's a way to split words and count them".
  - 11y ago
davidw 11y ago
Erlang was designed from the ground up to do what it does, so it's... not easy to replicate that in other systems.
- tormeh 11y ago
  This. The VM and everything about Erlang in general is designed for this particular task. Just sit down and learn you some Erlang - it's a bit weird and alien, but it's not so hard and you either do it or regret not doing it. You could, I suppose, hack something together using multiple JVMs per machine (avoid global GC) and Akka and implement some custom live diagnostics, but if you're really doing a telecommunications project there's no real shortcut. Plain Akka will cut it in many cases but it's not a thoroughbred like Erlang. Give up, Erlang just can't be beaten at its home turf by a framework.
  - MichaelGG 11y ago
    What shortcut are you talking about? I spread SIP/RTP handling systems over many machines, load balanced with a SIP proxy. I would love to know how Erlang is going to make it magically scale even better. Highest record was only a billion calls in a day or two, so maybe I'm not at enough scale to be hurt by non-Erlang. (Stack was all C, plus F# for routing and billing.)
- pron 11y ago
  ... unless those other systems are more general. Erlang itself is written in C. The JVM (or, rather, any JVM) is more low-level and therefore more general than an Erlang VM, and includes much of the work already, so replicating Erlang on the JVM is much easier than replicating it in C. There is nothing Erlang VMs provide that the JVM doesn't, except for some guarantees that are simply different on the JVM, and I think most applications would prefer the JVM's advantages anyway.
  - MCRed 11y ago
    OTP is written in erlang. The JVM is not "more low-level" and not "more general". In fact it is impossible to do on the JVM in any JVM language what the erlang VM gives you. You literally cannot replicate erlang on the JVM. You can fake it, but you will not have the guarantees and reliability that the erlang VM gives you. To get erlang/OTP you would have to replicate it from the beginning in C, and there's no point in that, when you can just use erlang.
giancarlostoro 11y ago
I'm not an expert in comparing these but there's also: Orbit for the JVM / Scala by EA (BioWare actually) https://github.com/electronicarts/orbit https://github.com/electronicarts/orbit Then there's Orleans by Microsoft for .NET: https://github.com/dotnet/orleans https://github.com/dotnet/orleans They feature a concept called Virtual Actors as opposed to other frameworks like Akka for the JVM.
- MCRed 11y ago
  Erlang/OTP are not just "actors", and Actors on the JVM aren't actually actors. They're poser actors.
  - nevergo 11y ago
    "They're poser actors." - slightly fanatic...
jcrites 11y ago
I have not worked in Erlang and and am not super familiar with OTP, so my answer might be only quasi on-topic. Java concurrency primitives like ExecutorService and BlockingQueue with support from libraries like Google Guava (ListenableFuture & ListeningExecutorService and, more loosely related, EventBus), as well as libraries like Netty form an excellent basis for concurrent software development in Java. I've developed a number of event processing type applications in Java (including our email delivery system) using message passing styles and future/promise styles and feel like Java does a good job accommodating them, helping them perform well, and allowing them to be easy to operate and troubleshoot. You can make this work all the way down to asynchronous IO at the operating system level if you wish, although in practice we get acceptable performance allowing that lowest level to use blocking IO for simplicity. It's really easy to set up a "pipeline" of message processors in a Java application that produce and consume from BlockingQueues; or alternatively, submit work to an ExecutorService or publish an event to an EventBus. Maybe not as easy as other languages or frameworks, since there is some scaffolding, but it feels pretty minimal to me. (Again I say this as someone who has not worked in Erlang or other concurrent languages / frameworks extensively.) Unlike some other concurrent code, pipeline-type code is pretty easy to write, understand, and debug. The hardest part is usually orchestrating safe controlled shutdown. One area where I understand that Java probably does not compete with Erlang is in the reliability of individual processes and threads and whatnot within a machine. There is no simple way in Java, for example, to continue processing requests in the application while you shutdown and restart with a new version. However, we typically accommodate problems like this at the next level up by routing traffic away from a machine in preparation for it to receive a software updated. Java's exception handling is also robust. There is not much need to worry about "termination" of individual processes. A top level try/catch block in your message processing system goes a really long way to making the app itself immune to any kind of lower level failure. It might be difficult to convey the supreme confidence of error handling in Java if you've only worked with other languages, but a subjective feeling is: "There is absolutely nothing that can go wrong in any Java code that I might execute that will not unwind in a controlled way through my try/catch blocks and give me a nice, clear stack trace and error message." Whatever thread was handling that work can move onto the next message nicely and cleanly. And beyond this, "There is absolutely no way that any Java code I execute can interact with any part of the application except the objects being passed to it." People credit garbage collection in Java with making applications and libraries much easier to compose. I personally believe that Java's error handling and behavior containment is also a big part of it. A library that I call simply cannot crash me or interact with anything except what it's passed. (OK, there are some exceptions to these rules, such as code that calls into native code, or running out of heap space, or weird dynamic/reflective stuff, but (i) you can avoid most of them in practice (ii) they don't come up much anyway (iii) exceptions to the rules don't tend to be a problem.) Application crashes like OOM are also problems that we solve in other layers: if they happen, it means the software is not correct or not tuned correctly, and the crash of an application at this level is handled by the routing layer on top. We don't consider application crashes as something that we need to worry about on an ongoing basis; it's more of a QA issue during development. We do not tend to have systems though where "this particular machine must be available at all times". None of this specifically supports distributed application development along with concurrency, beyond making message passing easy within the app. That's where client libraries like Netty or frameworks like Akka go much further.
deleted 11y ago
[deleted]
jpgvm 11y ago
Celluloid for Ruby implements the actor concurrency model. It's not exactly the same, but running on JRuby it's a reasonable platform for writing concurrent applications in a highly productive language and style.
- MCRed 11y ago
  Or you can use Elixir and get the real thing with a ruby like syntax (plus a lot more.)
  - jpgvm 11y ago
    Definitely, Elixir is very nice. However it is very useful to have access to actor style concurrency outside of the BEAM ecosystem. One of the really nice things about Celluloid is you can start up the actor system inside an existing non-threaded and non-actor aware system and write concurrent code.
  - decentrality 11y ago
    Can you expound on this?
    - jpgvm 11y ago
      Elixir is a Ruby like language that runs on the BEAM VM, the bytecode virtual machine that Erlang runs on. Elixir is thus able to execute Erlang code directly including OTP. This means you can use OTP as you would in Erlang but without the somewhat arcane syntax. Thus it can be said, you can use the "real" thing.
babo 11y ago
There are similar attempts but OTP is a unique and very powerful approach, the deep integration between the language, core libraries and the framework is hard to match. Why not stick with it? Elixir is fresh and nice, but even Erlang is easy to grab.
- MCRed 11y ago
  I think it's more binary. Either the platform takes care of it for you, the way Erlang and OTP do, and thus you do your code and it just works... or the platform hides it from you and you think you're doing ok until you get bitten in the ass in production-- and then you have a Very Bad Day, and possibly years of Fail Whales. So, Erlang/OTP are correct. The rest, so far, are not correct.
MCRed 11y ago
The real question is: Why don't you just use Erlang or Elixir? Can you find the magic sauce in another language? I believe the honest answer is no. You can't do it in Java because the JVM doesn't support it. You can't really build this on top of something that was not designed with parallelism and concurrency in mind, and designed correctly. For that reason Go doesn't do it either. Scripting languages aren't even thinking about it and to do it in something like C or C++ you'd basically be recreating a poorly implemented half working version of erlang. So more interesting is--- why do people have this aversion to Erlang and Elixir? It doesn't take but a couple weeks to get used to erlang programming, and Elixir is even faster I think. For the record I've been taking interns thru Programming Elixir in about 2 weeks and getting them to where they can program in the language (just at that point now with a new group so we'll see how much they struggle... but I've already seen code written by them.) Erlang did it right and has put in several decades of effort getting it even more right. Other languages, like Go, aren't even trying (though of course advertising "concurrency" is very popular, none of them really do it.) All these people choosing things like node.js or go for problems where erlang is the correct solution make me think that too many of the people in our industry aren't really engineers, but more scripters following the herd. And engineer knows why erlang is the correct solution for distributed systems.
- pron 11y ago
  > Why don't you just use Erlang or Elixir? Because you may want good performance without dropping down to C. Many serious Erlang applications are mixed Erlang/C applications, where they delegate processing to C, or use Erlang for the control plain and C for the data plain. Or because you want more sophisticated, fast transactional shared-state than ETS allows. Or because you want to take advantage of a much wider selection of high-quality libraries. Note that these aren't problems with Erlang or Elixir as languages -- they're both great -- but rather with the runtime they're running on, whose developers simply don't have the resources to make it all that it can be. Which brings me to: > the JVM doesn't support it. The JVM most certainly does support it. It was designed with parallelism and concurrency in mind, and includes some of the best high-quality, production-ready implementations of concurrent data structures and schedulers in existence. The effort that's been poured into the JVM -- and even JVM concurrency alone -- dwarfs the effort put into Erlang at least by an order of magnitude. I think Erlang would benefit greatly if it were to target the JVM. There is a project, Erjang, that runs BEAM code on the JVM, but it is not very actively maintained and doesn't take advantage of some of the recent, relevant innovations in the Java world. Since that project was developed, there have been major improvements in the pertinent areas on the JVM: concurrent GCs, JITting of dynamically-typed languages, fibers and work-stealing scheduling. OpenJDK is the second-largest open-source project in the world (after the Linux kernel), and I don't see why Erlang shouldn't take advantage of the vast resources it has at its disposal. OpenJDK and Erlang are a great fit!
RogerAlsing 11y ago
Akka for .NET, http://getakka.net/ http://getakka.net/
beagle3 11y ago
Not OTP, but the Erlang message passing model has been available for Python since 2002 or so, in a package called Candygram[0]. [0] https://launchpad.net/candygram https://launchpad.net/candygram - main page is on SourceForge which is down at the moment, and should be avoided even when it is up.
egonelbre 11y ago
Something like Erlang/OTP not really... Although here are some bits/pieces I've seen in Go community: * Project Iris http://iris.karalabe.com/ http://iris.karalabe.com/ * Go Circuit https://github.com/gocircuit/circuit https://github.com/gocircuit/circuit * NSQ http://nsq.io/ http://nsq.io/ * Consul https://www.consul.io/ https://www.consul.io/ * SkyNet https://github.com/skynetservices/skynet https://github.com/skynetservices/skynet * Grace https://github.com/facebookgo/grace https://github.com/facebookgo/grace Each having their pros/cons with varying quality. Replicating Erlang processes -> usually you use goroutines. When that level fails you fail the whole process and restart it using some supervisor. You may need computer level failover as well, depending on the requirements. For the servers/protocols part of OTP, the stdlib is usually sufficient to get things running; although may need some additions for rarer encodings. For machine level deployment there are cluster managers i.e. kubernetes, aws, google cloud etc. Regarding debugging/monitoring I haven't seen anything that is close to Erlang. Basically, I have no idea what you are doing and cannot recommend anything particular. For the full feature set there is no single replacement. If you need OTP then use OTP.
rubyn00bie 11y ago
Ah. Yes... This is mostly how I began my long awkward journey from the JVM, Ruby, Node, et. al to Elixir. Let me give you the one tip that'll make this way easier: Use the right tool for the job. Not the one you like best. Just because you can use the blunt end of a drill to hit a nail, doesn't mean you should give up hammers... You might even break your drill! If your problem's solution requires extremely concurrent, high availability, low latency, throughput then you must use BeamVM. The JVM will be too slow and largely memory inefficient compared to Beam. If concurrency isn't needed, or isnt applicable (parallel, or synchronous, problems), then it's not the answer nor is OTP. E.g. I wouldn't dream of writing and image processor in Elixir-- Beam isn't the right tool to solve that problem. Also, checkout dialzyer if you think you need type safety. It'll catch plenty of stupid mistakes... I had that urge (for types) coming from the JVM, or a non-functional non-dynamic language, but it's actually a straw man. I'd highly encourage you to get past classes, and state, so you can really enjoy the platform for what it offers-- it's pretty eye opening.
- arthurcolle 11y ago
  I hear frequently that BEAM languages shouldn't be used for numerical computing or any CPU-bound tasks. Why not, though? If I take a high resolution image and spawn N*M BEAM processes which each deal with performing processing on some subcomponent of the image, and then use some scheduling algorithm to reassemble the image after the processing is done, wouldn't you have substantial speedups compared to using some other image processing library in a language like Python? In the same vein, things like matrix multiplications or other numerical algorithms that are known to parallelize well seem to lend themselves really well to BEAM processes, although the libraries aren't written yet since you can trivially call Python from BEAM anyways.
  - dmytrish 11y ago
    NxM BEAM processes will give you a real boost only if you have NxM physical cores to run code in parallel. Yes, Erlang makes clusters painless, but it's still more reasonable to use a single machine with a faster VM/native code.
decentrality 11y ago
Celluloid: http://celluloid.io http://celluloid.io
- Yadi 11y ago
  Do you know why this comment is awesome? I've used celluloid for so long with Ruby. But recently I've been trying to understand OTP/Erl and I'v had no luck. Now seeing these two as an alternative makes a lot of sense for diff langs.
  - decentrality 11y ago
    Yeah, we get people saying we're not 'true Erlang' but that was kind of the whole idea. It's an alternative to Erlang and Akka, pulling the best from both. And it's so active and involved that it's almost becoming more of an RVM than a library only. With `jRuby` and more and more with `Rubinius`, the concept of actor-based concurrency itself is coming into range of being language-unspecific, with Erlang not being the default authority on that. Akka gets a lot of respect, and of course Elixr, Go, Rust, etc get a lot of concurrency attention... But Celluloid with Ruby is far superior in my opinion, because it is not only performant and functional, it actually allows you to get into the internals and change how your actor system behaves. It's as simple or as complex as you want it to be. Oh and you don't feel like killing yourself while you're writing code.
    - Yadi 11y ago
      Indeed, thanks! One quick question: Aside of the docs, any suggestions for learning on further Celluloid & Ruby /actor based patterns?
      - decentrality 11y ago
        We're doing much better documentation as we approach 1.0 ... possibly writing and publishing a book as well. For now.. Google Groups: https://groups.google.com/forum/#!forum/celluloid-ruby https://groups.google.com/forum/#!forum/celluloid-ruby IRC: #celluloid on Freenode Or drop me a message with your question. @digitalextremist on github
mapcars 11y ago
Preemption. Erlang VM counts each instruction per process and uses it's own scheduler to switch processes, all other implementations of lightweight processes can't do this without implementing their own erlang.
- MichaelGG 11y ago
  So every OS is it's own Erlang?
  - mapcars 11y ago
    Yes, but "modern" OS'es have heavy processes, in other words they save registers, stack pointers, other process related things and restore them on every process switch. I'm not sure what makes real difference to Erlang's processes here, I hope someone can explain this with more details.
jtwebman 11y ago
Why not just use Elixir or Erlang? I never understood why programmers would spend years re-writing something in their language of choice if it already existed.
nmcfarl 11y ago
Hugh
rvirding 11y ago
I know I missed this but I do want to make some (general) comments: - Erlang, the language and system, was designed for highly concurrent and fault tolerant systems. In many ways these were more important than raw throughput in that if it could not handle the massive concurrency and build truly fault-tolerant systems then it wasn't interesting. At all. - Same with pre-emptive scheduling, the system had to be non-blocking. Again if it wasn't then it wasn't interesting. Yes, you can provide primitives to allow the programmers to do it but this does make things difficult and not-reliable. - The language design was focussed on these types of systems and and implementing the types of architectures which OTP supports. - From Erlang's point of view using OS threads as a base for Erlang processes is not an option. They are way too heavy and you can't have enough of them to be interesting. 10k processes are child's play, 100k processes is starting to get interesting and 1M process production systems exist, for example WhatsApp. - For Erlang processes are the basic building blocks in a similar way to objects in an OO language. What would a Java programmer say if they were told that they couldn't have more than 1000 objects? - Having the erlang VM handle using all the cores, or as many as you want, by default is just the natural way to do things. If I had to do any form of restructuring of my system because I was running on 4, 8, 16 or 32 cores I would consider that to be intolerable and so primitive I would wonder what the implementors were thinking of. - While the Erlang syntax is different (which functional language doesn't have a different syntax?) it is actually very concise and consistent, this by design. The elixir syntax is "Ruby influenced" and more complex and feature filled. Which you prefer is up to you. - I am very fond of lisp so there is at least one native implementation of lisp on the Erlang VM, LFE (Lisp Flavoured Erlang), http://lfe.io/ http://lfe.io/ and https://github.com/rvirding/lfe https://github.com/rvirding/lfe. - There is nothing which you can do in one which you can't do in the others, after all they run on the same VM and you can easily combine them and use them together. That's about all for the moment, Robert

anonyfox 11y ago

Elixir/OTP. :)

Gonzih 11y ago

pulsar for clojure

flippant 11y ago

JVM: Quasar http://www.paralleluniverse.co/quasar/ http://www.paralleluniverse.co/quasar/ Scala/Java: Akka http://akka.io http://akka.io Haskell: Cloud Haskell http://haskell-distributed.github.io/ http://haskell-distributed.github.io/

virtualwhys 11y ago
FWIW, one of the above is widely used in production systems. and none of the above have solved preserving types across machine boundaries (or at least not in a stable/non-experimental let's-bet-the-bank-on-this release). Quasar looks pretty insane at first blush; if Java 9 or 10 delivers on the missing piece [1] for this library, watch out. [1] "Quasar fibers are implemented by creating and scheduling continuation tasks and since the JVM doesn’t (yet) support native continuations, Quasar implements them through selective bytecode instrumentation: methods that can block a fiber currently need to be explicitly marked through annotations so that Quasar can insert the continuation suspension and resumption hooks."
- hyperpape 11y ago
  I'm not familiar with Erlang: what does preserving types across machine boundaries mean in this context?
  - vezzy-fnord 11y ago
    Probably referring to the external term format used in multi-node distributed message passing: http://erlang.org/doc/apps/erts/erl_ext_dist.html http://erlang.org/doc/apps/erts/erl_ext_dist.html
  - crocal 11y ago
    When you build highly distributed systems, making sure a value is properly transferred across different types of machine is actually not a trivial task because sender and receiver may encode values differently at the bit level (for example, because different endianess system is used). Erlang VM take care of this naturally, and the language offers built in functions to encode / decode binary representations that can be sent over basic transmission channels (like TCP / IP sockets). If Erlang is not your cup of tea, look at htons() and nstoh() functions to have another example. My trade is in real time distributed systems applied to the automatic control of trains. You wouldn't believe the number of times I have had to fix this issue in multiple codes, both new or legacy. And my example is limited to individual values, not data structures. Think about how ugly things can turn if you have things like lists or dictionaries. When you consider that Erlang adds on top of this built-in marshalling and demarshalling of data structure. As of today, I haven't found a more efficent environment to do this kind of stuff safely.
    - MichaelGG 11y ago
      How's that different than using a well defined binary serialization format (protobufs?) and having a controller daemon that makes sure everyone reports the same version or has the same serialization contracts loaded before adding them to discovery? Or is it just that Erlang has this all batteries included, the way Python's popular with scientific programming?
      - crocal 11y ago
        You are spot on. You can do what Erlang does in many ways. It's the combination of all this, built into a coherent architecture, that makes OTP unique.
        pron 11y ago
        You call it coherent, I call it a small ecosystem with limited choices, limited development resources behind it, and disappointing performance.
- pron 11y ago
  Main author of Quasar here. Quasar's bytecode instrumentation is really very gentle -- no class fields/methods are added/removed and object state isn't changed in any way. It is far, far less intrusive than, say, JRebel. While Java 9 sadly won't include native JVM fibers or continuations, it will probably make the instrumentation process 100% transparent.
  - BenoitP 11y ago
    Java 9 will introduce the G1 GC as default. How do the emulation of continuations behave regarding this GC? Is is possible to obtain truly pauseless behavior with Quaser and G1?
- tekacs 11y ago
  Akka preserves types across machine boundaries, at least inasmuch as the External Term Format does, AFAIK. Would you say that it's missing something?
  - virtualwhys 11y ago
    Akka production release is all about `Any`, as in it's untyped, and you have to pattern match on the receiver to the expected type. That's a far cry from Akka Typed [1], the recently released experimental branch, which allows you to match on the "real" type; as a result distributed code is compile time checked...a dream scenario ;-) [1] http://doc.akka.io/docs/akka/snapshot/scala/typed.html http://doc.akka.io/docs/akka/snapshot/scala/typed.html
    - tekacs 11y ago
      Yup, I've been using Akka Typed myself recently. Having said that it doesn't change the fact that Akka preserves types in most arbitrary hierarchies today, across machine boundaries.
- codygman 11y ago
  > and none of the above have solved preserving types across machine boundaries (or at least not in a stable/non-experimental let's-bet-the-bank-on-this release). What about Static Pointers[0]? Do you feel the solve the problem or are likely to if you characterize them as non-stable and/or experimental? 0: https://ocharles.org.uk/blog/guest-posts/2014-12-23-static-pointers.html https://ocharles.org.uk/blog/guest-posts/2014-12-23-static-p...

ispaceman 11y ago

VS C++: Generic Parallel Computing (GPC) API http://parallect.codeplex.com http://parallect.codeplex.com

MCRed 11y ago
You could implement a half written, buggy version of erlang in C++... but GPC isn't even close to erlang/OTP. What I'm learning here is that people don't understand what erlang/OTP is.

markonthewall 11y ago

I suggest you take a look at Elixir, it's an incredibly well designed and powerful languages. FWIW, I am pretty sure that it will take off exponentially in the coming years... the support for concurrency is amazing, and it also allows for simpler software to be developed easily. Definitely worth taking a look at it.

jflatow 11y ago
For those unaware, Elixir is a language that runs on the Erlang VM, so its amazing concurrency is the same as Erlang's.
- akhilcacharya 11y ago
  Yup, syntax wise it's like if Ruby was mixed with Erlang.
  - rue 11y ago
    I was deeply disappointed with the syntax… there are so many compromises because of underlying semantics that the ‘rubyish’ layer on top is very clunky. It does cut down on a lot of Erlang boilerplate, so it’s still a better option… but I’m hoping someone will give it a third try.
    - jtwebman 11y ago
      They are making it better everyday though.
    - e_proxus 11y ago
      Totally agree. What they have improved on is a nice macro system, and a coherent (so far) standard library. Both, which Erlang lacks. The syntax itself is slightly disappointing though. Optional parentheses around argument calls doesn't really add much except confusion, and the extra cruft around blocks and functions make things like pattern matching quite a bit clunkier.
  - 11y ago

Gepsens 11y ago

Go https://golang.org/ https://golang.org/

MCRed 11y ago
Unfortunately, I think you're serious. And you're probably one of many who think this way. Which shows that people really don't understand what it means to do concurrency (as go doesn't support it really.) Look the erlang syntax is not that hard.
- amelius 11y ago
  Could you explain what Go is missing, then?
  - kungfooguru 11y ago
    These posts cover some of that: http://blog.erlware.org/some-thoughts-on-go-and-erlang/ http://blog.erlware.org/some-thoughts-on-go-and-erlang/ http://vagabond.github.io/rants/2015/06/05/a-year-with-go/ http://vagabond.github.io/rants/2015/06/05/a-year-with-go/
  - nevergo 11y ago
    Could you tell us what not?
- Rapzid 11y ago
  Unfortunately, I think you're serious. And you're probably one of many who think this way. Which shows that people really don't understand what it means to do concurrency (as go does support it, really.)

nevergo 11y ago

Scala with Akka. http://www.scala-lang.org/ http://www.scala-lang.org/ http://akka.io/ http://akka.io/

jeffdavis 11y ago

My claim is that Erlang/OTP is a cluster OS, not a language. It supports two languages: Erlang and Elixir.

chops 11y ago
The idea that Erlang/OTP is an OS is something promoted by Garrett Smith in this talk (https://www.youtube.com/watch?v=0ZGHzI9F5YE https://www.youtube.com/watch?v=0ZGHzI9F5YE), and the idea that it is intentionally OS-like has been promoted by the Robert Virding and Joe Armstrong (https://twitter.com/rvirding/status/386612140242915328 https://twitter.com/rvirding/status/386612140242915328) And two different lisps: * Lisp Flavored Erlang (http://lfe.io/ http://lfe.io/) * Joxa (http://joxa.org/ http://joxa.org/)
zeckalpha 11y ago
It's also kinda like a Smalltalk image, too, given that a program can be seen like a paused virtual machine image.
zarkone 11y ago
Erlang on Xen: https://github.com/cloudozer/ling https://github.com/cloudozer/ling

Rantenki 11y ago

Clojure/JVM: core.async, but moreso pulsar: https://github.com/puniverse/pulsar https://github.com/puniverse/pulsar

MCRed 11y ago
Not even close. And that your claim seems to be widely believed shows me that people don't understand what erlang/OTP are and what makes them unique (so far.)
- kasey_junk 11y ago
  Maybe you could enumerate some of the things that are unique or impossible to replicate instead of just saying "nope that's not it"
- nevergo 11y ago
  Then why is it so unique?

pixelmonkey 11y ago

Apache Storm[1] isn't exactly like Erlang/OTP, but it definitely aims to achieve similar goals. Though Storm is written in Java and Clojure, the infrastructure it provides is usable across languages thanks to something it calls the "multi-lang protocol". I work on a Storm library for Python that's called streamparse[2], and the goal of the project is to allow us to easily achieve Erlang OTP-style reliable processing atop open source infrastructure while still writing pure Python code. I also gave a PyCon talk about streamparse which you can find on YouTube[3]. It describes the motivation for the project -- which is to solve a large-scale real-time analytics problem with Python and do so in a reliable way, while beating Python's multi-core limitations (the GIL, etc.) [1]: https://storm.apache.org/ https://storm.apache.org/ [2]: https://github.com/Parsely/streamparse https://github.com/Parsely/streamparse [3]: https://www.youtube.com/watch?v=ja4Qj9-l6WQ https://www.youtube.com/watch?v=ja4Qj9-l6WQ

virtualwhys 11y ago
> to easily achieve Erlang OTP-style reliable processing that reliability wasn't the case for at least one of the internet heavyweights, quite the opposite [1] [1] http://blog.acolyer.org/2015/06/15/twitter-heron-stream-processing-at-scale/ http://blog.acolyer.org/2015/06/15/twitter-heron-stream-proc...
- pixelmonkey 11y ago
  I have a more cynical view of the Heron announcement. But let's remember that Twitter ran Storm in production for over 4 years at massive scale, and whatever improvements Heron represents, they thought the abstraction was important enough to reimplement the entire Storm API in the new system.
fernandotakai 11y ago
not sure if this exists right now, but i would love to see a good tutorial/article on storm showing how to use it to solve real life problems instead of "hey here's a way to split words and count them".
- 11y ago

davidw 11y ago

Erlang was designed from the ground up to do what it does, so it's... not easy to replicate that in other systems.

tormeh 11y ago
This. The VM and everything about Erlang in general is designed for this particular task. Just sit down and learn you some Erlang - it's a bit weird and alien, but it's not so hard and you either do it or regret not doing it. You could, I suppose, hack something together using multiple JVMs per machine (avoid global GC) and Akka and implement some custom live diagnostics, but if you're really doing a telecommunications project there's no real shortcut. Plain Akka will cut it in many cases but it's not a thoroughbred like Erlang. Give up, Erlang just can't be beaten at its home turf by a framework.
- MichaelGG 11y ago
  What shortcut are you talking about? I spread SIP/RTP handling systems over many machines, load balanced with a SIP proxy. I would love to know how Erlang is going to make it magically scale even better. Highest record was only a billion calls in a day or two, so maybe I'm not at enough scale to be hurt by non-Erlang. (Stack was all C, plus F# for routing and billing.)
pron 11y ago
... unless those other systems are more general. Erlang itself is written in C. The JVM (or, rather, any JVM) is more low-level and therefore more general than an Erlang VM, and includes much of the work already, so replicating Erlang on the JVM is much easier than replicating it in C. There is nothing Erlang VMs provide that the JVM doesn't, except for some guarantees that are simply different on the JVM, and I think most applications would prefer the JVM's advantages anyway.
- MCRed 11y ago
  OTP is written in erlang. The JVM is not "more low-level" and not "more general". In fact it is impossible to do on the JVM in any JVM language what the erlang VM gives you. You literally cannot replicate erlang on the JVM. You can fake it, but you will not have the guarantees and reliability that the erlang VM gives you. To get erlang/OTP you would have to replicate it from the beginning in C, and there's no point in that, when you can just use erlang.

giancarlostoro 11y ago

I'm not an expert in comparing these but there's also: Orbit for the JVM / Scala by EA (BioWare actually) https://github.com/electronicarts/orbit https://github.com/electronicarts/orbit Then there's Orleans by Microsoft for .NET: https://github.com/dotnet/orleans https://github.com/dotnet/orleans They feature a concept called Virtual Actors as opposed to other frameworks like Akka for the JVM.

MCRed 11y ago
Erlang/OTP are not just "actors", and Actors on the JVM aren't actually actors. They're poser actors.
- nevergo 11y ago
  "They're poser actors." - slightly fanatic...

jcrites 11y ago

I have not worked in Erlang and and am not super familiar with OTP, so my answer might be only quasi on-topic. Java concurrency primitives like ExecutorService and BlockingQueue with support from libraries like Google Guava (ListenableFuture & ListeningExecutorService and, more loosely related, EventBus), as well as libraries like Netty form an excellent basis for concurrent software development in Java. I've developed a number of event processing type applications in Java (including our email delivery system) using message passing styles and future/promise styles and feel like Java does a good job accommodating them, helping them perform well, and allowing them to be easy to operate and troubleshoot. You can make this work all the way down to asynchronous IO at the operating system level if you wish, although in practice we get acceptable performance allowing that lowest level to use blocking IO for simplicity. It's really easy to set up a "pipeline" of message processors in a Java application that produce and consume from BlockingQueues; or alternatively, submit work to an ExecutorService or publish an event to an EventBus. Maybe not as easy as other languages or frameworks, since there is some scaffolding, but it feels pretty minimal to me. (Again I say this as someone who has not worked in Erlang or other concurrent languages / frameworks extensively.) Unlike some other concurrent code, pipeline-type code is pretty easy to write, understand, and debug. The hardest part is usually orchestrating safe controlled shutdown. One area where I understand that Java probably does not compete with Erlang is in the reliability of individual processes and threads and whatnot within a machine. There is no simple way in Java, for example, to continue processing requests in the application while you shutdown and restart with a new version. However, we typically accommodate problems like this at the next level up by routing traffic away from a machine in preparation for it to receive a software updated. Java's exception handling is also robust. There is not much need to worry about "termination" of individual processes. A top level try/catch block in your message processing system goes a really long way to making the app itself immune to any kind of lower level failure. It might be difficult to convey the supreme confidence of error handling in Java if you've only worked with other languages, but a subjective feeling is: "There is absolutely nothing that can go wrong in any Java code that I might execute that will not unwind in a controlled way through my try/catch blocks and give me a nice, clear stack trace and error message." Whatever thread was handling that work can move onto the next message nicely and cleanly. And beyond this, "There is absolutely no way that any Java code I execute can interact with any part of the application except the objects being passed to it." People credit garbage collection in Java with making applications and libraries much easier to compose. I personally believe that Java's error handling and behavior containment is also a big part of it. A library that I call simply cannot crash me or interact with anything except what it's passed. (OK, there are some exceptions to these rules, such as code that calls into native code, or running out of heap space, or weird dynamic/reflective stuff, but (i) you can avoid most of them in practice (ii) they don't come up much anyway (iii) exceptions to the rules don't tend to be a problem.) Application crashes like OOM are also problems that we solve in other layers: if they happen, it means the software is not correct or not tuned correctly, and the crash of an application at this level is handled by the routing layer on top. We don't consider application crashes as something that we need to worry about on an ongoing basis; it's more of a QA issue during development. We do not tend to have systems though where "this particular machine must be available at all times". None of this specifically supports distributed application development along with concurrency, beyond making message passing easy within the app. That's where client libraries like Netty or frameworks like Akka go much further.

deleted 11y ago

[deleted]

jpgvm 11y ago

Celluloid for Ruby implements the actor concurrency model. It's not exactly the same, but running on JRuby it's a reasonable platform for writing concurrent applications in a highly productive language and style.

MCRed 11y ago
Or you can use Elixir and get the real thing with a ruby like syntax (plus a lot more.)
- jpgvm 11y ago
  Definitely, Elixir is very nice. However it is very useful to have access to actor style concurrency outside of the BEAM ecosystem. One of the really nice things about Celluloid is you can start up the actor system inside an existing non-threaded and non-actor aware system and write concurrent code.
- decentrality 11y ago
  Can you expound on this?
  - jpgvm 11y ago
    Elixir is a Ruby like language that runs on the BEAM VM, the bytecode virtual machine that Erlang runs on. Elixir is thus able to execute Erlang code directly including OTP. This means you can use OTP as you would in Erlang but without the somewhat arcane syntax. Thus it can be said, you can use the "real" thing.

babo 11y ago

There are similar attempts but OTP is a unique and very powerful approach, the deep integration between the language, core libraries and the framework is hard to match. Why not stick with it? Elixir is fresh and nice, but even Erlang is easy to grab.

MCRed 11y ago
I think it's more binary. Either the platform takes care of it for you, the way Erlang and OTP do, and thus you do your code and it just works... or the platform hides it from you and you think you're doing ok until you get bitten in the ass in production-- and then you have a Very Bad Day, and possibly years of Fail Whales. So, Erlang/OTP are correct. The rest, so far, are not correct.

MCRed 11y ago

The real question is: Why don't you just use Erlang or Elixir? Can you find the magic sauce in another language? I believe the honest answer is no. You can't do it in Java because the JVM doesn't support it. You can't really build this on top of something that was not designed with parallelism and concurrency in mind, and designed correctly. For that reason Go doesn't do it either. Scripting languages aren't even thinking about it and to do it in something like C or C++ you'd basically be recreating a poorly implemented half working version of erlang. So more interesting is--- why do people have this aversion to Erlang and Elixir? It doesn't take but a couple weeks to get used to erlang programming, and Elixir is even faster I think. For the record I've been taking interns thru Programming Elixir in about 2 weeks and getting them to where they can program in the language (just at that point now with a new group so we'll see how much they struggle... but I've already seen code written by them.) Erlang did it right and has put in several decades of effort getting it even more right. Other languages, like Go, aren't even trying (though of course advertising "concurrency" is very popular, none of them really do it.) All these people choosing things like node.js or go for problems where erlang is the correct solution make me think that too many of the people in our industry aren't really engineers, but more scripters following the herd. And engineer knows why erlang is the correct solution for distributed systems.

pron 11y ago
> Why don't you just use Erlang or Elixir? Because you may want good performance without dropping down to C. Many serious Erlang applications are mixed Erlang/C applications, where they delegate processing to C, or use Erlang for the control plain and C for the data plain. Or because you want more sophisticated, fast transactional shared-state than ETS allows. Or because you want to take advantage of a much wider selection of high-quality libraries. Note that these aren't problems with Erlang or Elixir as languages -- they're both great -- but rather with the runtime they're running on, whose developers simply don't have the resources to make it all that it can be. Which brings me to: > the JVM doesn't support it. The JVM most certainly does support it. It was designed with parallelism and concurrency in mind, and includes some of the best high-quality, production-ready implementations of concurrent data structures and schedulers in existence. The effort that's been poured into the JVM -- and even JVM concurrency alone -- dwarfs the effort put into Erlang at least by an order of magnitude. I think Erlang would benefit greatly if it were to target the JVM. There is a project, Erjang, that runs BEAM code on the JVM, but it is not very actively maintained and doesn't take advantage of some of the recent, relevant innovations in the Java world. Since that project was developed, there have been major improvements in the pertinent areas on the JVM: concurrent GCs, JITting of dynamically-typed languages, fibers and work-stealing scheduling. OpenJDK is the second-largest open-source project in the world (after the Linux kernel), and I don't see why Erlang shouldn't take advantage of the vast resources it has at its disposal. OpenJDK and Erlang are a great fit!

RogerAlsing 11y ago

Akka for .NET, http://getakka.net/ http://getakka.net/

beagle3 11y ago

Not OTP, but the Erlang message passing model has been available for Python since 2002 or so, in a package called Candygram[0]. [0] https://launchpad.net/candygram https://launchpad.net/candygram - main page is on SourceForge which is down at the moment, and should be avoided even when it is up.

egonelbre 11y ago

Something like Erlang/OTP not really... Although here are some bits/pieces I've seen in Go community: * Project Iris http://iris.karalabe.com/ http://iris.karalabe.com/ * Go Circuit https://github.com/gocircuit/circuit https://github.com/gocircuit/circuit * NSQ http://nsq.io/ http://nsq.io/ * Consul https://www.consul.io/ https://www.consul.io/ * SkyNet https://github.com/skynetservices/skynet https://github.com/skynetservices/skynet * Grace https://github.com/facebookgo/grace https://github.com/facebookgo/grace Each having their pros/cons with varying quality. Replicating Erlang processes -> usually you use goroutines. When that level fails you fail the whole process and restart it using some supervisor. You may need computer level failover as well, depending on the requirements. For the servers/protocols part of OTP, the stdlib is usually sufficient to get things running; although may need some additions for rarer encodings. For machine level deployment there are cluster managers i.e. kubernetes, aws, google cloud etc. Regarding debugging/monitoring I haven't seen anything that is close to Erlang. Basically, I have no idea what you are doing and cannot recommend anything particular. For the full feature set there is no single replacement. If you need OTP then use OTP.

rubyn00bie 11y ago

Ah. Yes... This is mostly how I began my long awkward journey from the JVM, Ruby, Node, et. al to Elixir. Let me give you the one tip that'll make this way easier: Use the right tool for the job. Not the one you like best. Just because you can use the blunt end of a drill to hit a nail, doesn't mean you should give up hammers... You might even break your drill! If your problem's solution requires extremely concurrent, high availability, low latency, throughput then you must use BeamVM. The JVM will be too slow and largely memory inefficient compared to Beam. If concurrency isn't needed, or isnt applicable (parallel, or synchronous, problems), then it's not the answer nor is OTP. E.g. I wouldn't dream of writing and image processor in Elixir-- Beam isn't the right tool to solve that problem. Also, checkout dialzyer if you think you need type safety. It'll catch plenty of stupid mistakes... I had that urge (for types) coming from the JVM, or a non-functional non-dynamic language, but it's actually a straw man. I'd highly encourage you to get past classes, and state, so you can really enjoy the platform for what it offers-- it's pretty eye opening.

arthurcolle 11y ago
I hear frequently that BEAM languages shouldn't be used for numerical computing or any CPU-bound tasks. Why not, though? If I take a high resolution image and spawn N*M BEAM processes which each deal with performing processing on some subcomponent of the image, and then use some scheduling algorithm to reassemble the image after the processing is done, wouldn't you have substantial speedups compared to using some other image processing library in a language like Python? In the same vein, things like matrix multiplications or other numerical algorithms that are known to parallelize well seem to lend themselves really well to BEAM processes, although the libraries aren't written yet since you can trivially call Python from BEAM anyways.
- dmytrish 11y ago
  NxM BEAM processes will give you a real boost only if you have NxM physical cores to run code in parallel. Yes, Erlang makes clusters painless, but it's still more reasonable to use a single machine with a faster VM/native code.

decentrality 11y ago

Celluloid: http://celluloid.io http://celluloid.io

Yadi 11y ago
Do you know why this comment is awesome? I've used celluloid for so long with Ruby. But recently I've been trying to understand OTP/Erl and I'v had no luck. Now seeing these two as an alternative makes a lot of sense for diff langs.
- decentrality 11y ago
  Yeah, we get people saying we're not 'true Erlang' but that was kind of the whole idea. It's an alternative to Erlang and Akka, pulling the best from both. And it's so active and involved that it's almost becoming more of an RVM than a library only. With `jRuby` and more and more with `Rubinius`, the concept of actor-based concurrency itself is coming into range of being language-unspecific, with Erlang not being the default authority on that. Akka gets a lot of respect, and of course Elixr, Go, Rust, etc get a lot of concurrency attention... But Celluloid with Ruby is far superior in my opinion, because it is not only performant and functional, it actually allows you to get into the internals and change how your actor system behaves. It's as simple or as complex as you want it to be. Oh and you don't feel like killing yourself while you're writing code.
  - Yadi 11y ago
    Indeed, thanks! One quick question: Aside of the docs, any suggestions for learning on further Celluloid & Ruby /actor based patterns?
    - decentrality 11y ago
      We're doing much better documentation as we approach 1.0 ... possibly writing and publishing a book as well. For now.. Google Groups: https://groups.google.com/forum/#!forum/celluloid-ruby https://groups.google.com/forum/#!forum/celluloid-ruby IRC: #celluloid on Freenode Or drop me a message with your question. @digitalextremist on github

mapcars 11y ago

Preemption. Erlang VM counts each instruction per process and uses it's own scheduler to switch processes, all other implementations of lightweight processes can't do this without implementing their own erlang.

MichaelGG 11y ago
So every OS is it's own Erlang?
- mapcars 11y ago
  Yes, but "modern" OS'es have heavy processes, in other words they save registers, stack pointers, other process related things and restore them on every process switch. I'm not sure what makes real difference to Erlang's processes here, I hope someone can explain this with more details.

jtwebman 11y ago

Why not just use Elixir or Erlang? I never understood why programmers would spend years re-writing something in their language of choice if it already existed.

nmcfarl 11y ago

Hugh

rvirding 11y ago

I know I missed this but I do want to make some (general) comments: - Erlang, the language and system, was designed for highly concurrent and fault tolerant systems. In many ways these were more important than raw throughput in that if it could not handle the massive concurrency and build truly fault-tolerant systems then it wasn't interesting. At all. - Same with pre-emptive scheduling, the system had to be non-blocking. Again if it wasn't then it wasn't interesting. Yes, you can provide primitives to allow the programmers to do it but this does make things difficult and not-reliable. - The language design was focussed on these types of systems and and implementing the types of architectures which OTP supports. - From Erlang's point of view using OS threads as a base for Erlang processes is not an option. They are way too heavy and you can't have enough of them to be interesting. 10k processes are child's play, 100k processes is starting to get interesting and 1M process production systems exist, for example WhatsApp. - For Erlang processes are the basic building blocks in a similar way to objects in an OO language. What would a Java programmer say if they were told that they couldn't have more than 1000 objects? - Having the erlang VM handle using all the cores, or as many as you want, by default is just the natural way to do things. If I had to do any form of restructuring of my system because I was running on 4, 8, 16 or 32 cores I would consider that to be intolerable and so primitive I would wonder what the implementors were thinking of. - While the Erlang syntax is different (which functional language doesn't have a different syntax?) it is actually very concise and consistent, this by design. The elixir syntax is "Ruby influenced" and more complex and feature filled. Which you prefer is up to you. - I am very fond of lisp so there is at least one native implementation of lisp on the Erlang VM, LFE (Lisp Flavoured Erlang), http://lfe.io/ http://lfe.io/ and https://github.com/rvirding/lfe https://github.com/rvirding/lfe. - There is nothing which you can do in one which you can't do in the others, after all they run on the same VM and you can easily combine them and use them together. That's about all for the moment, Robert