6 ms·

> José: Why did you choose Elixir? > Steve: We chose Elixir because we were looking for a system that was easy for programmers to understand and could take bet

> José: Why did you choose Elixir? > Steve: We chose Elixir because we were looking for a system that was easy for programmers to understand and could take better advantage of our servers. I was intrigued at Elixir’s combination of friendly syntax, powerful metaprogramming features, and incorporation of the Actor model. Am I wrong or is this guy in some sort of bubble where only functional languages are taught?

capableweb 3y ago
You seem to be wrong, at least based on the quote you chose to use here, as Steve doesn't even mention anything related to functional programming?
- kramerger 3y ago
  Elixir is a functional language for the Erlang VM. Most C++/Java/Rust/... programmers wpuld have hard time understanding it. But if you are in a bubble where everyone uses Haskell and talks about Monads, then OPs statement may be valid
  - yesco 3y ago
    I think Elixir is closer to an easier to read Lisp than to Haskell. In fact if someone claimed to know Rust, but couldn't figure out Elixir then I'd simply assume they were lying about their Rust experience.
  - capableweb 3y ago
    Monads and Haskell is not a requirement to understand a functional programming language. Also, I find it hard to believe that anyone who knows N+1 programming languages would have a hard time understanding Elixir quickly, it looks like most mainstream programming languages used today, with slightly different syntax for some things. Take a look at https://elixir-lang.org/crash-course.html https://elixir-lang.org/crash-course.html and you'll see what I mean, it's basically Ruby with some slight modifications.
    - arrowsmith 3y ago
      As much as I love Elixir, it's really not just "basically Ruby with some slight modifications". The syntax is similar at a glance, but there are some major design differences (e.g. immutability); solving the same problem in Elixir and Ruby can require a completely different structure to your code. I wrote this blog post about what I think are the three most important differences between Elixir and Ruby: https://phoenixonrails.com/blog/elixir-for-ruby-developers-the-three-most-important-differences https://phoenixonrails.com/blog/elixir-for-ruby-developers-t... . There's definitely a learning curve, although it's not insurmountable.
      - skrebbel 3y ago
        No monads though. No pure functions, no Option types, pretty much no recursion in practice. Really it’s got none of the stuff that makes some FP languages hard to learn. (Except maybe “no for loops”).
        arrowsmith 3y ago
        That's true - Elixir is simpler to learn than, say, Haskell. All I'm saying is that it's not a trivial jump from Elixir to Ruby, despite the superficially similar syntax.
        skrebbel 3y ago
        I don’t think eg ruby->go is a bigger jump. Learn defer, structural typing, interfaces vs learn to replace all loops with map/filter/etc + pattern matching. Feels similar, no?
    - GrinningFool 3y ago
      > it's basically Ruby with some slight modifications. It /looks/ like Ruby in a lot of ways, but treating it like Ruby w/ modifications is a mistake that I've seen lead to a lot of really bad usage that (at best) fails to take advantage of the underlying Beam VM, and at worst [and more commonly] actively works against it.
  - AlchemistCamp 3y ago
    I picked it up pretty quickly as primarily a JS dev at the time. I’ve also worked on several projects where I’ve pair programmed with a dev new to the language. They’re usually pretty productive within a few days. Not writing their own DSLs or going deep into OTP, but productive in terms of writing application code. Phoenix is pretty straightforward for those who have experience with Rails, Laravel or a similar full-stack web framework.
  - moomoo11 3y ago
    Don’t forget having to know beam and erlang especially if post junior/intern level where it’s more than just “it looks like ruby”
    - cpursley 3y ago
      I’ve used Elixir for half a decade and never had to dig into Erlang.
  - pessimizer 3y ago
    Rust screams Erlang influence, but maybe it's just me. IIRC, in the beginning they even tried to put in a green threading VM for tail calls, which seems insane for something that you want to be a systems language.
    - steveklabnik 3y ago
      Early Rust was pretty expressly influenced by Erlang. The green threading runtime was removed in 2014, shortly before the 1.0.0 release in May 2015. The reason for the waning influence was exactly that: couldn’t be reconciled with systems use cases effectively.
    - sph 3y ago
      Native green threading instead of async/await would have made for a much more pleasant to use Rust language IMO. I hate async/await with a passion.
