21 ms·
How Elixir helped Bleacher Report handle 8x more traffic
- d3ckard 10y agoFunny thing is that I have yet to see the other side of argument - when people had a bad experience with Elixir. It seems so nicely fit into its problem domain that basically everybody that starts doing it is happy with results. I guess that says something.
- holydude 10y agoThe bad side 1) no support from mega corporations 2) not that many developers to choose from 3) while based on BEAM it's still too "new" 4) too slow for raw money crunching
- izelnakri 10y ago4th one depends on the implementation, and it isn't a disadvantage since most scripting languages have the same characteristic.
- pdexter 10y agoHow many implementations are there?
- izelnakri 10y agoI can give you 3 already: 1- doing it with SQL, 2- Distributed way with processes, 3- Doing it with custom NIFs etc.
- gamache 10y agoSpeaking as someone who came to Elixir from Scala/Akka on the JVM, yes it is absolutely a disadvantage, and no there is no implementation of the Erlang VM which rivals the JVM for speed. In Erlang/Elixir you get speed through horizontal scalability (which is easy) and/or writing parts of your code in another, faster language (which is harder).
- hderms 10y agoWhy did you leave Akka for elixir?
- gamache 10y agoThere were a few reasons. I never loved Scala, and I especially didn't like the let's-write-Haskell-in-Scala obsession with static typing that affects half the community. The JVM and Akka both have a lot of knobs to tweak, whereas the BEAM seems to have saner defaults. I didn't need rocket fast performance and I didn't need any JVM libraries, but I did like the actor model of concurrency and process supervision, so when it came time to look for greener pastures, Elixir was a solid choice. I've been using it in production just over a year, and it's been excellent.
- hderms 10y agoFair enough. I've dug into the haskell-as-scala stuff and found it academically interesting but somewhat divorced from reality with respect to how immediately useful it would be to most projects.
- crusso 10y agoThe reality is that raw money (number?) crunching is rarely the problem for modern sites. Even when it is, the number crunching code is often easily isolated and can be modularized using another more performant language and then Elixir can call that module as needed.
- hackerboos 10y agoAlso not many jobs. I've been looking for an Elixir job in Canada for months.
- d3ckard 10y agoIMHO the best way to start working with Elixir is to persuade people in your current place to give it a try. In the age of microservices it should be doable and later on it creates the market. That's what I did anyway.
- sotojuan 10y agoThis isn't going to change for years. If you want an Elixir job, go freelance.
- d3ckard 10y ago1) You can argue that it makes tech much less dependent on needs of one particular entity. It can be a good or bad thing, depending on your views. 2) This one I do not agree on principle. I wish we finally stopped judging devs by "language experience" and start judging them by "domain experience". For early stage startups it might be a disadvantage, all the rest should not be concerned about it. 3) Actually it's pretty stable. It's constantly being expanded (i.e. GenStage, but I've been working with it for year and a half now and never had issues with breaking changes. 4) True, but this is a niche. Number crunching is important in some domains, but what you need from web app is usually making things work in predicable way. Everything else is more of a specialized problem which needs custom solutions.
- kitsune_ 10y agoJudging from past experiences here on HN and other programming echo chambers, I'd wager that Elixir is currently at the beginning of its hype cycle (somewhere between 'technology trigger' and 'peak of inflated expectations' if you go by Gartner). So I'm almost certain that you will eventually see "Why Elixir was bad for us..." posts upvoted on here or in other places.
- hackerboos 10y agoElixir hasn't gone through the usual hype phases because it's just syntactical sugar, less boilerplate and more modern than Erlang making it more palatable for Ruby/Python devs. The BEAM VM is what makes all this possible and the BEAM VM has been around for decades.
- kitsune_ 10y agoIf you search for Elixir on HN and sort by popularity, 10 of the top 20 results were submitted during the past 12 months (Which in itself might be just related to an increase in users here on HN, but compare the results to languages like Java or Haskell). Many of my dev friends with hipsterish inclinations jumped on the Elixir hype train in the past year or so. I really don't see how this is different than past "hype phases" of other technologies.
- macintux 10y agoOh, sure, there'll be some people who regret it, but the key difference is that it isn't going to run into some of the same problems that plague other new languages because it fundamentally isn't a new language.
- danmaz74 10y agoNo matter how good Elixir is, at some point the hype will reach a point where many people will try it having wild expectations, and will get disappointed. This is just the way hype works :)
- amalag 10y ago
- aaron-lebo 10y agoIt's early in the adoption cycle. Not that Elixir is bad, but if you are writing something in it today you are ahead of the curve. As soon as there are a lot of mediocre developers (if we get there) that start using Elixir because they heard it can do no wrong, you'll hear complaints.
- d3ckard 10y agoThis is undoubtedly true. One thing to note though is that I believe that Elixir/Erlang model of programming just fits well with the demands of web applications. There is a lot of cognitive load you're relieved from just because the used abstractions actually seem well suited for the task.
- twoquestions 10y agoBad side: you have to do everything yourself. Ruby on Rails, ASP.Net, Django, they all have a million and one StackOverflow answers, blog posts, and books written about them. I found out the hard way that Elixir and Phoenix docs aren't as prolific. That and the names are less Googleable. Some people may like that challenge, but it does add a level of difficulty.
- andy_ppp 10y agoIn my experience reading the Phoenix source code is much simpler than Django or Rails so less need for stack overflow or help. There is much less to go wrong as well.
- iamatworknow 10y agoYou do realize your experience isn't typical, right? Most developers aren't going to look through the source code for the framework they use to answer a question about usage. They're going to google it.
- ibgib 10y agoUnlike with past languages, I've also found myself looking at the source code with Elixir, but it's because docs are first-class citizens. I think this is atypical of languages in general, and it's actually why the source code comes up when googling for the info. The answers are in the code in the form of: ``` @doc This is some useful, markdown documentation, which actually contains usage info. ## Usage ## Examples ```
- ibgib 10y ago> I found out the hard way that Elixir and Phoenix docs aren't as prolific Odd, because I have found the opposite to be true about the docs. I've found the docs proper to be quite prolific, well maintained and well-written with examples. This stems from docs being first-class citizens of the language, a dead-simple docs generation tool, and their dogged commitment on excellent documentation (which is why docs are first-class citizens to begin with). > That and the names are less Googleable. That said, the _SO/Google_ aspect (not docs) is _significantly_ less prolific - I totally agree with that. But I've found where with other languages I often find myself on SO (C# and JS mainly), I haven't even needed it because the docs are just so well maintained (and versioned). This, plus their community is _extremely_ active, on the elixir forum and github (also slack, but I use that less). So now, when I google for elixir info, I'm basically googling to get to the official documentation quickly. If there is any question I have beyond that, I check the elixir forum, rarely (but sometimes) needing to post a new question. Perhaps I've just had a different experience wrt this.
- andy_ppp 10y agoI've tried to get other people to get involved with Elixir but most people don't understand Functional Programming and haven't encountered the problems Rails/Ruby or say Python has. I think people coming from OOP find FP hard and seem to struggle with things like Ecto and definitely Macros. Once you have mutable state everywhere and problems with the GIL and throughput on routes being slowed down too much so you start moving everything into queues (celery or rabbit). Then you realise that all of this could have been avoided and made much much easier to test if it were all written in Elixir.
- sotojuan 10y ago> I've tried to get other people to get involved with Elixir but most people don't understand Functional Programming I really don't get this. Elixir is barely FP—just immutability and first class functions. Is it really that hard for a lot of people? It's not Haskell or Clojure (""weird"" syntax). I'd argue the hard part of Elixir is OTP and taking advantage of distributed computing. > haven't encountered the problems Rails/Ruby or say Python has. This is a good reason, honestly. If Ruby is fine, why change? It'll just make learning a new paradigm and OTP less fun because there's no need to learn it.
- deleted 10y ago[deleted]
- IanDrake 10y agoI would think you could switch your average legacy ROR implementation to a newly coded system on just about any other platform and also come out way ahead on resource requirements. For instance, they could have gone with .net and gotten nearly the same results AND had a stable of millions of devs to pull from.
- noop123 10y agoHence why reports like above are helpful, so there are examples to draw from. Otherwise everyone would just be guessing. I bet many would love to hear about migration cases from RoR to .NET as well.
- falcolas 10y agoYet another "Originally wrote in X, rewrote the application (in Y), and it was so much better!" story. I think the problem is that all of the focus arrows in on X vs Y, and not "rewrote the application". My opinion, and my experience, has demonstrated that once you understand the domain, a re-write in any language (including the original) is going to result in an improvement of similar magnitude. They could have re-written it in Cobol and probably seen an improvement of similar magnitude. But of course, "Y is n-times better than X" makes for a better headline and looks great on a Key Result slide...
- overcast 10y agoCorrect. Unless we're talking about extremely specific software, new performance typically just comes from newly learned skills. More efficient database calls, removal of long running loops, yada yada. I've revisited software I wrote for a company in my school days, only to decrease SQL calls from one minute to less than a second.
- christophilus 10y agoI agree. I'm not sure if the system would show a 10x improvement, but every time I've done a rewrite-- usually in the same language as the original-- almost everything improved dramatically (UX, performance, maintainability, etc). I now think that V1 should be considered throwaway, or at best research intended for exploring and understanding the problem space.
- noop123 10y agoPutting all the success in terms of "rewriting" is as misguided as accounting it all on the technology change. I have seen rewrites using the same technology fail due to scope issues. I have seen rewrites fail because they could not master a new technology. It is easy to paint everything with ones or zeros but it is most likely a combination of factors. A team with more knowledge of the domain, a management willing to try new technologies and a technology that excels at concurrency, which seems to be the problem they had at hand, sounds like a good combination for success.
- xutopia 10y agoExcept Phoenix and Elixir are just faster out of the gate than Rails and Ruby! "tl;dr Phoenix showed 10.63x more throughput over Rails when performing the same task, with a fraction of CPU load" https://littlelines.com/blog/2014/07/08/elixir-vs-ruby-showdown-phoenix-vs-rails https://littlelines.com/blog/2014/07/08/elixir-vs-ruby-showd... You can tack on a Phoenix app on top of a Rails app's database and immediately get big improvements as Rails can be a bottleneck.
- karmicthreat 10y agoI do quite a bit of event passing and processing from physical sensors and devices. It is proving quite useful there. I probably won't do all of our system with elixir though.
- NickBusey 10y agoI am curious, could you expand a bit on this? What about elixir in particular is useful for the physical sensor application? What kind of devices are you running it on?
- gargarplex 10y agoI would like to build an Elixir training video course called "Elixir for Rails developers". This is probably sufficient for an intro video series… 1) Installing, including all of the dependencies: 2) Making a new project. 3) Setting up a data model. 4) Building CRUD routes. 5) Building views. Can you use haml, sass, etc.? 6) What’s the equivalent of the console? 7) Deploying to production. How does that work? If any Elixir enthusiasts are interested in teaming up, let me know.
- sotojuan 10y agoThis already exists in book, blog post, and video formats.
- gargarplex 10y agoWith all due respect, people said that about dropbox when it launched. Can you recommend a good, cohesive video series that clearly explains Elixir and is targeted specifically to Rails devs?
- d3ckard 10y agoOut of curiosity: what does it mean to you "targeted for Rails users"? BTW, I was a Rails developer before I moved to Phoenix. Given that Phoenix is modelled after Rails that is the easiest transition there is (though it gets more and more different with every release and 1.3 will be a big step - and those are good changes).
- gargarplex 10y agoI mean things like: "Is there a REPL? I bet you're wondering how we deal with the console: what's the equivalent of bundle exec rails c". "What's the equivalent of an ActiveRecord migration". And so forth. We want to build the Rails blog tutorial, but in Elixir+Phoenix, and specifically for Rails users. Definitely, please send me an email: zack@zackburt.com if you'd like to be involved in the project.
- jondot 10y agoAnyone else worried about the long-term outlook on Elixir for adopting it now in bigger companies? (leaving OTP out, of course) * Bus factor of 1? * No visibility of improvement process (i.e. PEP)? * Long term support? How would you resolve this? do consultancies that build projects for clients in Elixir are aware of that? or notify the client of that?
- josevalim 10y ago> * Bus factor of 1? The core team is made of six members: @josevalim, @fishcakez, @ericmj, @lexmag, @whatyouhide and @true_droid. We have more than 500 contributors on GitHub, it is an accessible codebase. The areas where the bus factor is actually 1 are very rare (and when I can I delegate work to minimize that). > * No visibility of improvement process (i.e. PEP)? All planned improvements are currently in the issues tracker: https://github.com/elixir-lang/elixir/issues https://github.com/elixir-lang/elixir/issues. It is a short list because it is a stable language and the focus is on the ecosystem rather than the language. Proposals are sent before hand to elixir-lang-core mailing list for discussion. > * Long term support? List of consultancies currently involved with Elixir: https://github.com/doomspork/elixir-companies#consulting https://github.com/doomspork/elixir-companies#consulting Plus Plataformatec has been doing and supporting Elixir for 5 years and Erlang Solutions has been supporting Erlang for way longer than that and they also provide Elixir support.
- zeveb 10y agoMy God that's a nightmare of an office. Open-plan and a wall of distracting televisions. How do they get anything done? Or do employees just WFH when they need to actually produce stuff?
- NickBusey 10y agoHad the exact same thought, it looks downright dystopian. Not sure how anyone can get anything useful done in an environment like that.
- abritinthebay 10y agoThat's our content team on the 6th floor. They actually use all those TVs. It's the prettier floor for photos... Engineering is on a different floor, still open plan, but has lots of small meeting rooms for quiet work too. Also a pool table
- deleted 10y ago[deleted]