by kristerv on 1/6/19, 1:02 PM with 240 comments
by artellectual on 1/6/19, 3:08 PM
In elixir you really get the full power of multi core and support for distributed computing out of the box.
Code that would have been beyond my pay grade or wouldn’t even imagine to write in Ruby or JavaScript is now easily reasoned about and maintained in projects. I can write succinct code that is easy to read, is fast, able to take advantage of multiple cores, less error prone, which I can scale to multiple machines easily.
The erlang scheduler is so damn powerful and it feels amazing to be able to execute your code on multiple machines with a simple distributed task which is built in as a standard functionality of the language.
I’ll end this note saying that, look at the problem you are trying to solve. If you need multi core and distributed features (which is generally more common than you think) elixir is truly your friend.
I can say without a shadow of a doubt the project I’m building right now would not be progressing as fast as it is if I picked anything other than Elixir. You get a lot of bang for your buck when it comes to productivity in the domain that elixir solves for.
by chmln on 1/6/19, 4:56 PM
> Memory efficiency is much better than most other languages (with the exception of Rust, but Elixir is miles better at Error handling than Rust, which is a more practical feature IMO
How exactly are arbitrary runtime exceptions better? Any elixir function you call has the potential to crash. Meanwhile with Rust, your function returns a `Result` if it can error, and callers are then forced to handle those by the compiler, either via pattern matching or ergonomic error propagation.
Rust has runtime panics, but those are for rare unrecoverable errors and are not at all used for conventional error handling, reserved usually for C FFI, graphics code, etc.
by arvidkahl on 1/6/19, 4:18 PM
It has been extremely stable, scaling has been a non-issue. Error reporting has become easier and easier, now that companies like Sentry and AppSignal have integrations for Elixir.
Elixir is VERY fault-tolerant. DB connection crashing? Ah well, reconnects immediately, while still serving the static parts of the application. PDF generation wonky? Same thing. Incredibly fast on static assets, still very fast for anything else.
I've had nothing but fun with the language and the platform. And the Phoenix Framework is just icing on the cake. I've been fortunate to have been to many community events, and meeting (among so many others) José and Chris at conferences has made me very confident that this piece of software has a bright future. The Elixir slack is also VERY helpful, with maintainers of most important libraries being super responsive.
I would not start another (side or production) project with anything else than Elixir.
by symboltoproc on 1/6/19, 2:41 PM
I've seen third party dependencies churn on Elixir as well (packages that are no longer maintained or alternatives that are better) - I think it's an inherent problem with using dependencies and has nothing to do with the programming language in which those dependencies are written.
> As a developer I just want to get on with my work, not have to read another Hackernoon post on how everything from last week is obsolete because XYZ framework
My recommendation is that you don't read Hackernoon. This seems like a very ineffective way to level up your developer skills.
Edit: I agree that Elixir is very nice and would pick it over JavaScript for backend heavy applications without thinking. I just don't think this argument makes any sense in that context.
by phtrivier on 1/6/19, 3:53 PM
* the syntax is well though-of (`with`, destructuring, `|>` are powerful
* message passing has great use-cases
And then it has problems that are not necessarily "elixir-y", but are there nonetheless:
* it's hard to model an application around the Actor model. It's very easy to abuse it.
* it's hard to maintain / refactor a large application without help from the compiler before run-time
* it's hard to maintain an application in a language with a young ecosystem and no "seamless" integration with a better established one (ports are not seamless.)
Quite frankly, I'm looking forward to writing a backend in Rust, to have a point of comparison.
by sb8244 on 1/6/19, 3:19 PM
It's hard to pick one big draw, but I'd say the biggest for me is that everything I wanted to do in rails has been possible in Elixir and then additional functionality not easily possible in rails is trivial in Elixir. I often consider the distribution techniques as "enhancers" as you could work around them with global locks and data stores, but you don't need to.
I'm very bullish on Elixir and I'm curious to see where it will go. Looking forward to giving my talk about bringing Elixir into production (from a human and technical standpoint) at Lonestar Elixir conference.
by mrspeaker on 1/6/19, 2:38 PM
Elixir is past 3 times - so I will check it out for sure! - but this article didn't seem to actually say anything (seemed more like a PR piece that was trying not to be technical, and the main argument appeared to be "well, it's not javascript!").
The part that actually talked about Elixir listed some Pros that didn't seem that unique. What's the "killer feature" of Elixir - or is it just a combination of "good features"?
by faitswulff on 1/6/19, 2:41 PM
document.querySelectorAll('em').forEach(el => el.replaceWith(new Text(el.innerText)))by nickjj on 1/6/19, 2:26 PM
I am building a quite involved video learning platform as we speak with Elixir and Phoenix. No regrets so far, and if anything as time goes on, I'm becoming more and more happy with the decision.
The community is really great and there's a lot of quality libraries available. Not just libraries, but entire production systems too. For example https://changelog.com/ is written with Elixir / Phoenix and their platform is open source'd at https://github.com/thechangelog/changelog.com. There's so much good stuff in that repo to learn from.
Also the Elixir Slack channel has 20,000+ people in it and the official forums at https://elixirforum.com/ are very active.
by bnchrch on 1/6/19, 3:05 PM
- Ship faster
- Write simple, readable, reliable and fast code
- Scale easier and with less resources
- Onboard and train new hires into the code base quicker
I know I'm making it out to be a panacea which to be clear it isn't as the deployment story still has some final pieces for the core team to work through but I will say I'll continue to use it to build in the future
by bicx on 1/6/19, 2:48 PM
by _asummers on 1/6/19, 2:26 PM
by plainOldText on 1/6/19, 6:24 PM
I've been programming intensively in Elixir for the past two years and it's a wonderfully productive language, which allows one to write elegant systems that leverage the multi-core architecture of today's machines effectively.
In addition, the networking capabilities and fault tolerance of the VM make writing systems which spawn machines and services a breeze; not the mention the ecosystem only gets better by the day.
So yeah, Elixir is one of my main tools when I want to get things done elegantly and productively. And if for some reason I need to speed things up a bit here and there, I just add a little rust into the mix. [1]
by nixpulvis on 1/6/19, 3:13 PM
by bsaul on 1/6/19, 6:49 PM
by whalesalad on 1/6/19, 5:55 PM
But now I have a contract that would really benefit from the runtime. That being said the existing environment has a lot of python expertise and I don’t have enough production Elixir experience to have confidence in myself to deliver something of the right caliber.
It’s a damn shame. This system has to process hundreds of thousands of API calls for workloads against a half dozen third parties that all have different rate limits and failure modes. It’s the perfect job for Elixir. It needs to be as fast as possible while isolating failures to the smallest unit possible.
by cuddlecake on 1/6/19, 3:41 PM
It's the first language I genuinely enjoy reading and writing even in my private life.
If I wonder about the internals of a library I use, I can just look into the code and kind of understand what's happening. Never had that with JS or anything.
I'm just a genuine fanboy.
Only drawback I feel is: Some libraries that would have been quite developed in JS are not that well developed in Elixir. Some libraries are quite dead and it's hard to find alternatives (mostly obscure stuff)
But on the other hand, it often seems manageable to just write it yourself, or fork it and move on.
by neathack on 1/6/19, 4:53 PM
Really, Go "is the choice if you need to 'sell it' to a 'Boss'" and the imperative programming style leads to more complexity? And Python/Django can only be used if you "don't need anything 'real time' and just want RESTful 'CRUD'".
I get it, you guys like Elixir, but painting the world using such broad strokes doesn't really sound like "kaizen learning culture" to me, but more like "Negative Nancy".
by StreamBright on 1/6/19, 2:22 PM
https://github.com/aws-samples/aws-lambda-elixir-runtime
The only downside is that the out of the box performance is subpar for http services but it is still acceptable.
by heurist on 1/6/19, 8:24 PM
by phil_s_stein on 1/6/19, 5:02 PM
by zerr on 1/6/19, 4:42 PM
by trashhalo on 1/6/19, 2:46 PM
Anyone know whats going on there?
1. https://www.techempower.com/benchmarks/#section=data-r17&hw=...
by rs86 on 1/7/19, 10:33 AM
I think performance is better compared to Ruby and Python, but then again my experience with web applications is that the domains are best modeled using classes.
For writing networking code and protocols, the binary pattern matching is amazing, though. The Plug libraries are a pleasure to use also.
by lopatin on 1/6/19, 3:46 PM
by xvilka on 1/6/19, 2:18 PM
by atonse on 1/6/19, 3:42 PM
But from a talent and recruiting perspective, I'm less enthusiastic. Elixir, yes, there's growing talent. But Ember, boy it seems like nobody is doing it, and I've had to convince potential candidates that it'll be worth their time for future employability to learn Ember.
by ai_ia on 1/6/19, 2:31 PM
by xena on 1/6/19, 2:34 PM
by butterisgood on 1/6/19, 6:32 PM
by troquerre on 1/6/19, 7:09 PM
by dev_dull on 1/6/19, 4:20 PM
I guess the better question would be why is there not an easy, standard lib for doing this in any language in 2019?
by atombender on 1/6/19, 11:56 PM
Most of my current work is in Go, which is a fairly strict language, and I value perhaps more than anything the ability to verify my program at compile time -- for one, I can do large-scale refactoringest, safe in the knowledge that my program won't run until everything is again sound.
Go still leaves a lot to be desired, so I've been exploring options. I've started picking up Rust. I love the idea of zero-cost abstractions, though at the moment I find the mental overhead of a lot of the constructs (lifetime annotation, implicit operations that happen due to what traits you implement, the many baroque syntax choices, etc.) a little annoying. It brings to mind modern C++, which also has a lot of rules that you have to remember, from copy constructors to what the order of "const" in var/arg decls mean, to the awkward split between functional and imperative styles.
Modern C++ looks interesting, and I've used it for a few projects. What bugs me the most is the warts still not fixed by the "modern" iterations: Include files (leading to long compilation times), lack of modules, unsafe pointers, etc. While I appreciate and understand template mechanics, I'm not overly impressed with some developments -- Rust traits and Haskell typeclasses just seem so much less messy than the current situation with type traits and concepts. There's a tendency in "modern" C++ to offer multiple syntaxes for the same thing, none of which are very intuitive.
I've occasionally written small things in Haskell and OCaml, and I've considered doing a future project in OCaml now that multicore support is getting close. I looked at F# for a bit, too, but it comes across as having too much .NET/Microsoft flavour for me. Same with C#. I've looked at Nim, but it's too niche -- for the projects I'm going to work on, I'd have to write libraries for functionality that just isn't there yet (e.g. gRPC).
Back to Elixir, though; the problem is of course that none of these other languages offer anything like OTP. The closest may be Haskell, with it's Distributed Haskell project. But I'm not sure it's anywhere close to being as mature. Maybe Pony is comparable, but that also seems quite niche at this point.
by qaq on 1/6/19, 3:37 PM
by therealmarv on 1/6/19, 3:29 PM
Why would a SW company invest in niche languages where the resources (software developers) are really expensive and really hard to get? Technologically it's all great but economically that's a nightmare.
by GordonS on 1/6/19, 11:15 PM
I've dabbled with both - but really fell in love with both of them! I come from a C# background, so the static typing of F# is a big pull. OTOH, the simplicity of Elixir was an absolute delight - after just an afternoon, I felt like I had a decent grasp of it.
I'm conflicted, and would value some other opinions?
by abledon on 1/6/19, 6:50 PM
by pjmlp on 1/6/19, 3:44 PM
Now for someone starting new, maybe the Erlang eco-system might be a good bet, and Elixir an entry point.
Still, not everyone has Ericson scale problems to solve.
by rthille on 1/6/19, 8:57 PM
by flixic on 1/6/19, 2:37 PM
by honkycat on 1/19/19, 3:56 AM
Elixir has totally spoiled me. The meta-programming ALONE is something I miss constantly when I have to use other languages.
by mooreds on 1/6/19, 3:53 PM
by diminish on 1/6/19, 4:02 PM
Rails has revolutionized web application development on Ruby, with Sinatra as the minimalist version and a lot of "me too" frameworks have been developed, and somehow I like them all.
* On Python, Django and Flask * On Elixir, Phoenix * On Crystal, Amber * On Javascript Express js for Sinatra. But on JS we didn't get a successful Rails clone, but a storm of front end frameworks, finally Vue JS/React and endless others.
I wouldn't pick Elixir because The world is elsewhere: My choice is on JavaScript ES6, Vue, and a simple Express.js, Sinatra, Flask for most projects.
by cygned on 1/6/19, 2:24 PM
I never had any debugging issues in particular, but the dependency hell drives me nuts, too.
by hartator on 1/6/19, 6:36 PM
- Pipelines are hard to debug. You can’t just throw a debugger just before the line with the issue.
- Phoenix is very bad at serving static files. It was a nightmare to import a new CSS template requiring to convert everything to work with bower first, or dump the files in the /priv directory to make it work.
by undersheet on 1/6/19, 9:29 PM
by subfay on 1/6/19, 7:06 PM
by gpmcadam on 1/6/19, 2:19 PM
But every other word being emphasised in this article was tiring to read.
by qwerty456127 on 1/6/19, 3:04 PM
by jondubois on 1/6/19, 6:32 PM
This is a design flaw on the part of the team who is using Node.js incorrectly and not a flaw of Node.js itself. There are many ways to implement error handling properly in Node.js so that a user cannot crash a whole server/process and there are a lot of frameworks which implement this by default.
Elixir is over-marketed and over-hyped. It's obvious that there is a big money machine behind it. The entire community is obsessed with evangelizing; they're not getting organic growth; they have very aggressive marketing but it's mostly founded on exaggerations and flat out lies.
In addition to what I've pointed out above, to say that someone can learn Elixir in just 1 week is another example of a lie. It takes years to fully understand the nuances of a language to the point that you can be good at it; there are always a lot of patterns to learn; especially for functional programming languages.
The Elixir ecosystem will never be as significant as that of Node.js because Elixir's ecosystem is founded on hype. Part of the greatness of Node.js is that reality tends to exceed expectations; so-called 'thought leaders' and 'bloggers' have been working very hard to discredit Node.js from the beginning but they failed (see https://news.ycombinator.com/item?id=3062271).
I'm not going to consider using Elixir while it's so clearly over-marketed and over-hyped.
by cjhanks on 1/6/19, 3:22 PM
Web developers seem to follow trends; Perl -> DJango|RoR -> Node.JS -> Scala -> GoLang -> Elixir -> Something. Or, something like that. To me, it's like buying a $500 pencil and expecting that you should be capable of writing a better book.
If you get in bed with that crowd, don't expect that your program and 3rd party dependencies are going to be stable in 2 years.