troupo 3y ago
Elixir and Erlang are functional, but not in the Haskell sense. They are pragmatic languages that prefer results over theory and purity.
varispeed 3y ago
If I didn't know the context, I'd think this is a troll comment. I bought a book about Elixir and genuinely tried to learn it, but noped out quickly as in I find programs written in it to be unworkable mess quickly. It's like Perl on crack.
jatins 3y ago
I like Elixir as much as any other guy but I am not going to chose it for my team because it was "easy for programmers to understand" If you wanted something that was easy you'd go got Golang or Java, not a language without types. Lots of reasons to love Elixir but this doesn't sound like one
- cpursley 3y ago
  Java is an order of magnitude more difficult to learn vs. Elixir. Especially in the context of Java web frameworks.
- weatherlight 3y ago
  I think dynamic langs are easier to pick up than statically typed ones. But thats just me, I guess.
  - IshKebab 3y ago
    Easier to pick up, harder to use. A spade is easier to pick up than a digger, but try digging foundations with a spade.
    - weatherlight 3y ago
      Is it though? I've been using dynamic langs my entire career, and static ones too! I feel like statically typed langs, (I'm looking at you Java), are a bit more stubborn to work with, especially around API design, prototyping, greenfield stuff. I do like langs like Haskell and Standard ML where they are statically typed, the the type system is mathematically sounds, and the types are inferred. I want my type system to be inferred and bomb proof or to just get out of the way. Its the best of both world.
      - IshKebab 3y ago
        Static typing has huge advantages over dynamic: * Reading and understanding code is much easier because the types are written down. You spend much less time figuring out what variables can contain. * Navigating code is much faster because tools like go-to-definition, code completion and find-all-references work reliably * Refactoring code is a lot easier - or in large projects actually tractable. In large dynamically typed projects something as simple as renaming a variable can be an impossible task. * Obviously the one people talk about most is catching bugs. The degree it does that depends on how strong the typing is (e.g. Rust will catch many more bugs than Java). But they will all catch the embarrassing things that dynamic languages can't like typos and missing arguments. If you've only ever written short greenfield projects you might not appreciate some of these benefits as much as you should because you wrote all the code yourself so all the details are still in your head. It's a bit like saying seatbelts are an unnecessary pain because you haven't ever been in a crash. > types are inferred Some local type inference is good, but Haskell / ML style global type inference is kind of the worse of both worlds. You have to satisfy the type checker, which is harder because global solver errors are always harder, and you don't get the documentation benefits of static types because the inferred type is frequently a generic type. Rust went with local type inference only for very good reasons.

capableweb 3y ago

You seem to be wrong, at least based on the quote you chose to use here, as Steve doesn't even mention anything related to functional programming?

kramerger 3y ago
Elixir is a functional language for the Erlang VM. Most C++/Java/Rust/... programmers wpuld have hard time understanding it. But if you are in a bubble where everyone uses Haskell and talks about Monads, then OPs statement may be valid
- yesco 3y ago
  I think Elixir is closer to an easier to read Lisp than to Haskell. In fact if someone claimed to know Rust, but couldn't figure out Elixir then I'd simply assume they were lying about their Rust experience.
- capableweb 3y ago
  Monads and Haskell is not a requirement to understand a functional programming language. Also, I find it hard to believe that anyone who knows N+1 programming languages would have a hard time understanding Elixir quickly, it looks like most mainstream programming languages used today, with slightly different syntax for some things. Take a look at https://elixir-lang.org/crash-course.html https://elixir-lang.org/crash-course.html and you'll see what I mean, it's basically Ruby with some slight modifications.
  - arrowsmith 3y ago
    As much as I love Elixir, it's really not just "basically Ruby with some slight modifications". The syntax is similar at a glance, but there are some major design differences (e.g. immutability); solving the same problem in Elixir and Ruby can require a completely different structure to your code. I wrote this blog post about what I think are the three most important differences between Elixir and Ruby: https://phoenixonrails.com/blog/elixir-for-ruby-developers-the-three-most-important-differences https://phoenixonrails.com/blog/elixir-for-ruby-developers-t... . There's definitely a learning curve, although it's not insurmountable.
    - skrebbel 3y ago
      No monads though. No pure functions, no Option types, pretty much no recursion in practice. Really it’s got none of the stuff that makes some FP languages hard to learn. (Except maybe “no for loops”).
      - arrowsmith 3y ago
        That's true - Elixir is simpler to learn than, say, Haskell. All I'm saying is that it's not a trivial jump from Elixir to Ruby, despite the superficially similar syntax.
        skrebbel 3y ago
        I don’t think eg ruby->go is a bigger jump. Learn defer, structural typing, interfaces vs learn to replace all loops with map/filter/etc + pattern matching. Feels similar, no?
  - GrinningFool 3y ago
    > it's basically Ruby with some slight modifications. It /looks/ like Ruby in a lot of ways, but treating it like Ruby w/ modifications is a mistake that I've seen lead to a lot of really bad usage that (at best) fails to take advantage of the underlying Beam VM, and at worst [and more commonly] actively works against it.
