4 ms·

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

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.

deleted 9y ago
[deleted]
probablybroken 9y ago
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 9y ago
  I don't actually know Erlang but Elixir has all of the same properties and is simple to learn in my opinion.
  - pivo 9y ago
    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 9y ago
      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 9y ago
    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.
- deleted 9y ago
  [deleted]
nrser 9y ago
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).
- andy_ppp 9y ago
  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.
- 9y ago

deleted 9y ago

[deleted]

probablybroken 9y ago

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 9y ago
I don't actually know Erlang but Elixir has all of the same properties and is simple to learn in my opinion.
- pivo 9y ago
  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 9y ago
    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 9y ago
  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.
deleted 9y ago
[deleted]

nrser 9y ago

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

andy_ppp 9y ago
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.
9y ago