6 ms·

Non-representative anecdote : i've recently heard of two teams that started using elixir, they both came from a ruby background, and in both case they weren't u

by bsaul 9y ago

Non-representative anecdote : i've recently heard of two teams that started using elixir, they both came from a ruby background, and in both case they weren't using OTP. They both justified using elixir because it was "closer to ruby" (???), and they both seemed to live a pretty difficult time with that language. Which makes me wonder : why would you ever want to use such a special language (purely functional isn't for everyone) if you don't have any scalability issue, and don't even use OTP ?

gfiorav 9y ago
People usually dive into Elixir expecting Ruby, but it’s a very different language. Most of this confusion comes from not wanting to sit down and read a good book about it. The only thing it takes from Ruby is variable and namespace naming (since José Valim was a ruby syntax enthusiast). Ruby syntax is good IMHO, but that’s not the only reason to go for Elixir (far from it). I recommend the book “Programming Elixir”. Even if you end up not picking the language, it makes a good point about how OOP is a natural enemy to concurrency (because of state) and about how transforming data (I.e functional) is a better match. The language runs atop the Erlang VM, which successfully navigated the troubles of concurrency in ISP nodes a long time ago. Again, worth a read.
jeremyjh 9y ago
There is a significant learning curve, but anyone can learn it. It is not much like Ruby, yet it captures much of the joy of programming in Ruby and is far better for structuring large programs. There is optional typing support through Dialyzer, but even without that the compiler will catch many mistakes that annoy me and slow down development in Ruby. Also - the performance can really make a perceptible difference in user experience even if you don't "need" the scalability.
iaml 9y ago
I'm guessing what they really meant is "it's close to rails" since the same people made both rails and phoenix AFAIK.
- dudul 9y ago
  Some of the main contributors - starting with J Valim - were core ruby contributors I think.
  - jmcgough 9y ago
    rails contributors actually, the core ruby contributors are all japanese afaik
fabian2k 9y ago
Are those web applications? If they're using Phoenix, they are also using OTP under the hood, but they don't have to use it directly.
- benwilson-512 9y ago
  To elaborate on this a "traditional" stack of Phoenix for the web and and Ecto for the DB uses quite a bit of OTP, particularly if websockets are involved (every connection is a GenServer). The thing is, going from Ruby to Elixir involves two learning curves: groking functional programming, and then groking processes. They really do need to be learned in that order since, within any given process, you're just operating in a relatively normal functional world. HTTP requests are very easily envisioned in a simple functional way. You've got request data in, and you're gonna return response data. The interaction you have along the way with OTP based database pools and so forth is as a client, you aren't really having to manage the lifecycle of any of that stuff. In other words to get going with basic web stuff it's more critical to just become familiar with functional programming, and less critical to understand how OTP works. This is totally fine from a learning curve perspective. What's cool about Phoenix channels though is that each user's connection, and each channel that they run is a GenServer. It provides a great opportunity to get some hands on interaction with the concept in a way that naturally fits into with the web application they're building. TL;DR:You can be a client / user of OTP processes without knowing the details of how they work, and that's generally enough for HTTP.
  - conradfr 9y ago
    I did (i.e paid) the Pragmatic Studio course and a large part is making a project that mimics a HTTP server and I find it a great way to discover functional programming and pattern matching (doesn't touch Phoenix though).
dudul 9y ago
I've seen a few (as in 2 ;) ) examples of this myself. And this is what "scares" me the most for elixir's future/potential. I think it's a great language/tech but ruby enthusiasts rushing into it thinking that it's "just like ruby but faster" may have a very bad influence on where the language goes. They may bring a lot of ruby best practices that don't transpose at all in elixir/erlang world.
- bsaul 9y ago
  That was indeed my underlying point. I see elixir more as "erlang with easier syntax", than "ruby with a more powerful runtime". aka : you should get to understand erlang design decisions prior to jumping into the tech. Which probably means having more experience than building the typical low load website made with RoR.
  - sotojuan 9y ago
    We already had a ton of Rails devs who didn't know Ruby or OOP well. If Elixir becomes very popular, we will have Elixir devs that don't know OTP, functional programming (outside of pure functions/immutability), or Erlang. That's the way it goes.
  - pmontra 9y ago
    I'm in the fourth month of a Phoenix project, which shields me from almost all of OTP, and I agree with your point. Maybe even "Erlang with a Ruby syntax" would be too much. Similarities with Ruby don't go any further than "def" "do" "end" and many library modules and functions deliberately named to mimic corresponding modules and methods in Ruby. Everything else is different, both syntax and semantic. After 10 years of Rails, all things considered Elixir and Phoenix are pretty good. The best feature of the language so far is pattern matching. It can be used in the arguments of function definitions. It makes all the "if"s go away. It seems strange after 30 years of programming, but a program without conditionals is easier to read. Not having to use an external background job framework is great news too. Just spawn your processes to send a mail, process something asynchronously and store the result in the database. No Sidekiq (or Celery if you're into Python.) On the awful side, Ecto is too low level and it feels like a self inflicted pain. I understand the reasons behind its design decisions, but the typical web application or mobile backend don't need all of that. Actually the team working with me on this project wrote a lot of code to build queries and wrap them into another layer to return {:ok, result} / {:error, reason} tuples. We're calling them from controllers more or less as Model.get_something(args). I checked it now and we have zero occurrences of " from " in controller code. All the queries are confined inside a model. If we were using Rails ActiveRecord would have written all that code for us. Instead we had to use a more verbose query syntax, write our functions and tests. This is a net loss of productivity. There are some modules that can be mounted on the top of Ecto to make it look like ActiveRecord or other ORMs for other languages. I'm looking forward to using Ecto.Rut in my next project. I hope I'll never have to use Ecto directly. https://github.com/sheharyarn/ecto_rut https://github.com/sheharyarn/ecto_rut We almost didn't use the supervisor layer of the language (somewhat like systemd/init for who's not familiar with it.) I used it in smaller projects and I feel like it's a little too complicated. Same for defining a GenServer, more complex and verbose than exposing the same functionality with methods from a object. I know we have to split the code between what runs in the client process and what runs on the server process, but I feel there should be a vanilla GenServer that handles the most straightfoward case inside the behavior, which is no code in the client with the exception of passing the arguments to the server. Maybe use the name, sigils or module attributes to declare if there will be a synchronous return value. Anyway, Elixir is still young and there is time to smooth the rough edges. So far it's an acceptable contender and definitely better than the popular scripting languages when concurrency is important.
lojack 9y ago
I worked on a project that used elixir without OTP. There’s a lot of nice things that elixir gives you and I didn’t personally feel like there was a significant learning curve. OTP is used under the hood for lots of analytics and reporting things, but those pieces were built by other people. The project I was working on had very specific requirements for response times that simply weren’t realistic with Ruby. We could have squeezed Ruby a bit to get what we needed, but it would have introduced complexity. We also knew we’d need to add features in the future while maintaining the same performance, so siding with the simpler solution made more sense to us. At some point in the near future we’ll probably use OTP, and I’ve already got a few ideas of how we’ll be leveraging it for some of our upcoming features. OTP is the killer feature, but I find working with elixir in general to be a very pleasant experience even on projects that don’t use it.
karmajunkie 9y ago
I don't know if I'd move a project without scalability issues (and that's an important caveat) to Elixir purely based on the language facilities like pattern matching, but I'd definitely start one with it. Pattern matching alone is something I feel the lack of every time I get into a Ruby project these days. For a project where scalability is a concern, I'd have no qualms about moving it over. At the very least I'd carve out the slices which most impact performance and implement them in Elixir and deal with the PITA of having two app servers. In a real world project with these kinds of issues I've seen some pretty huge improvements by doing this piece by piece.
jetti 9y ago
>they both came from a ruby background, That seems to be the case with the majority of vocal (i.e hosting or being on podcasts) people who use Elixir. In a sense, I'm lucky since I came from a C# background and don't have to worry about doing things the "Ruby Way" instead of the "Elixir way". >why would you ever want to use such a special language (purely functional isn't for everyone) if you don't have any scalability issue, and don't even use OTP ? There are a few reasons. One being the hype train that has surrounded the language over the past year+ (at least that's when I noticed it gaining steam). Another reason is that they just don't know enough to get into OTP. Elixir is still young and there is a lot of OTP functionality that isn't represented in Elixir that you need to drop down to Erlang to use. Erlang is not the prettiest of languages and has its own learning curve as well. I think eventually the teams that you heard of will get to OTP as get more familiar with the language.

by bsaul 9y ago

gfiorav 9y ago

People usually dive into Elixir expecting Ruby, but it’s a very different language. Most of this confusion comes from not wanting to sit down and read a good book about it. The only thing it takes from Ruby is variable and namespace naming (since José Valim was a ruby syntax enthusiast). Ruby syntax is good IMHO, but that’s not the only reason to go for Elixir (far from it). I recommend the book “Programming Elixir”. Even if you end up not picking the language, it makes a good point about how OOP is a natural enemy to concurrency (because of state) and about how transforming data (I.e functional) is a better match. The language runs atop the Erlang VM, which successfully navigated the troubles of concurrency in ISP nodes a long time ago. Again, worth a read.

jeremyjh 9y ago

There is a significant learning curve, but anyone can learn it. It is not much like Ruby, yet it captures much of the joy of programming in Ruby and is far better for structuring large programs. There is optional typing support through Dialyzer, but even without that the compiler will catch many mistakes that annoy me and slow down development in Ruby. Also - the performance can really make a perceptible difference in user experience even if you don't "need" the scalability.

iaml 9y ago

I'm guessing what they really meant is "it's close to rails" since the same people made both rails and phoenix AFAIK.

dudul 9y ago
Some of the main contributors - starting with J Valim - were core ruby contributors I think.
- jmcgough 9y ago
  rails contributors actually, the core ruby contributors are all japanese afaik

fabian2k 9y ago

Are those web applications? If they're using Phoenix, they are also using OTP under the hood, but they don't have to use it directly.

benwilson-512 9y ago
To elaborate on this a "traditional" stack of Phoenix for the web and and Ecto for the DB uses quite a bit of OTP, particularly if websockets are involved (every connection is a GenServer). The thing is, going from Ruby to Elixir involves two learning curves: groking functional programming, and then groking processes. They really do need to be learned in that order since, within any given process, you're just operating in a relatively normal functional world. HTTP requests are very easily envisioned in a simple functional way. You've got request data in, and you're gonna return response data. The interaction you have along the way with OTP based database pools and so forth is as a client, you aren't really having to manage the lifecycle of any of that stuff. In other words to get going with basic web stuff it's more critical to just become familiar with functional programming, and less critical to understand how OTP works. This is totally fine from a learning curve perspective. What's cool about Phoenix channels though is that each user's connection, and each channel that they run is a GenServer. It provides a great opportunity to get some hands on interaction with the concept in a way that naturally fits into with the web application they're building. TL;DR:You can be a client / user of OTP processes without knowing the details of how they work, and that's generally enough for HTTP.
- conradfr 9y ago
  I did (i.e paid) the Pragmatic Studio course and a large part is making a project that mimics a HTTP server and I find it a great way to discover functional programming and pattern matching (doesn't touch Phoenix though).

dudul 9y ago

I've seen a few (as in 2 ;) ) examples of this myself. And this is what "scares" me the most for elixir's future/potential. I think it's a great language/tech but ruby enthusiasts rushing into it thinking that it's "just like ruby but faster" may have a very bad influence on where the language goes. They may bring a lot of ruby best practices that don't transpose at all in elixir/erlang world.

bsaul 9y ago
That was indeed my underlying point. I see elixir more as "erlang with easier syntax", than "ruby with a more powerful runtime". aka : you should get to understand erlang design decisions prior to jumping into the tech. Which probably means having more experience than building the typical low load website made with RoR.
- sotojuan 9y ago
  We already had a ton of Rails devs who didn't know Ruby or OOP well. If Elixir becomes very popular, we will have Elixir devs that don't know OTP, functional programming (outside of pure functions/immutability), or Erlang. That's the way it goes.
- pmontra 9y ago
  I'm in the fourth month of a Phoenix project, which shields me from almost all of OTP, and I agree with your point. Maybe even "Erlang with a Ruby syntax" would be too much. Similarities with Ruby don't go any further than "def" "do" "end" and many library modules and functions deliberately named to mimic corresponding modules and methods in Ruby. Everything else is different, both syntax and semantic. After 10 years of Rails, all things considered Elixir and Phoenix are pretty good. The best feature of the language so far is pattern matching. It can be used in the arguments of function definitions. It makes all the "if"s go away. It seems strange after 30 years of programming, but a program without conditionals is easier to read. Not having to use an external background job framework is great news too. Just spawn your processes to send a mail, process something asynchronously and store the result in the database. No Sidekiq (or Celery if you're into Python.) On the awful side, Ecto is too low level and it feels like a self inflicted pain. I understand the reasons behind its design decisions, but the typical web application or mobile backend don't need all of that. Actually the team working with me on this project wrote a lot of code to build queries and wrap them into another layer to return {:ok, result} / {:error, reason} tuples. We're calling them from controllers more or less as Model.get_something(args). I checked it now and we have zero occurrences of " from " in controller code. All the queries are confined inside a model. If we were using Rails ActiveRecord would have written all that code for us. Instead we had to use a more verbose query syntax, write our functions and tests. This is a net loss of productivity. There are some modules that can be mounted on the top of Ecto to make it look like ActiveRecord or other ORMs for other languages. I'm looking forward to using Ecto.Rut in my next project. I hope I'll never have to use Ecto directly. https://github.com/sheharyarn/ecto_rut https://github.com/sheharyarn/ecto_rut We almost didn't use the supervisor layer of the language (somewhat like systemd/init for who's not familiar with it.) I used it in smaller projects and I feel like it's a little too complicated. Same for defining a GenServer, more complex and verbose than exposing the same functionality with methods from a object. I know we have to split the code between what runs in the client process and what runs on the server process, but I feel there should be a vanilla GenServer that handles the most straightfoward case inside the behavior, which is no code in the client with the exception of passing the arguments to the server. Maybe use the name, sigils or module attributes to declare if there will be a synchronous return value. Anyway, Elixir is still young and there is time to smooth the rough edges. So far it's an acceptable contender and definitely better than the popular scripting languages when concurrency is important.

lojack 9y ago

I worked on a project that used elixir without OTP. There’s a lot of nice things that elixir gives you and I didn’t personally feel like there was a significant learning curve. OTP is used under the hood for lots of analytics and reporting things, but those pieces were built by other people. The project I was working on had very specific requirements for response times that simply weren’t realistic with Ruby. We could have squeezed Ruby a bit to get what we needed, but it would have introduced complexity. We also knew we’d need to add features in the future while maintaining the same performance, so siding with the simpler solution made more sense to us. At some point in the near future we’ll probably use OTP, and I’ve already got a few ideas of how we’ll be leveraging it for some of our upcoming features. OTP is the killer feature, but I find working with elixir in general to be a very pleasant experience even on projects that don’t use it.

karmajunkie 9y ago

I don't know if I'd move a project without scalability issues (and that's an important caveat) to Elixir purely based on the language facilities like pattern matching, but I'd definitely start one with it. Pattern matching alone is something I feel the lack of every time I get into a Ruby project these days. For a project where scalability is a concern, I'd have no qualms about moving it over. At the very least I'd carve out the slices which most impact performance and implement them in Elixir and deal with the PITA of having two app servers. In a real world project with these kinds of issues I've seen some pretty huge improvements by doing this piece by piece.

jetti 9y ago

>they both came from a ruby background, That seems to be the case with the majority of vocal (i.e hosting or being on podcasts) people who use Elixir. In a sense, I'm lucky since I came from a C# background and don't have to worry about doing things the "Ruby Way" instead of the "Elixir way". >why would you ever want to use such a special language (purely functional isn't for everyone) if you don't have any scalability issue, and don't even use OTP ? There are a few reasons. One being the hype train that has surrounded the language over the past year+ (at least that's when I noticed it gaining steam). Another reason is that they just don't know enough to get into OTP. Elixir is still young and there is a lot of OTP functionality that isn't represented in Elixir that you need to drop down to Erlang to use. Erlang is not the prettiest of languages and has its own learning curve as well. I think eventually the teams that you heard of will get to OTP as get more familiar with the language.