7 ms·

Some random thoughts and impressions: I had not even heard of Elixir till the Phoenix framework hit 1.0 about a month ago, and right now I'm very seriously con

by yumraj 11y ago

Some random thoughts and impressions: I had not even heard of Elixir till the Phoenix framework hit 1.0 about a month ago, and right now I'm very seriously considering Elixir/Phoenix for my next startup and have been slowly learning/hacking in it. I come from C/C++ background, so the syntax was different as it is more Ruby-ish, but still very easy to grok. I've been looking at golang as my next language, but I think Elixir is even more simpler that it. Of all the functional languages that I've tried to get into in the past, this has the most approachable syntax, and I can see things like pattern matching helping a lot with code maintainability. The performance, from whatever I've seen and the limited benchmarks that are out there, it compares extremely well with JVM, Node and Go. Erlang/OTP brings fault tolerance, Phoenix/Ecto etc. have been very productive, community is awesome and helpful. Erlang tooling, such as observer, is awesome and I don't think we have anything similar in golang, though I could be wrong. Dializer helps with type checking. The one thing missing is lack of a enterprise sponsor, and also number of potential hires which can be risky for startups, but on the other hand people interested in working in elixir could be an interesting hiring filter ;)

smt88 11y ago
To be honest with you, "for my next startup" strikes me as the absolute worst time to use a language/platform that is both new to you and new to the industry. Delays kill startups, and that just begs for delays. You have to learn the language. All your new engineers have to learn it. You'll inevitably be (re)inventing the wheel because Elixir isn't in production at thousands of companies already. Picking a shitty, slow language, as long as it's a popular one (JavaScript, Java, C#, PHP, Python), is going to have a much better cost/benefit profile.
- pgz 11y ago
  It really depends on the startup. For some form of chat application or distributed system he will find himself reinventing less compared to the competition. Would be a great way to beat the averages :)
- yumraj 11y ago
  Yes, you're absolutely right. Which is why I'm extremely conflicted right now. I definitely like what I'm seeing with Elixir/Phoenix, but should I take the risk or not is a really tough question. It is performant and fault tolerant, so for a startup if that means it can reduce our operational, and support, cost that itself would be a huge win. Deployment seems straight forward, much much simpler than what I had to do with a Rails app that I was experimenting with. Go deployment would be easier, but Elixir seems at worst to be inline with Play/Java (running under Play and not tomcat). There is a huge set of libraries should I need to venture outside Elixir and into Erlang, and moreover I think (not 100% sure) that Erlang can easily call into other language libraries which might come in handy. The way I'm looking at it is implementing small examples in a couple of other options, such as Nodejs/Loopback and Java/Play and then comparing them. So far Elixir/Phoenix seems straightforward and productive, but still evaluating. However, even if Elixir/Phoenix is the best thing since sliced bread, hiring and training is indeed going to be an issue so I've been trying to figure out how to solve than conundrum.
  - rz2k 11y ago
    One counter point is the "Python Paradox"[1], though I don't know how well that conjecture was ever actually supported. However, isn't the Elixir/OTP ecosphere considered relatively practical and tested, rather than just esoteric or purist, even if it is new? [1] http://www.paulgraham.com/pypar.html http://www.paulgraham.com/pypar.html
    - simoncion 11y ago
      I can't speak to Elixir/OTP, as I've not -yet- used Elixir. However, every time I've gone to use something in the Erlang/OTP standard library [0] it has always been far less complicated and far more well designed than I feared it was going to be. Maybe this is a reflection of my pessimism, but I feel that it is actually a reflection of the quality of the software. :) [0] Yes, I know that Elixir is a BEAM language and -as such- has access to both Erlang and OTP, so this distinction is terribly fine. ;)
    - smt88 11y ago
      When PG says "smarter engineers", it isn't a given that there are more of them or that it matters that they're smart. Many startups don't need top-tier engineers. They need productive, numerous engineers, especially at the beginning when hiring anyone is difficult (let alone someone good).
