4 ms·

>Erlang was at one point the only way to get this sort of structure, though. It still is though! Isolated processes with asynchronous, dynamic message passing

by jolux 5y ago

>Erlang was at one point the only way to get this sort of structure, though. It still is though! Isolated processes with asynchronous, dynamic message passing requires really heavy libraries in most other languages. Rust is completely different, I can't fathom why you'd compare them in this way.

jerf 5y ago
Because as I've said, I'm not comparing solutions, I'm comparing problems. Rust solves the isolation problem in a completely different way. Go also solves the isolation problem by enforcing it at a language community and best practice level, rather than rigidly enforcing it in the language. Now, I personally wish it had something more like Erlang or Pony, but, at the same time... it's doing fine without it and completely satisfying my Erlang use cases in real code, better than Erlang did. Not perfectly, but fine. (I rather prefer channels as a default to Erlang's message passing, which in both my opinion and experience has the "unbounded buffer" problem in that messages can build up in a queue forever.) Message buses solve the message passing requirement. You can get a whole range of solutions from "just sling vaguely JSON stuff around" to "here's a whole strongly typed protocol", with a whole array of options on persistence, clustering, language support, etc., a whole array of options around how synchronous they are and what guarantees they provide, rather than Erlang's one exact solution, You're kind of demonstrating my exact point here... it isn't that the exact Erlang solution shows up in other languages, the point is that the problem space that Erlang covers is now covered in plenty of other languages, in all sorts of ways, many of them better for some task than Erlang's one point in the space that was selected very, very early in the exploration process. This was not the case 20 years ago. It is now. And I don't particularly think Erlang's coverings of the problem space are the best. People not already deep into Erlang aren't evaluating whether or not some solution is exactly like Erlang, they're evaluating whether the solution is a good solution on its own terms, and once you remove the "must be exactly like Erlang" clause there are a lot of better choices for every element of Erlang, except arguably, the integration of all of them together.
- jolux 5y ago
  I understand your argument, I guess what I'm trying to say is that I don't think these arguments are unique to Erlang, you could make these arguments about the use of any language to solve almost any problem, outside of kernel programming. I choose tools based on how they fit with how I want to solve problems.

by jolux 5y ago

jerf 5y ago

Because as I've said, I'm not comparing solutions, I'm comparing problems. Rust solves the isolation problem in a completely different way. Go also solves the isolation problem by enforcing it at a language community and best practice level, rather than rigidly enforcing it in the language. Now, I personally wish it had something more like Erlang or Pony, but, at the same time... it's doing fine without it and completely satisfying my Erlang use cases in real code, better than Erlang did. Not perfectly, but fine. (I rather prefer channels as a default to Erlang's message passing, which in both my opinion and experience has the "unbounded buffer" problem in that messages can build up in a queue forever.) Message buses solve the message passing requirement. You can get a whole range of solutions from "just sling vaguely JSON stuff around" to "here's a whole strongly typed protocol", with a whole array of options on persistence, clustering, language support, etc., a whole array of options around how synchronous they are and what guarantees they provide, rather than Erlang's one exact solution, You're kind of demonstrating my exact point here... it isn't that the exact Erlang solution shows up in other languages, the point is that the problem space that Erlang covers is now covered in plenty of other languages, in all sorts of ways, many of them better for some task than Erlang's one point in the space that was selected very, very early in the exploration process. This was not the case 20 years ago. It is now. And I don't particularly think Erlang's coverings of the problem space are the best. People not already deep into Erlang aren't evaluating whether or not some solution is exactly like Erlang, they're evaluating whether the solution is a good solution on its own terms, and once you remove the "must be exactly like Erlang" clause there are a lot of better choices for every element of Erlang, except arguably, the integration of all of them together.

jolux 5y ago
I understand your argument, I guess what I'm trying to say is that I don't think these arguments are unique to Erlang, you could make these arguments about the use of any language to solve almost any problem, outside of kernel programming. I choose tools based on how they fit with how I want to solve problems.