4 ms·

What difference does it make? Erlang/OTP distribution doesn't have pluggable architecture. Sooner or later you will reach a point that you have to modify it. Th

What difference does it make? Erlang/OTP distribution doesn't have pluggable architecture. Sooner or later you will reach a point that you have to modify it. Then you are diverging from the original branch which makes it even more difficult to maintain it. You have to merge your additions into every release (minor or major) and test it thoroughly. A better architecture for a distributed system has a strong composability property. It should be possible to modify every possible aspect of it on a running cluster without introducing downtime. Write your own standard well documented distribution layer and become independent of underlying technologies.

andy_ppp 9y ago
I think, 1) you are misunderstanding the grand parents points. Better to have primitives that scale you to X rather than having to get to X on your own. 2) The grand parent wrote the Elixir language. 3) Making sweeping statements like "A better architecture for a distributed system has a strong composability property" is very easy.
- majidazimi 9y ago
  > 1) Better to have primitives that scale you to X rather than having to get to X on your own. For a fast time to market, I do agree with you. But if you are well established company in the market, then in most cases "do it yourself" is the best idea. Unless you have the money to call for experts to fix the problem for you. > 2) The grand parent wrote the Elixir language. I didn't know him, nor I care. > 3) Making sweeping like "A better architecture for a distributed system has a strong composability property" is very easy. I'm considering this as an excuse, than a technical argument.
  - josevalim 9y ago
    > But if you are well established company in the market, then in most cases "do it yourself" is the best idea. Unless you have the money to call for experts to fix the problem for you. This requires having distributed system experts on your team or having the money to call them from day one, before you even reach the market and before you are even sure you will have custom needs. If you have the need, the expertize and the time, then surely. But writing a distributed system from scratch should certainly not be the first choice (IMO).
josevalim 9y ago
What do you mean by architecture here? If you mean the roles different nodes take and their topology, I actually doubt you can be decoupled from your architecture in a distributed system because they directly affect your design and capabilities. You can move away from fully meshed for topologies but how does this choice affect node ups and node downs? Rebalancing can affect how you store data in the cluster. How many connections should you have between nodes? A single connection makes the ordering guarantee straight-forward. Multiple connections is more performance but requires care if you need ordering and is more efficiently done along side your application. And what about process placement? On which side of CAP do you want your registries to sit? If you and your team is capable of "writing your own standard well documented distributed layer" upfront, then you are in a better position than most to take those decisions. But writing a distributed system is hard, so I will gladly start with a well-designed system, especially at the beginning of the project, when it may be unclear which patterns I will need as my application and business grow. And most times, it will be good enough. As far as OTP goes, you can plug your own discovery/topology mechanism as well as your own module for handling the connection between nodes. But, as mentioned in my previous reply, some of those issues may be better solved on the side, e.g. a different tcp/udp connection for data transmitting.
- majidazimi 9y ago
  I did also mention that for fast time to market it is indeed a good idea to use already available tools. By the way writing a distribution layer is not that difficult. Many companies/startups with scalable back-ends that are not using Erlang/OTP have already done it. The point is scalable software requires knowledge and Erlang/OTP is not going to magically solve it. But it seems many fans are trying to promote it such that it is a magic tool that is going to make a shit software become a hyper scalable one. Just look at the comments below that how people have gone crazy.
  - jlouis 9y ago
    Erlang (and by extension Elixir) definitely provides a set of tools which are good for building highly concurrent distributed systems. And your systems are likely to have few errors as well as being resilient, if you know what you are doing. But indeed, you need to know your tools like every other part of computer science. Storing 9 billion elements in an array, doing linear search and then complaining your linear search is too slow and needs to run faster will be disastrous to your architecture. Likewise, assuming communication is free is equally disastrous. The problem with building a distribution layer in another language is the effort involved. Most of the companies which pull that off and get stability in addition are usually large, multinational, and has ample amounts of engineering resources to throw at the effort required.
