I discovered Erlang in the late 2000s via its kinda weird and iconic video "Erlang the Movie" https://www.youtube.com/watch?v=xrIjfIjssLE that prompted me to dig further. I was at the time an average developer. Erlang, and Joe Armstrong books and videos, made me understand things that other web-oriented languages ( Ruby, PHP... ) never really dug into at the time.
Because the Erlang ecosystem is more than distribution. Distribution is a consequence of its design around concurrency and message passing and let-it-crash/auto-healing philosophy. Erlang, and after that Elixir, made me think differently about code and made me a better programmer.
Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang.
I expected a bit more of content in the article, like which components of kubernetes equals which OTP functions or general patterns and how easy can be to implement your mini-kubernetes on Erlang, not just “hey they both solve the problems of a distributed by using similar patterns”.
I wish I could downvote but this feature does not seem available in my UI, I guess only certain users can downvote.
The main difference sadly break most of the analogy.
Because a pod is far from the granularity of a process. It is closer to the granularity of an application, the biggest abstraction that OTP gives you.
What that mean is that k8s does not have the same property than erlang. In erlang, isolation is your go to tool. If you need something, you spawn a process. Having a lot of really granular process makes scheduling on cores easy, makes your design easy to crash because the blast area is small, and makes it really cheap to have message passing in the core of the VM.
In k8s, any networking is hard, hence the current trend of service mesh. As the unit of computation is bigger, supervision get harder. Building a supervision tree is more expensive. And crashing and restarting get more expensive too.
K8s has the advantage of being language agnostic ofc. But do not forget the paradigm shift that having really cheap process give you in an integrated environment like the BEAM.
And ofc, i have not even talked about the dynamic tracing that the BEAM gives.
I recently went half way in a project using Erlang back-end but didn't get to a production stage mainly due to political reasons in my organization. Mnesia (Erlang’s distributed database) is remarkable and in the Erlang way it comes completely packaged with the system. My only gripe is that documentation overall is a bit hard once you start digging in. The OTP book mentioned is good but may be a bit dated (but we can figure out what is amiss still). I am not sure whether drivers for accessing external databases such as Mongo, Postgresql etc are actively maintained. (Edit: when I check it now it looks like the drivers are recently updated!)
>>Elixir depends on the decades of development behind the Erlang VM and in many ways is just syntactic sugar on top of Erlang/OTP
I think calling Elixir "just syntactic sugar" is a gross and unfair oversimplification. While friendly syntax is one of its welcoming qualities, Elixir is its own language. It doesn't "transpile" into Erlang. It compiles down to bytecode.
Elixir creates an AST which is transformed into Erlang Abstract Format (http://erlang.org/doc/apps/erts/absform.html) which is then compiled into Erlang bytecode by Erlang compiler.
I agree with your post because Elixir has brought so much beyond syntax to the BEAM such as tool aesthetics and community building. However, Elixir does not compile to BEAM bytecode directly. The compiler emits Erlang terms first which are then compiled to bytecode.
Eventually I try to do something with Elixir. Then suddenly everything is so good.
The whole experience how I create a new project with `mix`, get dependencies, build, compile, run `repl` was so much better than rebar.
To me, `mix` is the greatest tool. I don't see something like mix in other languages, except Clojure and Leiningen.
The community around Elixir is awesome too. It's very different from Erlang type. I have a hard time to find library and stuff in Erlang before. I don't have a central place to look for that. Elixir brough me hex.pm.
I personally like Erlang syntax, I think it's short and concise. But I end up like Elixir much more than Erlang.
Does Erlang support structural sharing between large data structures? If not, how is it possible to efficiently pass large messages between processes on the same physical machine?
The only thing that is passed "efficiently" between processes are large binary blobs. Everything[0] else is copied. Up to a point, this is efficient, as a copy decouples sharing and this is really good for modern caches, and it is good for the garbage collection.
However, when the data becomes too large, Erlang programmers often choose to bring the computation to the data rather than the other way around. Passing a function is efficient. Keeping data cache-local in a process is efficient.
Passing on a local machine is optimized quite well. The API is the same as passing to a remote machine, but serialization is omitted when passing locally. A fair amount of copying still happens, but (I assume--now we're into territory that I am less sure about) that keeps the implementation robust and simple (i.e. there's no "ownership" to wrangle down in the BEAM; at the highest level of abstraction inside the VM, it's just copies of immutable structures).
For communicating quickly locally, you could use large/refcounted binaries (http://erlang.org/doc/efficiency_guide/binaryhandling.html) in to avoid copying-on-message-pass. Those generally tend to be frowned upon, and incur the usual headaches/perf issues of a ref-counted structure as well.
In short, I'd suggest defaulting to the assumption that Erlang is fast enough at passing messages locally for it not to matter that much in practice. Benchmark the throughput of your system locally, and if the overhead of message passing isn't a major pain point immediately, move on up the stack. If you're doing scientific computing and want to number-crunch huge data sets in parallel via some minimal-coordination memory-map-backed system, this is not the platform for you (or use a NIF).
> To wrap up, it's evident that much of the work that went into Erlang has inspired the work of Kubernetes.
Even if there are clear similarities between Erlang and Kubernetes, I'm not sure the former inspired the latter. We should ask Kubernetes developers :-)
Kubernetes is based on borg which as far as I know wasn't really inspired by erlang necessarily. However I suspect the problem space lends itself to idenpendent discovery of very similar solutions.
In large Erlang applications, the "send to multiple peers" broadcast tendencies of its message passing can indeed cause the network to become a bottleneck; so can the default chattiness that a lot of Erlang application developers assume for their app behavior.
Fortunately, there are lots of simple-to-apply patterns and solutions when you get to that point, for example the excellent Partisan library: https://github.com/lasp-lang/partisan
Sure. As with any other distributed processing, if you have enough other resources, you can run out of network. Or if something happens to reduce capacity of the network, it's going to constrain the rest of your system.
It depends on what you're doing. At work we have several systems that needed to upgrade to 2x 10G Ethernet (from 2x 1G), but not much pushes that limit at the moment. Our newer hosting is more badwidth with smaller CPU and RAM, so we expect to see more CPU constraints than network constraints.
if you push your design to the limits of scalability, then you gonna hit a wall at some point (IO, memory or CPU) and as long as your application is not based on CPU intensive calculations (simulations, calculus, ...) most of the time IO is the bottleneck, network or disk.
However, I am not that experienced in distributed applications and would appreciate reading the opinions from more experienced engineers.
Yes! Each node has a name and you would look into the functions on the Node module on how to do that. In Elixir you'd say:
iex(3)> defmodule Hello do
...(3)> def world() do
...(3)> IO.puts "here we go!"
...(3)> end
...(3)> end
iex(4)> Node.spawn_link(:erlang.node(), fn -> Hello.world() end)
here we go!
#PID<0.101.0>
If you like the O'Reilly format then I liked Designing for Scalability with Erlang/OTP. I thought it was light on the details beyond scaling beyond single node OTP apps but it covers a lot of the built-in Erlang functionality pretty well
[+] [-] julienmarie|8 years ago|reply
[+] [-] paulsutter|8 years ago|reply
https://youtu.be/rRbY3TMUcgQ
[+] [-] outlog|8 years ago|reply
Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang.
https://rvirding.blogspot.com/2008/01/virdings-first-rule-of...
(he is one of the creators of erlang / stars in Erlang the Movie)
[+] [-] TurboHaskal|8 years ago|reply
[+] [-] nudpiedo|8 years ago|reply
I wish I could downvote but this feature does not seem available in my UI, I guess only certain users can downvote.
[+] [-] di4na|8 years ago|reply
Because a pod is far from the granularity of a process. It is closer to the granularity of an application, the biggest abstraction that OTP gives you.
What that mean is that k8s does not have the same property than erlang. In erlang, isolation is your go to tool. If you need something, you spawn a process. Having a lot of really granular process makes scheduling on cores easy, makes your design easy to crash because the blast area is small, and makes it really cheap to have message passing in the core of the VM.
In k8s, any networking is hard, hence the current trend of service mesh. As the unit of computation is bigger, supervision get harder. Building a supervision tree is more expensive. And crashing and restarting get more expensive too.
K8s has the advantage of being language agnostic ofc. But do not forget the paradigm shift that having really cheap process give you in an integrated environment like the BEAM.
And ofc, i have not even talked about the dynamic tracing that the BEAM gives.
[+] [-] Steeeve|8 years ago|reply
[+] [-] icebraining|8 years ago|reply
[+] [-] gtycomb|8 years ago|reply
[+] [-] pipu|8 years ago|reply
[+] [-] enraged_camel|8 years ago|reply
I think calling Elixir "just syntactic sugar" is a gross and unfair oversimplification. While friendly syntax is one of its welcoming qualities, Elixir is its own language. It doesn't "transpile" into Erlang. It compiles down to bytecode.
[+] [-] dmitriid|8 years ago|reply
Elixir creates an AST which is transformed into Erlang Abstract Format (http://erlang.org/doc/apps/erts/absform.html) which is then compiled into Erlang bytecode by Erlang compiler.
Erlang VM's bytecode is largely undocumented (except for third-party attempts like http://erlangonxen.org/more/beam and http://beam-wisdoms.clau.se/en/latest/). So all languages on the Erlang VM either create and compile Erlang Abstract Format or transpile to Core Erlang (https://8thlight.com/blog/kofi-gumbs/2017/05/02/core-erlang....)
[+] [-] rubiquity|8 years ago|reply
[+] [-] kureikain|8 years ago|reply
Eventually I try to do something with Elixir. Then suddenly everything is so good.
The whole experience how I create a new project with `mix`, get dependencies, build, compile, run `repl` was so much better than rebar.
To me, `mix` is the greatest tool. I don't see something like mix in other languages, except Clojure and Leiningen.
The community around Elixir is awesome too. It's very different from Erlang type. I have a hard time to find library and stuff in Erlang before. I don't have a central place to look for that. Elixir brough me hex.pm.
I personally like Erlang syntax, I think it's short and concise. But I end up like Elixir much more than Erlang.
[+] [-] rs86|8 years ago|reply
[+] [-] amelius|8 years ago|reply
[+] [-] jlouis|8 years ago|reply
However, when the data becomes too large, Erlang programmers often choose to bring the computation to the data rather than the other way around. Passing a function is efficient. Keeping data cache-local in a process is efficient.
[0] Except literal data.
[+] [-] zbentley|8 years ago|reply
For communicating quickly locally, you could use large/refcounted binaries (http://erlang.org/doc/efficiency_guide/binaryhandling.html) in to avoid copying-on-message-pass. Those generally tend to be frowned upon, and incur the usual headaches/perf issues of a ref-counted structure as well.
In short, I'd suggest defaulting to the assumption that Erlang is fast enough at passing messages locally for it not to matter that much in practice. Benchmark the throughput of your system locally, and if the overhead of message passing isn't a major pain point immediately, move on up the stack. If you're doing scientific computing and want to number-crunch huge data sets in parallel via some minimal-coordination memory-map-backed system, this is not the platform for you (or use a NIF).
[+] [-] kd5bjo|8 years ago|reply
[+] [-] sb8244|8 years ago|reply
https://hamidreza-s.github.io/erlang%20garbage%20collection%...
[+] [-] e12e|8 years ago|reply
[+] [-] ngrilly|8 years ago|reply
Even if there are clear similarities between Erlang and Kubernetes, I'm not sure the former inspired the latter. We should ask Kubernetes developers :-)
[+] [-] zaphar|8 years ago|reply
[+] [-] z3t4|8 years ago|reply
[+] [-] zbentley|8 years ago|reply
Fortunately, there are lots of simple-to-apply patterns and solutions when you get to that point, for example the excellent Partisan library: https://github.com/lasp-lang/partisan
[+] [-] toast0|8 years ago|reply
It depends on what you're doing. At work we have several systems that needed to upgrade to 2x 10G Ethernet (from 2x 1G), but not much pushes that limit at the moment. Our newer hosting is more badwidth with smaller CPU and RAM, so we expect to see more CPU constraints than network constraints.
[+] [-] nudpiedo|8 years ago|reply
However, I am not that experienced in distributed applications and would appreciate reading the opinions from more experienced engineers.
[+] [-] ngrilly|8 years ago|reply
[+] [-] _asummers|8 years ago|reply
[+] [-] pipu|8 years ago|reply
[+] [-] jb3689|8 years ago|reply
http://shop.oreilly.com/product/0636920024149.do
[+] [-] cinbun8|8 years ago|reply