7 ms·

PHP is trivial. Understanding it and shipping code can be done by a 9 year old. Rails is trivial. What is so trivial about Elixir? More concepts, caring way mor

PHP is trivial. Understanding it and shipping code can be done by a 9 year old. Rails is trivial. What is so trivial about Elixir? More concepts, caring way more about performance and concurrency (things a normal dev has to deal with very very rarely). Just don't see the upside

brightball 7y ago
It's understandable. Elixir is one of those languages you won't really appreciate until you've experienced the problems that it addresses. You're getting down voted mostly because of your tone (IMO) but the appeal if Elixir is just a reality of experience. When I found it, I was 15 years in my career and when I dove in, learned it and saw how it addressed so many short term and long term issues that appear in application development...the balance was the closest thing I'd seen to perfect. But if I hadn't experienced the pain, I would never have appreciated it all the little details.
- preommr 7y ago
  It would be nice if you elaborated on what those problems are and how elixir solves them better than existing alternatives. All I ever see is people exclaiming how awesome it is and then the responses turn out to be underwhelming for various reasons. Like hot reloading isn't that special or unique anymore.
  - gregors 7y ago
    I feel like this talk does a great job of answering that question - The Soul of Erlang and Elixir by Saša Jurić (https://www.youtube.com/watch?v=JvBT4XBdoUE https://www.youtube.com/watch?v=JvBT4XBdoUE)
    - preommr 7y ago
      lol, there's the hot reloading. But that's an interesting talk. I didn't have time to go through the whole thing but the core of it seems to be the pros of erlang like BEAM's high concurrency advantages and uniformity of tools running on top of otp. It's an interesting argument.
  - brightball 7y ago
    I need to write about it more. The most in depth piece I've written was this one: https://blog.codeship.com/comparing-elixir-go/ https://blog.codeship.com/comparing-elixir-go/ Hot reloading is very unique though (but not necessary for most use cases). There's no other stack outside of the BEAM that has an equivalent. A lot of what is offered by the BEAM isn't even possible in other stacks because it requires a collective of language decisions working together.
- joelbluminator 7y ago
  Doing this for 7 years, have yet to seen a problem throwing more servers/caching/database locks can't handle. I'm not saying those problems don't exist, I'm just saying it's not that common. Agree about the tone, was having a rough morning (plus: why does every Rails thread turn into a "you should really try Elixir!" , yeah we don't like our stack to be constantly shat on by Elixir guys)
  - ranyefet 7y ago
    Of course you can throw more servers/caching/database locks, but the advantage of using Elixir & Phoenix is that you can do a lot more with less. Think how much the code would be simpler and easier to reason about without caching. Or reducing the numbers of servers you need from 150 to 2 and with better performance [1] [1] https://www.techworld.com/apps-wearables/how-elixir-helped-bleacher-report-handle-8x-more-traffic-3653957/ https://www.techworld.com/apps-wearables/how-elixir-helped-b...
  - tarsinge 7y ago
    > yeah we don't like our stack to be constantly shat on by Elixir guys) Sorry to be blunt but this is nonsense, languages and stacks are just tools. When I was working on banking systems the idea of using dynamic typed language would have been insane. Now that I’m in a two man’s shop working on low traffic web app I’m happily using Rails for the CRUD work. And if tomorrow I were to work on a public high traffic real-time app like Discord I would do it in Elixir. There is no such thing as your stack.
    - joelbluminator 7y ago
      Usually there's the 1-2 tools you're most comfortable with, unless you're a true generalist. Most people can't be incredible in Rails/Django/Spring/Node/.NET at the same time, you have to pick 1-2 things you excel at. You can be efficient in 5 tools at the same time, but not an expert (for most people. some people are great at everything they put their hands on).
