3 ms·

You’re mentioning functional languages. That’s not for everyone or every usecase. (I love Erlang.)

ken 8y ago
So, in the world of concurrency, are imperative languages good for every person and every use case? :-) My intention was not to single out functional languages. Those were just the first languages I thought of with the best concurrency support. (I don't think it's mere coincidence, though, that so many concurrency-aware languages are functional. If concurrency is a major concern, perhaps one should consider that "mainstream" or even "imperative" might not necessarily be a hard requirement.) How about Occam or Crystal, then, which use CSP and are imperative yet don't have curly braces?
- AnimalMuppet 8y ago
  > So, in the world of concurrency, are imperative languages good for every person and every use case? :-) Clearly, no. I think it comes down to the question of shared mutable state. Functional languages say "don't do that, it's evil" - with some justification. If the problem doesn't push you toward shared mutable state, then consider functional languages. When could the problem push you toward shared mutable state? I worked on a video router. You had maybe 100 video sources, maybe 80 video destinations, and six different sources of control. All six sources of control needed to see the same state of what inputs were connected to what outputs. So the fundamental nature of the problem was one giant shared mutable state.
  - XorNot 8y ago
    Where this shows up a lot is the types of business problems which functional programming finds itself in. The least surprising thing in the world is that Haskell and functional Scala work pretty okay for Hadoop ETL work, for example.
marcosdumay 8y ago
Neither is concurrency. But if you need concurrency, functional is very visibly the way to go.
- dnautics 8y ago
  Definitely agree. For work I built a highly concurrent job scheduler in 3 months from zero in elixir, and being confident about the internals due to its functional nature let me focus on smoothening the interface edges

ken 8y ago

So, in the world of concurrency, are imperative languages good for every person and every use case? :-) My intention was not to single out functional languages. Those were just the first languages I thought of with the best concurrency support. (I don't think it's mere coincidence, though, that so many concurrency-aware languages are functional. If concurrency is a major concern, perhaps one should consider that "mainstream" or even "imperative" might not necessarily be a hard requirement.) How about Occam or Crystal, then, which use CSP and are imperative yet don't have curly braces?

AnimalMuppet 8y ago
> So, in the world of concurrency, are imperative languages good for every person and every use case? :-) Clearly, no. I think it comes down to the question of shared mutable state. Functional languages say "don't do that, it's evil" - with some justification. If the problem doesn't push you toward shared mutable state, then consider functional languages. When could the problem push you toward shared mutable state? I worked on a video router. You had maybe 100 video sources, maybe 80 video destinations, and six different sources of control. All six sources of control needed to see the same state of what inputs were connected to what outputs. So the fundamental nature of the problem was one giant shared mutable state.
- XorNot 8y ago
  Where this shows up a lot is the types of business problems which functional programming finds itself in. The least surprising thing in the world is that Haskell and functional Scala work pretty okay for Hadoop ETL work, for example.

marcosdumay 8y ago

Neither is concurrency. But if you need concurrency, functional is very visibly the way to go.

dnautics 8y ago
Definitely agree. For work I built a highly concurrent job scheduler in 3 months from zero in elixir, and being confident about the internals due to its functional nature let me focus on smoothening the interface edges