Ask HN: What equivalents of Erlang/OTP exist for other languages? - proveanegative
======
rvirding
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

------
MCRed
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.

~~~
MichaelGG
My aversion comes from relatively poor language syntax - it's more verbose
than it should be. Lack of powerful type system. And less-than-stellar
performance. Out of these, the language is the most annoying.

Can you state which language constructs Erlang has that other languages don't,
that are critical to concurrency? Cause it looks like someone built a great VM
and cluster library, then tossed in a language for fun.

And please explain why Erlang's features are not _possible_ in other
languages. Not just unavailable at the moment. Or do you mean the guarantees
are different? As in other languages will let you have corrupted shared state?
(I view that as a positive; let me escape guarantees when I want too.)

Or perhaps point me to a decent intro that'd cover all this? I looked at it
before and didn't get the real point why we need Erlang the language or why in
theory, you can't have OTP with the CLR or JVM.

~~~
dmytrish
Syntax does not matter much; Erlang's focus is not to be a good general-
purpose language. It is good for distributed computing _because_ it lacks many
useful and pleasant features.

Erlang has built-in immutability done right (more so than in Scala, OCaml,
Clojure(?)) - if it's not built in the language from the start, there's
nothing you can do about it.

Erlang has built-in binary serialization/deserialization that makes messages
across network easy and natural. Please show me a language that can serialize
a closure and send it over network. A rich type system and general-purpose
language features are obstacles here, types of values have to be _dumb_ to
serialize seamlessly.

Other than that, it has a lot of convenient and coherent features like good
pattern-matching (useful for parsing and routing messages), proper tail-call
optimization (just look at Scala, again), the built-in actor model,
lightweight processes, process monitoring, the large library of battle-tested
distributed practices, OTP, – these things _can_ be recreated in another
language/VM, but it will probably take huge resources and efforts and _self-
limitation_ of the platform, not features.

------
flippant
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
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
I'm not familiar with Erlang: what does preserving types across machine
boundaries mean in this context?

~~~
crocal
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
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
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
You call it coherent, I call it a small ecosystem with limited choices,
limited development resources behind it, and disappointing performance.

~~~
andkon
The reason this thread exists is because other options with strong ecosystems
and better performance which accomplish the above mentioned stuff just don't
seem to exist.

I'd actually love to see some performance numbers comparing performance on
Erlang/OTP vs the alternatives, though. I can't find anything quite like that,
maybe someone knows a link.

~~~
pron
Similar solutions exist everywhere, which is partly why the Erlang ecosystem
is so small!

But I agree that Erlang's design is beautiful, which is why I've decided to
port it to the JVM with Quasar. I wanted to bring that great design to a more
powerful runtime and a much bigger ecosystem. Again, the problem isn't with
the Erlang language but with the runtime that, while really nice, simply does
not have nearly enough resources to compete with the bigger runtimes like the
JVM and .NET (or even V8).

We will have some benchmarks eventually, I promise, but those take a long time
and aren't too critical, because, like I said, the Erlang ecosystem is very
small.

------
pixelmonkey
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)

~~~
fernandotakai
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".

~~~
pixelmonkey
It is a fair criticism of the state of Storm documentation and examples. The
book Storm Applied by Manning details tons of Storm usage examples, ranging
from the technically advanced to the mundane. I recommend that book to learn
more about real world usage (disclosure: I wrote the foreword).

Also, my team is working on an open source example project called birding that
uses streamparse and pykafka together to build filtered firehose tweet streams
from Twitter's public API. We think this will illustrate both Storm and Kafka
really well, and be beyond the typical word count examples. See
[https://github.com/Parsely/birding](https://github.com/Parsely/birding) to
track that effort.

------
markonthewall
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
For those unaware, Elixir is a language that runs on the Erlang VM, so its
_amazing_ concurrency is the same as Erlang's.

~~~
akhilcacharya
Yup, syntax wise it's like if Ruby was mixed with Erlang.

~~~
rue
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.

~~~
e_proxus
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.

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

~~~
chops
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/))

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

~~~
pron
... 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
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.