- interactivecode 7y ago
  You seem to have a bunch of experience with Phoenix, could you suggest some tutorials that will be helpful for people who start from scratch learning elixr and this type of development. Coming from a php / node.js background it seems very overwhelming
  - di4na 7y ago
    The default phoenix guide are really good and should be understandable if you come from php. https://hexdocs.pm/phoenix/overview.html https://hexdocs.pm/phoenix/overview.html The default elixir-lang getting started is pretty good. https://elixir-lang.org/getting-started/introduction.html https://elixir-lang.org/getting-started/introduction.html Some people prefer this community one https://elixirschool.com/en/ https://elixirschool.com/en/
  - cpursley 7y ago
    This video course is fantastic: https://pragmaticstudio.com/elixir https://pragmaticstudio.com/elixir
cpursley 7y ago
Can PHP or Rails do websockets or concurrency out of the box? The last Rails app I worked on required lots of glue to make this happen.
- joelbluminator 7y ago
  Well yes of course they do. Any modern web dev stack does concurrency out of the box. In Rails you use a web server like Unicorn if multi process is good enough or puma if you want mutli threads as well. PHP has apache modules that do the same thing.
  - jonesetc 7y ago
    considering their comment about it being difficult with rails, I think they are likely talking about concurrency within a single request as opposed to what I think you are talking about of concurrently handling requests.
    - joelbluminator 7y ago
      Again, that's just very rarely needed. The server is concurrent and if you have very heavy stuff you use background jobs. This doesn't only work for Rails, this is what java, .net, php etc etc are all doing and it works. I'll be interested intellectually to see what Elixir can do but I just don't see how it solves anything that isn't solved already.
      - jonesetc 7y ago
        I'm not preaching the elixir word here either. I've never used it for anything real and just dabbled a bit as a toy. I'm just trying to help get this conversation going because I'm also interested. My experience is in java, node, and python primarily which covers a good bit of ground as far as the different concurrency approaches. Anyhow, your characterization there I don't think is quite right. For one Java does not typically use a background job set up, because it is a first-class multithreaded runtime so it seems more likely prepared to use a threadpool for some concurrent processing before it say tosses things out to a task queue. Similarly as most java web servers are on a thread pool model for concurrency as opposed to async IO, you'll also have true in request concurrency for things like making a few calls to the DB and then collecting them. This thread pool is not well abstracted typically, and the mutable object model leads you to writing classically tricky multithreaded code with data races and the like. For something like node where you are not really likely to be using threads, you are pretty hard tied to async IO as your method of concurrency. So you have a really easy job if all you're doing is async calls to say a DB with no need for data processing. Here once you need real computation you will have essentially no option other than using a task queue. Then when it comes to python you have essentially the worst of all worlds. it's not easy to do concurrent IO or computation without some form of background processing. I believe that when it comes to the elixir runtime the idea is that they have removed async IO from the mix and instead put up a concurrency API that is as simple to manage as async IO in something like node. Under the covers is all delegating out simple blocking code to a thread/process pool, but the immutable data model and API makes it so that data is not shared across the pool, trying to keep the classic concurrent mistakes hard to make. Nothing that can be done in elixir seem to be impossible or even astoundingly hard in some other technology, but the unified API for all forms of concurrency seem like a nice way to make it a runtime that can handle many different types of workloads in a simple and cohesive way. That simple way also seeming to not need you to bring in things like a redis task queue where you generally would need to use it or some other external solution.
ravenstine 7y ago
CRUD is trivial in general, and pretty easy to implement even with the Node.js built-in HTTP library. A more complex API is probably where Rails or Phoenix start to make sense, but there's no reason why an HTTP library and a database aren't enough for basic CRUD. Someone who doesn't see CRUD as fundamentally trivial probably hasn't been programming very long.
- joelbluminator 7y ago
  Well the idea behind Crud is easy but it doesn't mean every crud app is easy. Is Wikipedia or base camp easy to write without a framework?
lfn716 7y ago
I wouldn't say Elixir has more concepts, it is rather different concepts. You also don't have to worry about performance and concurrency. I would actually argue that you have to worry less about performance and concurrency because you can go further without having to resort to cache layers, tuning, etc. But ultimately, I don't disagree with you. If you are building CRUD apps, then any technology is likely fine. Perhaps there is a chance Phoenix will start to take a bigger pie of the "CRUD apps space" with LiveView (https://github.com/phoenixframework/phoenix_live_view https://github.com/phoenixframework/phoenix_live_view). If you could produce CRUD apps at the pace you do today, but making them interactive and realtime is orders of magnitude simpler, would that interest you?