- sinatra 11y ago
  > Picking a shitty, slow language, as long as it's a popular one (JavaScript, Java, C#, PHP, Python), is going to have a much better cost/benefit profile. Although, keep in mind that a startup is going to be a roller coaster ride for years. You'll have days when you get tired of writing financial models for investors, or when an angry email from a customer ruins your mood, or you hit a road-block with a UI that just doesn't feel right. You'll want to take a break from all that by going back to just writing code for a day or two. At that point, you will want to get pleasure out coding. I'll be very unhappy if after those kind of days, I try to find solace in coding, and I see PHP, JavaScript or Java staring back at me. Compared to the years it takes to turn a startup successful, the time needed to learn a new language well enough is negligible. I knew just basic Ruby when I switched to Ruby + Sinatra from Java for my new startup. Now, three years later, I can't be happier I made the switch.
  - smt88 11y ago
    Failing fast isn't easy if you're also learning a new language. You want to go from zero to product as soon as possible, and that means using a language you already know like the back of your hand, even if that language sucks.
    - sinatra 11y ago
      Not necessarily. I don't go from zero to product till I have verified that there's a need for the product. I try to fail fast before developing the product. By the time I'm developing the product, I'm fairly certain it's not going to fail immediately after launch. Oh, and once you've built a product that people are using and you're going after growth, you would rarely get a chance to switch languages or frameworks. So, then, you're stuck with the language that you don't even like anymore for many years. I think you're also over-estimating the time required to learn a new language to be good enough for most startups. I understand that there are some areas where language mastery will be tremendous benefit. In that case, I agree that switching languages may not be such a good idea. But, that's a special case, IMHO.
    - MCRed 11y ago
      For your first couple programming languages, it's intimidating to learn a new language. Once you're experienced, though, you discover that its easy and quick to pick up new languages. Because my experience is, as I related above, even though I was learning elixir (for real, I had dabbled with it before) an building a team from scratch, we delivered a product extremely fast.... because we chose elixir. It doesn't matter how well you know java, the language is going to slow down your development dramatically... at lest compared to Elixir (and maybe go.)
- lectrick 11y ago
  I worked for thredup.com when it was brand-new and we used Rails when it was still fairly new and we had a pretty good time all things considered. You just have to be a capable programmer. ;)
- keithwhor 11y ago
  Since when is JavaScript (V8) slow? Is it 2006? :)
  - smt88 11y ago
    That list of languages was "popular" rather than "shitty and slow", although some of them certainly are shitty (and dynamic languages do tend to be kinda slow). I realize my phrasing was confusing.
- vikeri 11y ago
  I do not agree, I have worked for a year on a startup using Clojure(Script) and I hadn't touched Clojure before. Never looked back and did not encounter any major issues springing from the choice of language. To the contrary, I have really enjoyed not having to deal with the disadvatages of older languages. The issue could possibly be in hiring, if the supply of Elixir-developers would be scarce.
- perishabledave 11y ago
  Kind of, since Elixir runs on the Erlang VM and it uses much of Erlang's libraries (e.g. OTP) I'd argue that you can look at Erlang's track record for Elixir's.
