6 ms·

Erlang/Elixir were designed for telecommunication programs. If what you are doing is even vaguely like this Erlang/Elixir are going to be perhaps the best langu

by R0b0t1 5y ago

Erlang/Elixir were designed for telecommunication programs. If what you are doing is even vaguely like this Erlang/Elixir are going to be perhaps the best language you could pick. If you need to make a GUI or handle a CRUD app it may well be the worst language you could pick. Elixir is a lot more forgiving, but with Erlang you can tell it was made for telecom switches.

OkayPhysicist 5y ago
Have you used Phoenix? With it, Elixir is easily the best language to build CRUD app in. No other web framework even comes close.
dnautics 5y ago
> If you need to make a GUI or handle a CRUD app it may well be the worst language you could pick. I don't know how else to say this except that it's complete nonsense. I work for a place that deploys an elixir crud app and it's very nice despite tons of domain mistakes, annoying 3rd party APIs we connect to and bad architectural patterns that have accumulated over the course of several years of a brownfield project (I am a relatively recent hire). I can't imagine dealing with all that pain in another language
- R0b0t1 5y ago
  Usually when I see a story like that it goes the other way. The friction of integrating ${nice_thing} with ${everything_else}. I'll take your word for it for now, but it seems like your honeymoon period with FP-heavy programming just coming into industry.
  - lostcolony 5y ago
    I've had over a decade of experience in this industry, ~2-3 with Erlang, ~3 with node, ~3 with Java, ~1 with Go, and a smattering of others (C#, Ruby), plus plenty of others outside of production deployments. Erlang was as easy as any of them for CRUD apps. I used Cowboy for it, which is comparable to Express (JS) or Gin (Go) in how it approaches things (i.e., simple request/response paradigm, with various helper functions to pull stuff out of the request data, or write into the response data, and easy to insert middleware as, again, just functions). Integrations outside of the app weren't especially painful; admittedly, we didn't have to integrate with an undocumented API whose only integration was via supplied library that was implemented only in Java or similar. Is your objection just "CRUD apps have to integrate with lots of downstreams, and so for that you want a language that has a huge plethora of libraries to make those integrations easy"? Because in that case "maybe". But that's orthogonal to being a CRUD app; that's simply because you have a bajillion dependencies that have existing libraries.
    - R0b0t1 5y ago
      > Is your objection just "CRUD apps have to integrate with lots of downstreams, and so for that you want a language that has a huge plethora of libraries to make those integrations easy"? There's real projects where you have to bind together 10 different things and using C++ is simply the most expedient option because getting FFI bindings made for everything is intractable. I have a feeling most of the people here (especially the ones downvoting me) only have web experience.
      - pdimitar 5y ago
        You are grossly underestimating fault tolerance, looks like. Being a fan of C++ is fine but you come across as biased.
        R0b0t1 5y ago
        I'm not a fan of C++. I'm a fan of Erlang and the OTP. The entire reason I became interested in Erlang was fault tolerance. I have no idea why I'm getting downvoted, exactly what I have said was said later, above, and is more highly upvoted. The people here are not really painting a good picture of BEAM vm languages. The typical complaint is some extremely energetic new hire wants to use Erlang for something, does, and then it turns into a hard to maintain mess. You can equivocate about the specific reasons but if you are really going to say ignoring legacy compatibility is stupid then I'm not sure what to tell you.
        pdimitar 5y ago
        I think the disconnect (and downvotes, although I didn't downvote you) comes from mismatched expectations. When you say this: > There's real projects where you have to bind together 10 different things and using C++ is simply the most expedient option because getting FFI bindings made for everything is intractable. My immediate reaction was: "But dude, that doesn't apply to web development, and Elixir is most of the time used only for that". So your aside seemed inapplicable and out of place for this thread. Elixir isn't used for such projects most of the time (with some notable exceptions like the Nerves framework that allows you to burn a full bootable image of an Erlang/Elixir app to an SD card and boot off of it to a supported set of ARM and x64 SBCs). And then you say this: > I have a feeling most of the people here (especially the ones downvoting me) only have web experience. Which is, again, a bit out of place as a comment here, because again, Elixir is mostly used for web apps (REST, normal Web, GraphQL, WebSockets magic like LiveView etc). So to me it looks like your comment was addressing a wider issue that is mostly applicable to projects that actually care a lot about backwards compatibility -- and most web projects don't. > The people here are not really painting a good picture of BEAM vm languages. The typical complaint is some extremely energetic new hire wants to use Erlang for something, does, and then it turns into a hard to maintain mess. This happens in every ecosystem I've participated in for my 19.5 years of career (including when I was doing C++) so I urge you not to end up being negatively biased against the BEAM ecosystem folk in particular. People do get hyped and invest a lot of energy trying to fit square pegs into round holes -- and several months/years later people like myself are being called to beat the project back into shape. I have given up hope that the programmers at large will ever learn not to get hyped and judge tech based on its merits... :|
  - dnautics 5y ago
    Well, I have been "programming FP-heavy" for about ten years, and before that, I used ruby/python, (though admittedly not professionally). I did help maintain an absolutely godawful yet bog-standard django site for a short spell as a professional. The reason why elixir is fantastic is in such a ball of mud codebase, you can truly work in one corner of the codebase and not worry about anything else being disrupted. Testing story is also great. You can very simply do things you can't in other languages so easily, like concurrent tests that hit the database.
sodapopcan 5y ago
Well yes, but Erlang was actually solving the far more generalized problem of concurrent client/server applications. I would almost go as far as to say it's a DSL for writing such applications. So like, why isn't this stuff more popular? Because it's dynamic? Because Node? I dunno. Our industry is weird, or perhaps very normal in the age old mantra "Why do it the easy way when we could just do it the hard way?".
- arcturus17 5y ago
  I think Node would indeed be seen as the “easier” choice for project with concurrency needs thanks to its async model. As much as I like JS I’m not a big fan of it on the server however - web frameworks are lacking and tooling and libraries feel like the wild west. In Phoenix I’d see a web framework for projects with concurrency reqs, with great ergonomics and DX, nothing else. Maybe I’d miss types? But we work with Python just fine.
arcturus17 5y ago
I keep hearing Phoenix is an outstanding web framework for CRUD apps. I wouldn’t be trying this without building a significant web app and seeing for myself first anyway. And yes, high concurrency can be a fairly common req in web projects, it’s not only seen in telecomms engineering.
jon-wood 5y ago
There's not a huge difference between the domain of telecom switches and modern web applications. You've got multiple clients connecting, with the understanding that one client shouldn't have undue impact on the responsiveness seen by other clients. This is even more true once you get into using websockets which are directly analogous to active calls in a telecom switch - one websocket channel dying shouldn't cause other user's channels to be killed as well.

by R0b0t1 5y ago

OkayPhysicist 5y ago

Have you used Phoenix? With it, Elixir is easily the best language to build CRUD app in. No other web framework even comes close.

dnautics 5y ago

> If you need to make a GUI or handle a CRUD app it may well be the worst language you could pick. I don't know how else to say this except that it's complete nonsense. I work for a place that deploys an elixir crud app and it's very nice despite tons of domain mistakes, annoying 3rd party APIs we connect to and bad architectural patterns that have accumulated over the course of several years of a brownfield project (I am a relatively recent hire). I can't imagine dealing with all that pain in another language

R0b0t1 5y ago
Usually when I see a story like that it goes the other way. The friction of integrating ${nice_thing} with ${everything_else}. I'll take your word for it for now, but it seems like your honeymoon period with FP-heavy programming just coming into industry.
- lostcolony 5y ago
  I've had over a decade of experience in this industry, ~2-3 with Erlang, ~3 with node, ~3 with Java, ~1 with Go, and a smattering of others (C#, Ruby), plus plenty of others outside of production deployments. Erlang was as easy as any of them for CRUD apps. I used Cowboy for it, which is comparable to Express (JS) or Gin (Go) in how it approaches things (i.e., simple request/response paradigm, with various helper functions to pull stuff out of the request data, or write into the response data, and easy to insert middleware as, again, just functions). Integrations outside of the app weren't especially painful; admittedly, we didn't have to integrate with an undocumented API whose only integration was via supplied library that was implemented only in Java or similar. Is your objection just "CRUD apps have to integrate with lots of downstreams, and so for that you want a language that has a huge plethora of libraries to make those integrations easy"? Because in that case "maybe". But that's orthogonal to being a CRUD app; that's simply because you have a bajillion dependencies that have existing libraries.
  - R0b0t1 5y ago
    > Is your objection just "CRUD apps have to integrate with lots of downstreams, and so for that you want a language that has a huge plethora of libraries to make those integrations easy"? There's real projects where you have to bind together 10 different things and using C++ is simply the most expedient option because getting FFI bindings made for everything is intractable. I have a feeling most of the people here (especially the ones downvoting me) only have web experience.
    - pdimitar 5y ago
      You are grossly underestimating fault tolerance, looks like. Being a fan of C++ is fine but you come across as biased.
      - R0b0t1 5y ago
        I'm not a fan of C++. I'm a fan of Erlang and the OTP. The entire reason I became interested in Erlang was fault tolerance. I have no idea why I'm getting downvoted, exactly what I have said was said later, above, and is more highly upvoted. The people here are not really painting a good picture of BEAM vm languages. The typical complaint is some extremely energetic new hire wants to use Erlang for something, does, and then it turns into a hard to maintain mess. You can equivocate about the specific reasons but if you are really going to say ignoring legacy compatibility is stupid then I'm not sure what to tell you.
        pdimitar 5y ago
        I think the disconnect (and downvotes, although I didn't downvote you) comes from mismatched expectations. When you say this: > There's real projects where you have to bind together 10 different things and using C++ is simply the most expedient option because getting FFI bindings made for everything is intractable. My immediate reaction was: "But dude, that doesn't apply to web development, and Elixir is most of the time used only for that". So your aside seemed inapplicable and out of place for this thread. Elixir isn't used for such projects most of the time (with some notable exceptions like the Nerves framework that allows you to burn a full bootable image of an Erlang/Elixir app to an SD card and boot off of it to a supported set of ARM and x64 SBCs). And then you say this: > I have a feeling most of the people here (especially the ones downvoting me) only have web experience. Which is, again, a bit out of place as a comment here, because again, Elixir is mostly used for web apps (REST, normal Web, GraphQL, WebSockets magic like LiveView etc). So to me it looks like your comment was addressing a wider issue that is mostly applicable to projects that actually care a lot about backwards compatibility -- and most web projects don't. > The people here are not really painting a good picture of BEAM vm languages. The typical complaint is some extremely energetic new hire wants to use Erlang for something, does, and then it turns into a hard to maintain mess. This happens in every ecosystem I've participated in for my 19.5 years of career (including when I was doing C++) so I urge you not to end up being negatively biased against the BEAM ecosystem folk in particular. People do get hyped and invest a lot of energy trying to fit square pegs into round holes -- and several months/years later people like myself are being called to beat the project back into shape. I have given up hope that the programmers at large will ever learn not to get hyped and judge tech based on its merits... :|
- dnautics 5y ago
  Well, I have been "programming FP-heavy" for about ten years, and before that, I used ruby/python, (though admittedly not professionally). I did help maintain an absolutely godawful yet bog-standard django site for a short spell as a professional. The reason why elixir is fantastic is in such a ball of mud codebase, you can truly work in one corner of the codebase and not worry about anything else being disrupted. Testing story is also great. You can very simply do things you can't in other languages so easily, like concurrent tests that hit the database.

sodapopcan 5y ago

Well yes, but Erlang was actually solving the far more generalized problem of concurrent client/server applications. I would almost go as far as to say it's a DSL for writing such applications. So like, why isn't this stuff more popular? Because it's dynamic? Because Node? I dunno. Our industry is weird, or perhaps very normal in the age old mantra "Why do it the easy way when we could just do it the hard way?".

arcturus17 5y ago
I think Node would indeed be seen as the “easier” choice for project with concurrency needs thanks to its async model. As much as I like JS I’m not a big fan of it on the server however - web frameworks are lacking and tooling and libraries feel like the wild west. In Phoenix I’d see a web framework for projects with concurrency reqs, with great ergonomics and DX, nothing else. Maybe I’d miss types? But we work with Python just fine.

arcturus17 5y ago

I keep hearing Phoenix is an outstanding web framework for CRUD apps. I wouldn’t be trying this without building a significant web app and seeing for myself first anyway. And yes, high concurrency can be a fairly common req in web projects, it’s not only seen in telecomms engineering.

jon-wood 5y ago

There's not a huge difference between the domain of telecom switches and modern web applications. You've got multiple clients connecting, with the understanding that one client shouldn't have undue impact on the responsiveness seen by other clients. This is even more true once you get into using websockets which are directly analogous to active calls in a telecom switch - one websocket channel dying shouldn't cause other user's channels to be killed as well.