adrianN 9y ago
Good luck writing something on your own that scales better.
eternalban 9y ago
> A better architecture for a distributed system has a strong composability property. Sure, you want a beautiful lover, but is your object of desire within your reach? One needs to be practical when playing engineer. Let's try this: Composibility is a highly desired property for distributed systems however correctly scaling composible semantics is a hard problem. This sort of duality props up all over the place in general engineering, and certainly in software systems engineering.

andy_ppp 9y ago

I think, 1) you are misunderstanding the grand parents points. Better to have primitives that scale you to X rather than having to get to X on your own. 2) The grand parent wrote the Elixir language. 3) Making sweeping statements like "A better architecture for a distributed system has a strong composability property" is very easy.

majidazimi 9y ago
> 1) Better to have primitives that scale you to X rather than having to get to X on your own. For a fast time to market, I do agree with you. But if you are well established company in the market, then in most cases "do it yourself" is the best idea. Unless you have the money to call for experts to fix the problem for you. > 2) The grand parent wrote the Elixir language. I didn't know him, nor I care. > 3) Making sweeping like "A better architecture for a distributed system has a strong composability property" is very easy. I'm considering this as an excuse, than a technical argument.
- josevalim 9y ago
  > But if you are well established company in the market, then in most cases "do it yourself" is the best idea. Unless you have the money to call for experts to fix the problem for you. This requires having distributed system experts on your team or having the money to call them from day one, before you even reach the market and before you are even sure you will have custom needs. If you have the need, the expertize and the time, then surely. But writing a distributed system from scratch should certainly not be the first choice (IMO).

josevalim 9y ago

What do you mean by architecture here? If you mean the roles different nodes take and their topology, I actually doubt you can be decoupled from your architecture in a distributed system because they directly affect your design and capabilities. You can move away from fully meshed for topologies but how does this choice affect node ups and node downs? Rebalancing can affect how you store data in the cluster. How many connections should you have between nodes? A single connection makes the ordering guarantee straight-forward. Multiple connections is more performance but requires care if you need ordering and is more efficiently done along side your application. And what about process placement? On which side of CAP do you want your registries to sit? If you and your team is capable of "writing your own standard well documented distributed layer" upfront, then you are in a better position than most to take those decisions. But writing a distributed system is hard, so I will gladly start with a well-designed system, especially at the beginning of the project, when it may be unclear which patterns I will need as my application and business grow. And most times, it will be good enough. As far as OTP goes, you can plug your own discovery/topology mechanism as well as your own module for handling the connection between nodes. But, as mentioned in my previous reply, some of those issues may be better solved on the side, e.g. a different tcp/udp connection for data transmitting.

majidazimi 9y ago
I did also mention that for fast time to market it is indeed a good idea to use already available tools. By the way writing a distribution layer is not that difficult. Many companies/startups with scalable back-ends that are not using Erlang/OTP have already done it. The point is scalable software requires knowledge and Erlang/OTP is not going to magically solve it. But it seems many fans are trying to promote it such that it is a magic tool that is going to make a shit software become a hyper scalable one. Just look at the comments below that how people have gone crazy.
- jlouis 9y ago
  Erlang (and by extension Elixir) definitely provides a set of tools which are good for building highly concurrent distributed systems. And your systems are likely to have few errors as well as being resilient, if you know what you are doing. But indeed, you need to know your tools like every other part of computer science. Storing 9 billion elements in an array, doing linear search and then complaining your linear search is too slow and needs to run faster will be disastrous to your architecture. Likewise, assuming communication is free is equally disastrous. The problem with building a distribution layer in another language is the effort involved. Most of the companies which pull that off and get stability in addition are usually large, multinational, and has ample amounts of engineering resources to throw at the effort required.

adrianN 9y ago

Good luck writing something on your own that scales better.

eternalban 9y ago

> A better architecture for a distributed system has a strong composability property. Sure, you want a beautiful lover, but is your object of desire within your reach? One needs to be practical when playing engineer. Let's try this: Composibility is a highly desired property for distributed systems however correctly scaling composible semantics is a hard problem. This sort of duality props up all over the place in general engineering, and certainly in software systems engineering.