- MCRed 11y ago
  Nope. And I have real world experience to contradict that. Last year started a project with elixir, about 8 months before elixir hit 1.0. Despite starting with me and another engineer we both built a team, taught them elixir (the ones who didn't already know) and got a product to production within about 5 months[1]. Erlang is not new. It has been around for over 20 years. I don't think we needed to, but if there weren't an elixir library for what we needed, we had erlang libraries to fall back on. Our "new engineers" were often attracted to us BECAUSe we chose elixir. It took about a week for us to get new engineers productive with elixir (we hired good people, though). You're over estimating the benefit of libraries and way underestimating the benefit of a really good language/platform.... and elixir/erlang is that. It's a lot faster to create a given amount of functionality in Elixir, and then a lot faster to debug it and extend it. And then, after making the choice to stick with an "established" language, companies are shackled to it forever, hiring people who already like that language and so they never leverage newer better ways of doing things. [1] That was a year and several months ago that it went live. Five months may seem long, but this was a from-scratch ecommerce in a highly regulated industry involving a great deal of pulling customer records during the purchase process, with a parent company that didn't understand the concept of specs and kept changing it's mind on what it wanted. We were about %30 faster than a comparable other project at this company.
lectrick 11y ago
I've been doing programming for a while now (mostly in Ruby of late, but prior to that, lots of stuff) and the more I play with Elixir, the more I want to work in it. I'm actually going to ElixirConf (which is next weekend in Austin). They seem to have done a lot of things right, and addressed pretty much every single criticism I had of Ruby. > I'm very seriously considering Elixir/Phoenix for my next startup It will be a risk, but I say go for it. Others (who have probably NOT had any Elixir experience!!) will tell you your startup is already enough risk, but here's the thing- Elixir could end up being the key differentiator technology for you. Who else provides NO DOWNTIME code upgrades, and that incredible request responsiveness as well as reliability? Immutable data? Extreme concurrency? The "Actor model" that everyone is enamored with these days? The awesome community? Nobody, I think.
- 15155 11y ago
  > NO DOWNTIME code upgrades This doesn't need to be a language feature, but this is possible on the JVM afaik (see Clojure). Also, NO DOWNTIME in the context of services is kind of hard to qualify: I have no downtime for say, a web service, when doing a load-balancer deploy shuffle. > incredible request responsiveness as well as reliability "Request responsiveness" to some degree depends on language- a language is sometimes your upper-bound on performance. Much more often, however, do I find that this is a function of application design. And yes, language design and application design heavily play into each other, but there are many, many languages that can achieve the same responsiveness/reliability concerns. Haskell, many JVM-hosted languages are good choices. > Immutable data Almost every modern functional language. Many even do it (immutable data structures) better than Erlang/Elixir. Some even have interesting (state of the art) concurrency features that perform better in different situations - see Haskell STM (I wouldn't try and compare to Mnesia). > Extreme concurrency Haskell, Go, anything on the JVM, the CLR is catching up. > Actor model This is a bit of a subjective and semantic thing - many languages have green threads (though not all would necessarily fit the bill of "actor model" in out-of-the-box implementation, and not all are truly preemptive (most aren't)) - Haskell, Go are two good out-of-the-box implementations. I know Haskell has an Erlang Actor analogue, not sure if Go does yet. > The awesome community I hesitate to use the word "niche language" - but most "niche languages" have great communities (albeit small ones) - possibly out of necessity. I don't find that this scales often (What would you call the "Java community?", where would you find it?, where are the pockets of "good?") This is 100% subjective, but, I feel like Ruby has one of the best, largest communities. Some of that has bled into Elixir, for sure, to be fair. --- All in all, Elixir is a great language, but I hesitate to recommend it without knowing more about GP's requirements and business. (What if the GP needs to do very memory and CPU-intensive number crunching?)

by yumraj 11y ago

smt88 11y ago

To be honest with you, "for my next startup" strikes me as the absolute worst time to use a language/platform that is both new to you and new to the industry. Delays kill startups, and that just begs for delays. You have to learn the language. All your new engineers have to learn it. You'll inevitably be (re)inventing the wheel because Elixir isn't in production at thousands of companies already. Picking a shitty, slow language, as long as it's a popular one (JavaScript, Java, C#, PHP, Python), is going to have a much better cost/benefit profile.

pgz 11y ago
It really depends on the startup. For some form of chat application or distributed system he will find himself reinventing less compared to the competition. Would be a great way to beat the averages :)
yumraj 11y ago
Yes, you're absolutely right. Which is why I'm extremely conflicted right now. I definitely like what I'm seeing with Elixir/Phoenix, but should I take the risk or not is a really tough question. It is performant and fault tolerant, so for a startup if that means it can reduce our operational, and support, cost that itself would be a huge win. Deployment seems straight forward, much much simpler than what I had to do with a Rails app that I was experimenting with. Go deployment would be easier, but Elixir seems at worst to be inline with Play/Java (running under Play and not tomcat). There is a huge set of libraries should I need to venture outside Elixir and into Erlang, and moreover I think (not 100% sure) that Erlang can easily call into other language libraries which might come in handy. The way I'm looking at it is implementing small examples in a couple of other options, such as Nodejs/Loopback and Java/Play and then comparing them. So far Elixir/Phoenix seems straightforward and productive, but still evaluating. However, even if Elixir/Phoenix is the best thing since sliced bread, hiring and training is indeed going to be an issue so I've been trying to figure out how to solve than conundrum.
- rz2k 11y ago
  One counter point is the "Python Paradox"[1], though I don't know how well that conjecture was ever actually supported. However, isn't the Elixir/OTP ecosphere considered relatively practical and tested, rather than just esoteric or purist, even if it is new? [1] http://www.paulgraham.com/pypar.html http://www.paulgraham.com/pypar.html
  - simoncion 11y ago
    I can't speak to Elixir/OTP, as I've not -yet- used Elixir. However, every time I've gone to use something in the Erlang/OTP standard library [0] it has always been far less complicated and far more well designed than I feared it was going to be. Maybe this is a reflection of my pessimism, but I feel that it is actually a reflection of the quality of the software. :) [0] Yes, I know that Elixir is a BEAM language and -as such- has access to both Erlang and OTP, so this distinction is terribly fine. ;)
  - smt88 11y ago
    When PG says "smarter engineers", it isn't a given that there are more of them or that it matters that they're smart. Many startups don't need top-tier engineers. They need productive, numerous engineers, especially at the beginning when hiring anyone is difficult (let alone someone good).
sinatra 11y ago
> Picking a shitty, slow language, as long as it's a popular one (JavaScript, Java, C#, PHP, Python), is going to have a much better cost/benefit profile. Although, keep in mind that a startup is going to be a roller coaster ride for years. You'll have days when you get tired of writing financial models for investors, or when an angry email from a customer ruins your mood, or you hit a road-block with a UI that just doesn't feel right. You'll want to take a break from all that by going back to just writing code for a day or two. At that point, you will want to get pleasure out coding. I'll be very unhappy if after those kind of days, I try to find solace in coding, and I see PHP, JavaScript or Java staring back at me. Compared to the years it takes to turn a startup successful, the time needed to learn a new language well enough is negligible. I knew just basic Ruby when I switched to Ruby + Sinatra from Java for my new startup. Now, three years later, I can't be happier I made the switch.
- smt88 11y ago
  Failing fast isn't easy if you're also learning a new language. You want to go from zero to product as soon as possible, and that means using a language you already know like the back of your hand, even if that language sucks.
  - sinatra 11y ago
    Not necessarily. I don't go from zero to product till I have verified that there's a need for the product. I try to fail fast before developing the product. By the time I'm developing the product, I'm fairly certain it's not going to fail immediately after launch. Oh, and once you've built a product that people are using and you're going after growth, you would rarely get a chance to switch languages or frameworks. So, then, you're stuck with the language that you don't even like anymore for many years. I think you're also over-estimating the time required to learn a new language to be good enough for most startups. I understand that there are some areas where language mastery will be tremendous benefit. In that case, I agree that switching languages may not be such a good idea. But, that's a special case, IMHO.
  - MCRed 11y ago
    For your first couple programming languages, it's intimidating to learn a new language. Once you're experienced, though, you discover that its easy and quick to pick up new languages. Because my experience is, as I related above, even though I was learning elixir (for real, I had dabbled with it before) an building a team from scratch, we delivered a product extremely fast.... because we chose elixir. It doesn't matter how well you know java, the language is going to slow down your development dramatically... at lest compared to Elixir (and maybe go.)
lectrick 11y ago
I worked for thredup.com when it was brand-new and we used Rails when it was still fairly new and we had a pretty good time all things considered. You just have to be a capable programmer. ;)
keithwhor 11y ago
Since when is JavaScript (V8) slow? Is it 2006? :)
- smt88 11y ago
  That list of languages was "popular" rather than "shitty and slow", although some of them certainly are shitty (and dynamic languages do tend to be kinda slow). I realize my phrasing was confusing.