~~~
RogerAlsing
>and there's no point in that, when you can just use erlang

That is a strange comment, ofc the Erlang VM is not the single best VM that
will ever be created. Some day, someone will create a better one.

~~~
CHY872
I think the point was more that Erlang was produced at considerable expense,
so the cost of recreating Erlang for your own project is probably less than
the cost of simply producing your project in Erlang.

~~~
arthurcolle
> I think the point was more that Erlang was produced at considerable expense,
> so the cost of recreating Erlang for your own project is probably _more_
> than the cost of simply producing your project in Erlang.

Fixed! Read your comment, understood it, but I think you probably meant the
opposite

------
decentrality
Celluloid: [http://celluloid.io](http://celluloid.io)

~~~
Yadi
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
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
Indeed, thanks!

One quick question:

Aside of the docs, any suggestions for learning on further Celluloid & Ruby
/actor based patterns?

~~~
decentrality
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

~~~
Yadi
Thanks a bunch!

------
giancarlostoro
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
Erlang/OTP are not just "actors", and Actors on the JVM aren't actually
actors. They're poser actors.

------
egonelbre
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.

------
babo
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
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.

------
anonyfox
Elixir/OTP. :)

------
rubyn00bie
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
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
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.

------
jpgvm
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
Or you can use Elixir and get the real thing with a ruby like syntax (plus a
lot more.)

~~~
decentrality
Can you expound on this?

~~~
jpgvm
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.

------
beagle3
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.

------
mapcars
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
So every OS is it's own Erlang?

~~~
mapcars
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
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.

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

~~~
MCRed
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.

------
RogerAlsing
Akka for .NET, [http://getakka.net/](http://getakka.net/)

------
Rantenki
Clojure/JVM: core.async, but moreso pulsar:
[https://github.com/puniverse/pulsar](https://github.com/puniverse/pulsar)

~~~
MCRed
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
Maybe you could enumerate some of the things that are unique or impossible to
replicate instead of just saying "nope that's not it"

------
Gonzih
pulsar for clojure

------
jcrites
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.

~~~
pron
> 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

It's not trivial, but Java certainly supports hot code swapping. How hard it
is to use it depends on how much you want it to do, like preserve state etc.
For stateless services its not hard to load the new version using a new class
loader to live side-by-side with the old one, and then kill the old one
(automatically) once all its requests have completed, and let the old code be
collected by the GC.

~~~
jcrites
It's something you could arrange if you wanted to, but it could be pretty
complicated! Swapping individual classes within a VM and having multiple
classloaders could be very nuanced to debug. I suspect it would also
complicate usage of concurrency and primitives -- for example, there will be a
separate EventBus for each classloader, rather than one for the application.
The app will need to embrace subtlety like that to be correct. I'd almost be
tempted to consider the two classloader roots to be two separate apps in the
same process, but they'd need to share the same file descriptors for network
communication and logging. Urk.

It's a neat idea though. Do you know of any frameworks that would make the
idea easier to implement? It sounds loosely similar to the Unix availability
concept of passing off the listening socket to a new instance of the process,
while allowing the old processes to linger until they finish serving their
requests.

All other things equal, I favor architectural approaches where I can take any
machine offline safely and effortlessly since I tend to need to handle that
case anyway for availability reasons.

~~~
pron
> for example, there will be a separate EventBus for each classloader

Not if you leave the message classes alone.

> Do you know of any frameworks that would make the idea easier to implement?

No, just careful design (JRebel is for development rather than production, as
I understand, but I could be wrong) Tooting my own horn (again) but Quasar
does hot code swapping for actors (including state preservation)[1]. This is
possible (as it is in Erlang) because actors encapsulate their own state.

[1]: [http://docs.paralleluniverse.co/quasar/#hot-code-
swapping](http://docs.paralleluniverse.co/quasar/#hot-code-swapping)

------
nmcfarl
Hugh

------
Gepsens
Go [https://golang.org/](https://golang.org/)

~~~
MCRed
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
Could you explain what Go is missing, then?

~~~
kungfooguru
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/)

