During the last days I was playing around with HTTP/2 and SSE. Implementing this with Raxx is very easy and due to its streaming-oriented nature. I also implemented this with Phoenix/Plug but it really felt kinda hackish. Phoenix does an excellent job as a tool for building MVC based web-sites thanks to its batteries included. Raxx, on the other hand, is a nice solution when it comes to server streaming or micro services.
woeye
woeye
Just wanted to add my thoughts to this topic, too. First, I would like to state the I really, really enjoy Elixir as a language. Doing software development for more than two decades (god, I feel old) Elixir gave me several new ideads on how to tackle things - especially on the functional programming part. Also I find it quite amazing what you can do with OTP and distributed Elixir/Erlang. If only I had known earlier … 
But as an employee I believe it will be very hard to sell Elixir/Erlang to our customers or even our manager. Here in Germany Java/C# is very popular for traditional enterprises. Startups on the other hand seem to stick to node.js or more lately Golang.
And with the ever increasing popularity of the cloud, especially Kubernetes, Golang seems to become even more popular. Some even say that Golang will the become the lingua franca for cloud computing. Low memory footprint, easy-to-learn, high concurrency and, well, Google.
Maybe it is a bit of a marketing issue, too. Arguments like OTP and fault tolerance doesn help when the CTO states that this is handled by Kubernetes already. So no need for OTP. And while personally I do like the Phoenix package it’s hard to sell it in the ever increasing world of micro services. Every software architect I spoke to told me that without micro services you cannot scale your app. “That’s common knowledge”.
4
Phillipp
Yeah, the software industry in Germany is really frustrating and so much behind other countries.
5
gausby
Good idea. I guess this forum would be an excellent place for that. I’ll check if anyone has opened that thread already. (I might do this later)
3
nsweeting
Arguments like OTP and fault tolerance doesn help when the CTO states that this is handled by Kubernetes already.
I haven’t worked with Kubernetes a lot - but wouldnt it just handle fault-tolerance on the scale of an entire app crashing? Kubernetes + golang (without external golang packages) wouldnt handle fault-tolerance on the “agent” level. Which is where the niceties of OTP and its standards come to play.
3
lasseebert
I also had a hard time convincing companies to do Elixir (as a freelancer in Denmark).
It came to the point that my customers would require me to buy ice cream to them every time I mentioned Elixir.
I ended up starting my own company, become CTO and choose Elixir as the main language 
Now we are 10 people (3 developers) and I managed to hire the first Elixir developer besides my self.
Perhaps not a solution for anybody, since it requires the right place, time and people. But if the right place, time and people are there, go for it! 
39
sribe
Yep, asking for explication of what ideas there actually are outside the current libs that offer value, gets interpreted as claiming any such ideas are worthless. You’ve been crystal clear that you (we) are open to hearing about them–
While this is true, the trend is for the apps in K8s to be smaller and smaller. As in it’s not uncommon to spec 1 CPU & 256MB for Java apps. Of course not everything fits that model, but… K8s pods look more & more like OTP supervisors with a handful of child processes.
3
peerreynders
If somebody is only familiar with mainstream technology they would never expect the notion of fault resilience (rather than bare bones micro-level fault handling) to be part of a programming language.
Most high level programming languages are designed “language first” to perform computations. I suspect Erlang and the BEAM were developed in lockstep for computation and coordination which is why runtime concepts like process links and monitors are part of the core.
Designing for Scalability with Erlang/OTP p.175:
This forms part of the supervision strategy of a system and in some situations is put in place not by the developer, who focuses only on what particular workers have to do, but by the architect, who has an overall view and understanding of the system and how the different components interact with each other.
There also seems to be a drive to commoditize developer skills and designing for fault resilience seems to require a more advanced skill set. So the responsibility is pushed to the next level up, outside of the container. At this level of granularity the container becomes the “component”, k8s adopts the “let it crash” philosophy, creating design pressures to have the “component” no larger than what you can afford to lose.
At least that is my current perception …
10
dimitarvp
This seems to be the crux of this divide we’re lately witnessing (K8s vs. other deployment strategies). Many CTOs and programmers in general want to treat fault tolerance as an implementation detail that can be offloaded onto the Operations / Sysadmins team. I certainly witnessed such efforts several times already.
I mean OK, they are free to try but I have the feeling that the IT area at large will yet again waste humongous amounts of time, spend a lot of money, generate huge legacy somebody has to maintain, burn out and seek alternatives… and then somebody will notice that Erlang had 99% of what they wanted all along. 
11
tristan
Rebar3 Core Team
Maybe it is miscommunication. People hear “restart the process” and view it as a higher layer and similar to k8s. But restarting a crashed process isn’t new and Erlang itself even comes with heart but no one has questioned what the point of supervision is if you have heart.
I think this goes beyond simply explaining the performance/cost benefits of not churning k8s pods. It could need an explanation that breaks down how it helps structuring your program and how you would no more want to be without it than you would try/catch.
3