vikeri 11y ago
I do not agree, I have worked for a year on a startup using Clojure(Script) and I hadn't touched Clojure before. Never looked back and did not encounter any major issues springing from the choice of language. To the contrary, I have really enjoyed not having to deal with the disadvatages of older languages. The issue could possibly be in hiring, if the supply of Elixir-developers would be scarce.
perishabledave 11y ago
Kind of, since Elixir runs on the Erlang VM and it uses much of Erlang's libraries (e.g. OTP) I'd argue that you can look at Erlang's track record for Elixir's.
MCRed 11y ago
Nope. And I have real world experience to contradict that. Last year started a project with elixir, about 8 months before elixir hit 1.0. Despite starting with me and another engineer we both built a team, taught them elixir (the ones who didn't already know) and got a product to production within about 5 months[1]. Erlang is not new. It has been around for over 20 years. I don't think we needed to, but if there weren't an elixir library for what we needed, we had erlang libraries to fall back on. Our "new engineers" were often attracted to us BECAUSe we chose elixir. It took about a week for us to get new engineers productive with elixir (we hired good people, though). You're over estimating the benefit of libraries and way underestimating the benefit of a really good language/platform.... and elixir/erlang is that. It's a lot faster to create a given amount of functionality in Elixir, and then a lot faster to debug it and extend it. And then, after making the choice to stick with an "established" language, companies are shackled to it forever, hiring people who already like that language and so they never leverage newer better ways of doing things. [1] That was a year and several months ago that it went live. Five months may seem long, but this was a from-scratch ecommerce in a highly regulated industry involving a great deal of pulling customer records during the purchase process, with a parent company that didn't understand the concept of specs and kept changing it's mind on what it wanted. We were about %30 faster than a comparable other project at this company.

lectrick 11y ago

I've been doing programming for a while now (mostly in Ruby of late, but prior to that, lots of stuff) and the more I play with Elixir, the more I want to work in it. I'm actually going to ElixirConf (which is next weekend in Austin). They seem to have done a lot of things right, and addressed pretty much every single criticism I had of Ruby. > I'm very seriously considering Elixir/Phoenix for my next startup It will be a risk, but I say go for it. Others (who have probably NOT had any Elixir experience!!) will tell you your startup is already enough risk, but here's the thing- Elixir could end up being the key differentiator technology for you. Who else provides NO DOWNTIME code upgrades, and that incredible request responsiveness as well as reliability? Immutable data? Extreme concurrency? The "Actor model" that everyone is enamored with these days? The awesome community? Nobody, I think.

15155 11y ago
> NO DOWNTIME code upgrades This doesn't need to be a language feature, but this is possible on the JVM afaik (see Clojure). Also, NO DOWNTIME in the context of services is kind of hard to qualify: I have no downtime for say, a web service, when doing a load-balancer deploy shuffle. > incredible request responsiveness as well as reliability "Request responsiveness" to some degree depends on language- a language is sometimes your upper-bound on performance. Much more often, however, do I find that this is a function of application design. And yes, language design and application design heavily play into each other, but there are many, many languages that can achieve the same responsiveness/reliability concerns. Haskell, many JVM-hosted languages are good choices. > Immutable data Almost every modern functional language. Many even do it (immutable data structures) better than Erlang/Elixir. Some even have interesting (state of the art) concurrency features that perform better in different situations - see Haskell STM (I wouldn't try and compare to Mnesia). > Extreme concurrency Haskell, Go, anything on the JVM, the CLR is catching up. > Actor model This is a bit of a subjective and semantic thing - many languages have green threads (though not all would necessarily fit the bill of "actor model" in out-of-the-box implementation, and not all are truly preemptive (most aren't)) - Haskell, Go are two good out-of-the-box implementations. I know Haskell has an Erlang Actor analogue, not sure if Go does yet. > The awesome community I hesitate to use the word "niche language" - but most "niche languages" have great communities (albeit small ones) - possibly out of necessity. I don't find that this scales often (What would you call the "Java community?", where would you find it?, where are the pockets of "good?") This is 100% subjective, but, I feel like Ruby has one of the best, largest communities. Some of that has bled into Elixir, for sure, to be fair. --- All in all, Elixir is a great language, but I hesitate to recommend it without knowing more about GP's requirements and business. (What if the GP needs to do very memory and CPU-intensive number crunching?)