- AlchemistCamp 3y ago
  I picked it up pretty quickly as primarily a JS dev at the time. I’ve also worked on several projects where I’ve pair programmed with a dev new to the language. They’re usually pretty productive within a few days. Not writing their own DSLs or going deep into OTP, but productive in terms of writing application code. Phoenix is pretty straightforward for those who have experience with Rails, Laravel or a similar full-stack web framework.
- moomoo11 3y ago
  Don’t forget having to know beam and erlang especially if post junior/intern level where it’s more than just “it looks like ruby”
  - cpursley 3y ago
    I’ve used Elixir for half a decade and never had to dig into Erlang.
- pessimizer 3y ago
  Rust screams Erlang influence, but maybe it's just me. IIRC, in the beginning they even tried to put in a green threading VM for tail calls, which seems insane for something that you want to be a systems language.
  - steveklabnik 3y ago
    Early Rust was pretty expressly influenced by Erlang. The green threading runtime was removed in 2014, shortly before the 1.0.0 release in May 2015. The reason for the waning influence was exactly that: couldn’t be reconciled with systems use cases effectively.
  - sph 3y ago
    Native green threading instead of async/await would have made for a much more pleasant to use Rust language IMO. I hate async/await with a passion.

troupo 3y ago

Elixir and Erlang are functional, but not in the Haskell sense. They are pragmatic languages that prefer results over theory and purity.

varispeed 3y ago

If I didn't know the context, I'd think this is a troll comment. I bought a book about Elixir and genuinely tried to learn it, but noped out quickly as in I find programs written in it to be unworkable mess quickly. It's like Perl on crack.

jatins 3y ago

I like Elixir as much as any other guy but I am not going to chose it for my team because it was "easy for programmers to understand" If you wanted something that was easy you'd go got Golang or Java, not a language without types. Lots of reasons to love Elixir but this doesn't sound like one

cpursley 3y ago
Java is an order of magnitude more difficult to learn vs. Elixir. Especially in the context of Java web frameworks.
weatherlight 3y ago
I think dynamic langs are easier to pick up than statically typed ones. But thats just me, I guess.
- IshKebab 3y ago
  Easier to pick up, harder to use. A spade is easier to pick up than a digger, but try digging foundations with a spade.
  - weatherlight 3y ago
    Is it though? I've been using dynamic langs my entire career, and static ones too! I feel like statically typed langs, (I'm looking at you Java), are a bit more stubborn to work with, especially around API design, prototyping, greenfield stuff. I do like langs like Haskell and Standard ML where they are statically typed, the the type system is mathematically sounds, and the types are inferred. I want my type system to be inferred and bomb proof or to just get out of the way. Its the best of both world.
    - IshKebab 3y ago
      Static typing has huge advantages over dynamic: * Reading and understanding code is much easier because the types are written down. You spend much less time figuring out what variables can contain. * Navigating code is much faster because tools like go-to-definition, code completion and find-all-references work reliably * Refactoring code is a lot easier - or in large projects actually tractable. In large dynamically typed projects something as simple as renaming a variable can be an impossible task. * Obviously the one people talk about most is catching bugs. The degree it does that depends on how strong the typing is (e.g. Rust will catch many more bugs than Java). But they will all catch the embarrassing things that dynamic languages can't like typos and missing arguments. If you've only ever written short greenfield projects you might not appreciate some of these benefits as much as you should because you wrote all the code yourself so all the details are still in your head. It's a bit like saying seatbelts are an unnecessary pain because you haven't ever been in a crash. > types are inferred Some local type inference is good, but Haskell / ML style global type inference is kind of the worse of both worlds. You have to satisfy the type checker, which is harder because global solver errors are always harder, and you don't get the documentation benefits of static types because the inferred type is frequently a generic type. Rust went with local type inference only for very good reasons.