brightball 7y ago

It's understandable. Elixir is one of those languages you won't really appreciate until you've experienced the problems that it addresses. You're getting down voted mostly because of your tone (IMO) but the appeal if Elixir is just a reality of experience. When I found it, I was 15 years in my career and when I dove in, learned it and saw how it addressed so many short term and long term issues that appear in application development...the balance was the closest thing I'd seen to perfect. But if I hadn't experienced the pain, I would never have appreciated it all the little details.

preommr 7y ago
It would be nice if you elaborated on what those problems are and how elixir solves them better than existing alternatives. All I ever see is people exclaiming how awesome it is and then the responses turn out to be underwhelming for various reasons. Like hot reloading isn't that special or unique anymore.
- gregors 7y ago
  I feel like this talk does a great job of answering that question - The Soul of Erlang and Elixir by Saša Jurić (https://www.youtube.com/watch?v=JvBT4XBdoUE https://www.youtube.com/watch?v=JvBT4XBdoUE)
  - preommr 7y ago
    lol, there's the hot reloading. But that's an interesting talk. I didn't have time to go through the whole thing but the core of it seems to be the pros of erlang like BEAM's high concurrency advantages and uniformity of tools running on top of otp. It's an interesting argument.
- brightball 7y ago
  I need to write about it more. The most in depth piece I've written was this one: https://blog.codeship.com/comparing-elixir-go/ https://blog.codeship.com/comparing-elixir-go/ Hot reloading is very unique though (but not necessary for most use cases). There's no other stack outside of the BEAM that has an equivalent. A lot of what is offered by the BEAM isn't even possible in other stacks because it requires a collective of language decisions working together.
joelbluminator 7y ago
Doing this for 7 years, have yet to seen a problem throwing more servers/caching/database locks can't handle. I'm not saying those problems don't exist, I'm just saying it's not that common. Agree about the tone, was having a rough morning (plus: why does every Rails thread turn into a "you should really try Elixir!" , yeah we don't like our stack to be constantly shat on by Elixir guys)
- ranyefet 7y ago
  Of course you can throw more servers/caching/database locks, but the advantage of using Elixir & Phoenix is that you can do a lot more with less. Think how much the code would be simpler and easier to reason about without caching. Or reducing the numbers of servers you need from 150 to 2 and with better performance [1] [1] https://www.techworld.com/apps-wearables/how-elixir-helped-bleacher-report-handle-8x-more-traffic-3653957/ https://www.techworld.com/apps-wearables/how-elixir-helped-b...
- tarsinge 7y ago
  > yeah we don't like our stack to be constantly shat on by Elixir guys) Sorry to be blunt but this is nonsense, languages and stacks are just tools. When I was working on banking systems the idea of using dynamic typed language would have been insane. Now that I’m in a two man’s shop working on low traffic web app I’m happily using Rails for the CRUD work. And if tomorrow I were to work on a public high traffic real-time app like Discord I would do it in Elixir. There is no such thing as your stack.
  - joelbluminator 7y ago
    Usually there's the 1-2 tools you're most comfortable with, unless you're a true generalist. Most people can't be incredible in Rails/Django/Spring/Node/.NET at the same time, you have to pick 1-2 things you excel at. You can be efficient in 5 tools at the same time, but not an expert (for most people. some people are great at everything they put their hands on).
interactivecode 7y ago
You seem to have a bunch of experience with Phoenix, could you suggest some tutorials that will be helpful for people who start from scratch learning elixr and this type of development. Coming from a php / node.js background it seems very overwhelming
- di4na 7y ago
  The default phoenix guide are really good and should be understandable if you come from php. https://hexdocs.pm/phoenix/overview.html https://hexdocs.pm/phoenix/overview.html The default elixir-lang getting started is pretty good. https://elixir-lang.org/getting-started/introduction.html https://elixir-lang.org/getting-started/introduction.html Some people prefer this community one https://elixirschool.com/en/ https://elixirschool.com/en/
