[andy_ppp]

The thing that gets me about Erlang and Elixir is that it has transparent and simple to use microservices out of the box. These services are machine transparent, can be called locally and remotely, provide bounded contexts within your application, are robust and supervised against crashes, are simpler to deploy and far far simpler to develop, can be discovered using a variety of solutions or your own code. They also don’t require hundreds of containers interacting to work locally. I would go so far as to suggest that you shouldn’t build a microservices system without looking at the huge time, cost and complexity savings that Elixir or Erlang will give you.

[probablybroken]

But then you need to either replace your existing team with erlang developers, or retrain them ( and then have to suffer years of criticism and staff losses from those who disagree with the move. ) Probably easier, and potentially more appealing to current managers to recruit more sysadmins / tech ops and have a larger organisational pyramid under them. ( I say this as an erlang developer who works in a primarily java oriented organisation.. Perspectives may vary ;) )

[andy_ppp]

I don't actually know Erlang but Elixir has all of the same properties and is simple to learn in my opinion.

[pivo]

Erlang is also simple to learn! Simpler, I think, than Elixir just because Erlang is a simpler language. It’s the concepts that Erlang and Elixir share that take the most effort to lean.

[etxm]

Agree! The Erlang syntax only takes a day or two to learn. It’s succinct! You won’t be an OTP wizard but it doesn’t take much to become fluent with the language itself.

[regulation_d]

I think they’re both pretty simple languages, as far as the basic grammar goes. OTP is a whole other thing. But it strikes me that if you have one person on a team who knows OTP well, that person can assist the others when OTP issues come up.

[nrser]

If it's feasible to write (most) all of your app backend in Elixir, then I think it's a pretty great option. I feel like language context switches tend to be very expensive and error prone for developers, plus the increased hiring and on-boarding cost associated.

I think the core advantages of micro-services are:

1. Polyglot applications. There often is some library in a language for a use case, but there is also often the library in a specific language - the one that has a far larger community around it, very active development, considerable battle testing, a wealth of examples and guides and support available online. If you use this library in this language, you just kind of know it will work as best and easily as possible. The trail is well trodden. You now have a new problem of API contracts and versioning and such, but pretty much every language can at least HTTP and JSON reasonably at this point, so it's fairly tractable.

2. You already have code written in another language that pretty much works, either because of (1) or for historic reasons. If you go all-Elixir, you're going to need to re-write that hairy-ass black-box of a Go service that interfaces with Chinese SMS delivery. But it pretty much works, and if you can just chat with that over HTTP you can keep going. However, you probably want something to turn that thing back on every week-or-two when it inevitably eats it for whatever reason, and K8S gives you a really nice interface for this.

In general, I think - and this was an opinion I read on this forum at some point - that when building from scratch it's best to build a mono-service and then break small things off from that as the need arises, and Elixir would probably be at the top of my current list.

However, if you can run that mono-service in a micro-service environment - Kubernetes and containers - then you're well prepared for breaking pieces off or rolling new isolated components using the "right tool for the job".

I know there are difficulties around BEAM and K8S with both kind-of trying to do a lot of the same things, and that's something to definitely be aware of... people that have worked with it seem divided on where it falls between terrible and not really that bad of an idea (if you're paying attention and have some idea what you're doing).

[cube2222]

That's exactly the problem I have with elixir, or akka for that matter. It's definitely a very convenient abstraction for building microservices and distributed systems, but at the same time it's a heavy language lock-in you're getting yourself into, the moment you start your project.

And especially now, when there are the de facto standard libraries to do various tasks (like TF in Python) I think language lock-in can be a terrible idea.

[dqv]

I don't think it's heavy language lock in at all.

If I need to do something in Python, I have options like pyrlang[0] and rabbitmq[1].

In fact, parsing in Elixir is not nearly as mature as what is provided in Python. I need to parse emails. Python has `email.parser` which is perfect for my use case. I can easily use Pyrlang to do this. But Elixir is still much better at being an email client (or many email clients). The end result is an email client in Elixir that uses Python to parse the emails.

When I started with Elixir, my goal was to use it as much as possible, but delegate as soon as the task is better handled in another language.

[0]:https://github.com/esl/Pyrlang [1]:https://www.rabbitmq.com/

[noPasswdNow1]

You can make Erlang supervise external processes.

[andy_ppp]

Yes it is better to build mono services first because everything becomes N-times more complicated (unexpected requirements, deployment and testing) when you have N services to manage/mock/deploy/test/recover from failures of/log/configure etc.

[alberth]

If Polygot is important to you, check out https://www.graalvm.org

>> “High-performance polyglot VM. GraalVM is a universal virtual machine for running applications written in JavaScript, Python 3, Ruby, R, JVM-based languages like Java, Scala, Kotlin, and LLVM-based languages such as C and C++.

[mncharity]

For anyone else wondering...

"Support for Ruby, R, or Python 3 is still experimental in GraalVM. We are actively working on stability and support for all modules for those languages. At this point in time, we can run simpler applications of Ruby and R, but we do not have the same full compatibility we provide for Java and Node.js applications. Our Python implementation was just recently started and can only run small examples."[1]

[1] https://www.graalvm.org/docs/why-graal/