- cpursley 7y ago
  This video course is fantastic: https://pragmaticstudio.com/elixir https://pragmaticstudio.com/elixir

cpursley 7y ago

Can PHP or Rails do websockets or concurrency out of the box? The last Rails app I worked on required lots of glue to make this happen.

joelbluminator 7y ago
Well yes of course they do. Any modern web dev stack does concurrency out of the box. In Rails you use a web server like Unicorn if multi process is good enough or puma if you want mutli threads as well. PHP has apache modules that do the same thing.
- jonesetc 7y ago
  considering their comment about it being difficult with rails, I think they are likely talking about concurrency within a single request as opposed to what I think you are talking about of concurrently handling requests.
  - joelbluminator 7y ago
    Again, that's just very rarely needed. The server is concurrent and if you have very heavy stuff you use background jobs. This doesn't only work for Rails, this is what java, .net, php etc etc are all doing and it works. I'll be interested intellectually to see what Elixir can do but I just don't see how it solves anything that isn't solved already.
    - jonesetc 7y ago
      I'm not preaching the elixir word here either. I've never used it for anything real and just dabbled a bit as a toy. I'm just trying to help get this conversation going because I'm also interested. My experience is in java, node, and python primarily which covers a good bit of ground as far as the different concurrency approaches. Anyhow, your characterization there I don't think is quite right. For one Java does not typically use a background job set up, because it is a first-class multithreaded runtime so it seems more likely prepared to use a threadpool for some concurrent processing before it say tosses things out to a task queue. Similarly as most java web servers are on a thread pool model for concurrency as opposed to async IO, you'll also have true in request concurrency for things like making a few calls to the DB and then collecting them. This thread pool is not well abstracted typically, and the mutable object model leads you to writing classically tricky multithreaded code with data races and the like. For something like node where you are not really likely to be using threads, you are pretty hard tied to async IO as your method of concurrency. So you have a really easy job if all you're doing is async calls to say a DB with no need for data processing. Here once you need real computation you will have essentially no option other than using a task queue. Then when it comes to python you have essentially the worst of all worlds. it's not easy to do concurrent IO or computation without some form of background processing. I believe that when it comes to the elixir runtime the idea is that they have removed async IO from the mix and instead put up a concurrency API that is as simple to manage as async IO in something like node. Under the covers is all delegating out simple blocking code to a thread/process pool, but the immutable data model and API makes it so that data is not shared across the pool, trying to keep the classic concurrent mistakes hard to make. Nothing that can be done in elixir seem to be impossible or even astoundingly hard in some other technology, but the unified API for all forms of concurrency seem like a nice way to make it a runtime that can handle many different types of workloads in a simple and cohesive way. That simple way also seeming to not need you to bring in things like a redis task queue where you generally would need to use it or some other external solution.

ravenstine 7y ago

CRUD is trivial in general, and pretty easy to implement even with the Node.js built-in HTTP library. A more complex API is probably where Rails or Phoenix start to make sense, but there's no reason why an HTTP library and a database aren't enough for basic CRUD. Someone who doesn't see CRUD as fundamentally trivial probably hasn't been programming very long.

joelbluminator 7y ago
Well the idea behind Crud is easy but it doesn't mean every crud app is easy. Is Wikipedia or base camp easy to write without a framework?

lfn716 7y ago

I wouldn't say Elixir has more concepts, it is rather different concepts. You also don't have to worry about performance and concurrency. I would actually argue that you have to worry less about performance and concurrency because you can go further without having to resort to cache layers, tuning, etc. But ultimately, I don't disagree with you. If you are building CRUD apps, then any technology is likely fine. Perhaps there is a chance Phoenix will start to take a bigger pie of the "CRUD apps space" with LiveView (https://github.com/phoenixframework/phoenix_live_view https://github.com/phoenixframework/phoenix_live_view). If you could produce CRUD apps at the pace you do today, but making them interactive and realtime is orders of magnitude simpler, would that interest you?