Elixir as a new language doesn't have to reinvent a lot of things because of its ability to transparently call erlang (for instance, to use crypto I could just do :crypto.strong_rand_bytes(32) |> :base64.encode_to_string ). This is an awesome advantage to have.
Another one that wasn't mentioned: optional types. Sometimes you don't need / want em, but it's good to have the option available for when you do.
Aside from that... Elixir feels really fun. Maybe it's a silly metric, but that's just my biased opinion.
The last feature that caught my attention was their deployment tools. I haven't used em yet, but based on a conference video I watched, it looks like they have pretty sweet setup. They claim to have very easy zero downtime upgrades / downgrades. And I think preparing a release automatically bundles dependencies, so everything is contained in a single compressed file.
> Aside from that... Elixir feels really fun. Maybe it's a silly metric, but that's just my biased opinion.
I'd argue that from a hacker's perspective, this is the most important metric. It's what keep you returning to the language, and what gives it vi(r|t)ality. Don't underestimate fun!
If you use Dialyzer you get compile time type checking of for most operators too. The lack of operator overloading means that it can identify and trace variable types based on the operators they are next to (variables next to a + sign must be a number, etc).
When I started learning I didn't understand why I had to use a different operator for string concat vs numerical addition and the Dialyzer talk from ElixirConf explained it very well.
Coming from the Clojure world, every time I read about about Elixir, the similarity of the two langauges' values always surprise me: immutability, macros, dynamic and gradual typing, concurrency, and on.
I've yet to touch Elixir (or Erlang, for that matter). Does anyone have experience using both? Thoughts? Has anyone crossed from one language to the other over any strong preference?
I spent a few weeks with Closure about a year ago. To be honest, Elixir is much more pleasant to work with. However, I might be biased as my main lang is Ruby...
You still have to bend your thinking, yet, you feel that you become productive much faster.
I have used both (though Clojure less). I have not built distributed applications in Elixir yet, so I do not focus on those features in this comment. I prefer Elixir because:
1. My brain thinks in terms of editing lines, not s-expressions; I didn't get the hang of paredit, and editing without paredit required really tedious edit operations.
2. Elixir's understanding of types matches Erlang's and the host VM, while Clojure invents its own uni-typed IObj but runs on a typed VM. Interop with Java required adding type annotations. Elixir/Erlang interop seems to be almost entirely pain-free.
3. Elixir has a lot of syntax niceties like triple-quoted strings that automatically remove indents. And pattern matching everywhere.
4. I can feasibly (and in fact, have) audited and built all of my Elixir and Erlang dependencies from git repositories, while doing the same with the Maven dependencies needed for a typical Java project would be almost impossible. I wouldn't even know where to begin with bootstrapping all the necessary Maven plugins.
5. Elixir/Erlang has per-process garbage collection and memory limits, though I haven't taken advantage of these yet.
> My brain thinks in terms of editing lines, not s-expressions; I didn't get the hang of paredit, and editing without paredit required really tedious edit operations.
In my experience, learning and then working in Common Lisp, starting with paredit is tough. I disabled paredit for a while until I got the hang of thinking in s-expressions as you say. After a while when I tried paredit again, it was glorious.
Early on I did set up % as a global key that goes to the matching parenthesis if on parenthesis, and otherwise inserts the character typed.
I use Vim for editing Lisp. Basic :set lisp mode that dates back to ancient Unix implementations of vi and the % command for jumping between matching parentheses. In Vim, selecting a range and typing = re-indents it, and == indents the current line. I set shiftwidth to 2. When I need to move the indentation of a whole block I use select and < or >. Or << and >> for the current line. With those basics, I comfortably do 95% of all Lisp editing.
For instance to move an expression: put cursor on one parenthesis, type v for visual select, type % to jump to the other paren, then x to delete. Move somewhere, p to paste. Adjust formatting here and there, done.
I edit C and other languages in pretty much exactly the same way.
> Has anyone crossed from one language to the other...?
Yes, I've been doing Clojure for maybe four years, and picked up Elixir over the course of 2016. Frankly, I think I'll be preferring Elixir over Clojure for most tasks from now on.
The concurrency/parallelism story in Elixir/Erlang is just so much better than Clojure, or honestly anything else. (I'm talking about OTP and Supervisors here, but even the bare Process system is nicer than working with Clojure's CSP implementation)
Plus, because Erlang is also a functional language there isn't any Functional/OOP friction when interfacing with the native VM or with Erlang libraries. It's turtles all the way down, which I really appreciate after many times getting stuck in the mire of Java/OOP that lurks beneath the surface of Clojure.
Oh, and Phoenix blows any of the Clojure web systems out of water. It's awesome.
> Oh, and Phoenix blows any of the Clojure web systems out of water. It's awesome.
Are you referring to performance, or api design? In clojure there is almost no http apis by design, you're supposed to hook a library that follows the ring spec so it's not a nice comparison imho.
Right, and that's the bit I'm not keen on. You either end up with a totally bespoke stack of libraries for each project, importing the same boilerplate for basic things like csrf-protection, or you have Luminus vomit a bunch of code on disk and then you have to pick through the project and get rid of the stuff you don't want.
Then you realize that much of the code in the Luminus scaffold is managing state with mount (used to be with Component), and that's just a poor imitation of OTP from the Erlang world.
I dunno, I've been there, done that, and wasn't so fond of it. Phoenix, by contrast, strikes me as the right balance of lightness and pragmatism, with first-class support for managing stateful resources in a sane way (OTP mofos), and all the right defaults so I can be productive from day-zero on a new project.
[EDIT: to clarify, the Clojure way isn't _wrong_, and I do see the merit, but in my experience I prefer how things work out with Elixir and Erlang]
It's not a coincidence, Clojure was a big influence on Elixir... I think actually it's a bit of a funny parallel with Ruby, I know Matz has said the biggest influences on Ruby were Smalltalk, Lisp (or eLisp via Emacs) and Perl, and Elixir has a similar relation to Ruby, Clojure and Erlang (I think Jose has talked about this somewhere also).
I was very interested in Clojure and studied it for awhile. I liked it a lot, but had a difficult time becoming proficient with it. Part of it was the tooling (I tried learning Emacs and Clojure simultaneously when I should've only focused on Clojure), but my biggest hurdles were the syntax and understanding the error stack traces. They just seemed way too opaque. This really slowed down my progress. On the flip side, when I picked up Elixir, I became productive very quickly. Studying Clojure actually helped a lot here because I was familiar with functional programming and immutable data, but Elixir's familiar syntax and easier to understand error messages made it much easier for me to grok. I've since built a few things in Elixir and have been very happy with it.
I've heard great things about it and currently have both of those books under my Christmas tree. One discussion I have had often recently is the split in the web community that appears to be emerging. Around (Less than in my opinion) half of the community seems to be going the way of full oo while the rest are going fp. Personally I feel fp is the right direction and will quickly become the new hot item
You'll find that Elixir/Erlang is a mix of FP and OO at the end, which is why I find it amazing. While people debate FP vs OO, it takes the good parts of both.
You can read more about the OO aspects of Erlang from the author himself: http://tech.noredink.com/post/142689001488/the-most-object-o...
Thanks for the reply! That is a good point. I guess my original intent was strict oo (ex: typescript) that takes away the quazi FP properties js has. Very excited for elixer though
Elixir itself ships with a module called EEx that should feel very familiar if you've used Ruby's ERB. There's also a HAML rendering library (Calliope) among others.
It sounds like fun to use Elixir for the entire codebase. I played around with it briefly for fun. My favorite parts were pattern matching and |>. I never got to streams though.
Is the app public? (If you don't want to mention its homepage, I'll understand since it's your employer.)
We just received notification this morning that we can start running ads and pushing marketing. The app is only available in two areas right now, but we're working hard to bring it to everyone.
Programming languages, being technologies, are subject to the Lindy effect (https://en.wikipedia.org/wiki/Lindy_effect).
This means that the younger a language is, the lower its life expectancy. This is why the neomania in JavaScript framework
land is so chaotic. Even if a better framework emerges and takes off in popularity over a few months, it's unlikely to last in
the mainstream for another year. When I'm choosing something to study programming-wise, I use
this heuristic as part of the decision-making process. For example, studying algorithms and data structures is more robust
than studying Vue.js or GraphQL, which are not likely to be around in a few years.
Elixir was just released 5 years ago, and despite some success, has not taken off as much as the absolute top programming languages released around that
time. For example, Go, released just 2 years earlier, is by far the most successful of new languages from the last 10 years.
Given my skeptical mindset towards neomania, it might surprise you to hear that I'm a huge proponent of Elixir!
Here are my reasons for studying Elixir and using it exclusively for my non-work projects, despite there being
countless other recent, appealing languages:
- Although the language is young, it's built on Erlang, which is 30 years old. Even if Elixir fails, there is a lot
of knowledge transfer between the two languages (probably 90% of what I learn from using Elixir transfers directly over
even if I switch to exclusively Erlang).
- Elixir is quite a bit different from other languages I'm familiar with. It's compiled and functional, has powerful
pattern matching, uses lightweight processes and the actor model, and comes with OTP, a complete set of tools that I can use for free.
This means even if/when the language dies, I've added a lot of new skills to my programming toolbelt.
To anyone that has decided, like I have, that Elixir is worth putting some time into learning, I'd like to recommend the book Elixir in Action (https://www.manning.com/books/elixir-in-action)
and the blog of the author of that book, which has infrequent but outstanding posts (http://theerlangelist.com/).
> Programming languages, being technologies, are subject to the Lindy effect (https://en.wikipedia.org/wiki/Lindy_effect). This means that the younger a language is, the lower its life expectancy.
This is a really valuable point. My personal rule of thumb has been that every hardware or software technology takes 5 years to mature: it will useful long before then, but it take years for all the issues to be found and fixed and the ecosystem to fill out, so if you invest before the 5 years, expect less than perfection. Equally, if a technology does not seem to be maturing after 5 years in the field, it's probably not going to happen.
My personal long-term bet is Rust. It is an incredibly well-run project with a superb community, it has use cases that few other languages can fill, and I think that it has potential beyond it's currently defined position as a "systems language" (if you can write business applications in Swift, why not Rust?). Even if I'm wrong, it fills the criteria of being a programming language that is changing how I think about programming, so it will be a valuable experience.
> Erlang has this sort of huge cognitive overload with it's syntax, making it take longer to learn, for no obvious benefits.
Actually the adoption is quite good considering there is no industry giant backing it. There are plenty of companies using it in production and there is a job market for it.
Comparing the adoption with Go/Swift is a bit unfair.
The thing that I'm finding is that Elixir and Go have a direct correlation in many many areas. The biggest impediment to Elixirs adoption has been Go and specifically Google. The Google name helped tremendously with Go adoption.
What I'm finding is that every justifiable reason for using go outside of portable binaries...is that Elixir is the option I would have preferred or is simply a better fit. So much Go adoption came from concurrency needs of Ruby, Python and PHP Devs at a time when Elixir just wasn't ready yet.
The staying power of Elixir despite not being backed by Google or first to market here gives me great confidence. If nothing else, Elixir is educating a lot of people about what makes Erlang so good...and once you understand Erlang/BEAM you see everything that's missing everywhere else. Without learning it, you've got an ignorance is bliss situation.
We just released our software into two markets on the 1st of this month, and plan to release into markets nationwide beginning early 2017. I'm compelled to secrecy until then, but yes, I do plan on doing a thorough write-up of our product and our experiences with Elixir.
I'm having a lot of fun with it, can't wait for winter vacation to build stuff :)
There's a lot of niceties you get out of the box (mix is pretty nice and the testing framework is included, the REPL is good, love that they improve the error messages and consider an unclear error message a bug). I'm already used to pattern matching from Prolog so that's a great plus (I wanted to use Erlang initially but Elixir has won me over). I also feel like I'm thinking in a functional way much clearer (I'm using the PragProg book and this video tutorial https://bigmachine.io/products/take-off-with-elixir/ which both stress it, both resources highly recommended).
Once I start dipping into OTP I'm sure I won't be looking back anytime soon. It's been a while since I was this excited about a language.
Phoenix (web framework) is also pretty awesome. The abstraction of chaining a request through a bunch of functions to generate a response is very fitting. Plugs make sense.
I've just recently started learning Elixir and have really been enjoying it.
Subjectively speaking, I really like the terse yet expressive syntax. It's also nice to have a smaller codebase.
There's an awesome package that creates HTML docs out of your comments. It's really useful for creating documentation on the fly. Elixir's official docs are made this way.
I've been a long time Rubyist (10 years now) and I'm really enjoying Elixir. What got me hooked was the simple syntax and wonderful documentation, both from the project itself and in the Programming Elixir and Programming Phoenix books.
The ease of navigating an Elixir project is a huge benefit. If I want to know where a function is defined, it's very easy to find it. There's none of this class-reopening or meta programming malarkey that you get in Ruby (where is a Rails controller's render method defined exactly?)... it's all right there in the module.
Another thing that I love is that it's trivial to separate processing of several pieces of data into separate Elixir processes. To do something similar in Ruby, I would probably need to either use concurrent-ruby or spin them off into a background job with Sidekiq. In Elixir, it's baked right in.
Elixir is well-designed, the community is very friendly and it's just a pleasure to develop in.
> The ease of navigating an Elixir project is a huge benefit. If I want to know where a function is defined, it's very easy to find it. There's none of this class-reopening or meta programming malarkey that you get in Ruby (where is a Rails controller's render method defined exactly?)...
I would view Elixir as an improvement (iteration?) of Ruby built on Erlang. The article points out it was written by Jose Valim . It derives its structure from the documented shortcomings of both parent languages.
Other than some superficial syntax similarities, I find Elixir to be nothing like Ruby. Pattern matching, immutability, OTP, and the actor model feel like building blocks from a whole different universe.
I think this is very important. GGP wrote about Elixir's simplicty, but it's important to note that this simplicty is at risk whenever macros are involved. That said, I personally haven't had any issues with overly complex macros, but YMMV and macros certainly do open the doors to immense complexity. I do appreciate how Elixir tries to make them harder to write than normal functions, as if to say "are you sure you want to risk making this unclear instead of doing this another way?"
Just anecdotal evidence but I've been running Elixir in production for half a year now for an app called Sleeperbot (95% of our backend is written in Elixir)
Our websocket endpoints, our app servers, and other services all run on Elixir, and pretty much without any incidents.
Erlang/OTP is battle-tested and it's really the first time I could comfortably sleep at night without worrying about stuff going down. Personally I think Elixir past the point of just having "potential" and is my default go-to language to solve any problem as long as it makes sense to solve it with Elixir.
Hey I don't personally use sleeperbot, but I play fantasy bball. "Is there a basketball equivalent of sleeperbot?" is a very common question, so I assume you're doing something right.
Just curious, what other languages/frameworks have you tried in backend? Are you running Phoenix?
Here is a repost of a comment I made a while ago about why I love Elixir:
The thing that constantly gets me about Elixir and Phoenix is the default tends to be the correct way of doing it. Let me explain.
For example, the other day, I was looking at filtering a next parameter to remove the domain (for security- you could redirect someone to fake login box on your host after they log in)... however it's unnecessary as redirect/2 in phoenix if passed a URL rather than a path will throw an error by default. As an aside different exceptions will return different HTTP error codes - for example a database not found exception from Ecto will cause a 404. There are hundreds or thousands of these little decisions that are the correct/simpler decision.
Elixir and Phoenix, for want of a better way of saying it, show great programming taste. So to say it's a coat of paint is a bit harsh; it's the right coat of paint, in my opinion.
I have not used Erlang or Elixir, and wanted to start with Elixir (I want some experience with a functional language, I'm to biased with Java to use Scala as a functional language). However, I read somewhere that Elixir can be successfully used only with Phoenix if you don't know Erlang. As I understood, sooner than later interactions with Erlang libraries is needed, and that requires Erlang knowledge. Can somebody please confirm? That Elixir is basically oriented around Phoenix and Erlang is a requirement?
I'm not sure who told you that, but it's patently false. Phoenix is just another OTP application, you can build a Phoenix app without knowing Erlang at all. It is a practical reality that you will eventually dig into Erlang to some degree, but I wouldn't say it's a requirement by any means. Perhaps what was meant is that you will need to understand OTP, the Erlang standard library (because Elixir avoids wrapping it as much as possible), and some of the semantics of Erlang interop such as the binaries vs charlists, the use of records instead of structs, etc. For just getting started though, much of that can be avoided, and you can tackle it as the need arises.
Thanks. I'm not sure where I read, it was probably some article or comment here on HN. That's what I wanted to hear, it is possible to attend to those issues on-the-fly.
I think the Erlang question is misleading perhaps, because using erlang functions in elixir doesn't actually involve/require learning erlang... any erlang function is available to call directly from Elixir, generally just namespaced under an atom, like :crypto.block_decrypt(:aes_cbc256, key, iv, cipehrtext)
You don't have to "know erlang", just read some docs and make a slightly different syntax function call.
Start with elixir. The syntax is easy enough to learn. Once you get the hang of it learning erlang will be quite simple. You won't be a pro but you'll be able to look at a file and get the basic idea of what it does. Besides syntax they are very similar module-based languages.
The sheer magnitude of the astroturfing I see for elixir has dissuaded me in the past.
On top of that, the erlang vm has long been weak on heavy technical and numeric work and its really only ever been suitable for soft realtime telecom stuff.
Elixir is just a (worse) syntax over erlang, with shoehorned macros and obnoxious begging-for-attention-from-ruby-users language sugar.
Not to say that elixir won't succeed in the long-term, since we are talking about programmers that used to think rails was a good idea, but I guess it's just a shame that the path forward is a path through broken glass, barefooted.
Elixir is definitely interesting and one to keep an eye on. But I'd guess that for startups to use this, is still very risky especially at this stage. You may likely run into scenarios where you need some library/package and you can't find one for it and that could be a potential deal breaker for some startups.
I'm interested to hear though, can anyone care to comment on their experiences with Elixir's package ecosystem? How much developed is it and/or how much more to go to be suitable for most major projects?
Elixir's package ecosystem is quite good. The advantage Elixir has is that using an Erlang package in your Elixir codebase is very very easy and the same as using any other elixir package.
We are using Elixir for more than a year now at work and in almost all cases where we couldn't find a Elixir lib we found an Erlang one.
I think that the package ecosystem is well developed, and getting better every day. For the most common things, there's already packages out there. You want to talk to a database? Use Ecto. You want to check code quality? Use Credo. You want to respond using JSONAPI? Use ja_serializer. You want to talk over HTTP to something? Well there's two main options out there (HTTPotion and HTTPoison).
After all that if you can't find a package that suits your needs then it's very easy to create one. "mix new (your project)" and away you go.
That's what I did with my elastic package (https://github.com/radar/elastic) when I couldn't quite find something that suited my exact needs. There's Elastix and Tirexs out there (those are the ones I know of) but neither really suited what I needed, so I just built my own.
I don't know how it could be a deal breaker if a package didn't exist already. I'd encourage you to build whatever you don't find already existing and contribute back to the community.
Man, there are things I like about Ecto but for anything beyond simple selects the documentation is lacking and the experience is kind of painful.
As an example, I hit the issue recently where a changeset wouldn't accept nil for a relation via put_assoc. That seemed like an very trivial problem to be hitting for a project that's been around so long. And I hit a number of issues that had that sort of feeling.
Another thing was that, if you update a thing with new relation data, you have to force-reload the relationships from the database again. That was pretty surprising and seemed like it should be unnecessary.
I think there's room for an Ecto alternative that tries to be a bit less fancy and gains a lot because of it.
Working with Elixir professionally for year and the half, having deployed more than one app on production I can honestly say, that it's just awesome. Not a silver bullet, will not solve your problems, but the way it makes you think is great. It's been the most impactful and satisfying learning experience of my short career.
I am a self taught Ruby/Rails developer who has recently started dipping my toes in the world of Elixir and Phoenix.
I am having a lot of fun as I find it to be a refreshing approach to web development.
Elixir's guide is quite exhaustive. You can easily start building a toy app over a weekend.
I have open sourced the source code for my blog/web-shop that I built using Elixir/Phoenix. I am not an Elixir expert and this is not the best written Elixir app, but if anyone wants to look at the code for a simple CMS and shop built with Elixir and Phoenix, here is the link - https://github.com/authentic-pixels/ex-shop.
Read the blog post and then the thread, and was really starting to get excited at the prospect of using elixir. Then i wondered what was the pace of adopting new technologies in elixir, and found this thread about http2 support (which started to gain adoption last year, and increase peroformances a lot)
So, for a language that's primarely based around webserver, i find it really woorying that http2 support wasn't a primary concern, and depends on donation to a third party developper...
I guess it means the language is still young and so is the ecosystem.
That's a loaded question because it's not built for performance, although it's still very fast. It's built for realtime and consistent performance specifically.
The trade off there is prescheduling, where the VM caps execution time of processes in the scheduler guaranteeing that a heavy process isn't allowed to take over the machine VS cooperative scheduling where the code has to periodically check in with the scheduler to relinquish control.
Prescheduling won't be faster in a benchmark, but if you have millions of small requests their response time will remain consistent in the face of bad actors or infinite loops trying to takeover the machine.
The benchmarksgame's site quotes "Most (all?) large systems developed using Erlang make heavy use of C for low-level code, leaving Erlang to manage the parts which tend to be complex in other languages, like controlling systems spread across several machines and implementing complex protocol logic."
It's great to see another PHP/Js developer enthusiastic about Elixir. Usually it seems PHP devs pick Go as their next stack / interest.
The Ruby-inspired syntax have helped the language to gain traction amongst Rails developers but for somebody like me who only exposure to Ruby is Capistrano it doesn't do much.
109 comments
[ 4.2 ms ] story [ 143 ms ] threadAside from that... Elixir feels really fun. Maybe it's a silly metric, but that's just my biased opinion.
The last feature that caught my attention was their deployment tools. I haven't used em yet, but based on a conference video I watched, it looks like they have pretty sweet setup. They claim to have very easy zero downtime upgrades / downgrades. And I think preparing a release automatically bundles dependencies, so everything is contained in a single compressed file.
I'd argue that from a hacker's perspective, this is the most important metric. It's what keep you returning to the language, and what gives it vi(r|t)ality. Don't underestimate fun!
When I started learning I didn't understand why I had to use a different operator for string concat vs numerical addition and the Dialyzer talk from ElixirConf explained it very well.
I've yet to touch Elixir (or Erlang, for that matter). Does anyone have experience using both? Thoughts? Has anyone crossed from one language to the other over any strong preference?
Still you need to understand the whole process and OTP deal.
You still have to bend your thinking, yet, you feel that you become productive much faster.
1. My brain thinks in terms of editing lines, not s-expressions; I didn't get the hang of paredit, and editing without paredit required really tedious edit operations.
2. Elixir's understanding of types matches Erlang's and the host VM, while Clojure invents its own uni-typed IObj but runs on a typed VM. Interop with Java required adding type annotations. Elixir/Erlang interop seems to be almost entirely pain-free.
3. Elixir has a lot of syntax niceties like triple-quoted strings that automatically remove indents. And pattern matching everywhere.
4. I can feasibly (and in fact, have) audited and built all of my Elixir and Erlang dependencies from git repositories, while doing the same with the Maven dependencies needed for a typical Java project would be almost impossible. I wouldn't even know where to begin with bootstrapping all the necessary Maven plugins.
5. Elixir/Erlang has per-process garbage collection and memory limits, though I haven't taken advantage of these yet.
In my experience, learning and then working in Common Lisp, starting with paredit is tough. I disabled paredit for a while until I got the hang of thinking in s-expressions as you say. After a while when I tried paredit again, it was glorious.
Early on I did set up % as a global key that goes to the matching parenthesis if on parenthesis, and otherwise inserts the character typed.
Also, I hope you were setting https://www.emacswiki.org/emacs/ShowParenMode
Just my 2¢.
For instance to move an expression: put cursor on one parenthesis, type v for visual select, type % to jump to the other paren, then x to delete. Move somewhere, p to paste. Adjust formatting here and there, done.
I edit C and other languages in pretty much exactly the same way.
Yes, I've been doing Clojure for maybe four years, and picked up Elixir over the course of 2016. Frankly, I think I'll be preferring Elixir over Clojure for most tasks from now on.
The concurrency/parallelism story in Elixir/Erlang is just so much better than Clojure, or honestly anything else. (I'm talking about OTP and Supervisors here, but even the bare Process system is nicer than working with Clojure's CSP implementation)
Plus, because Erlang is also a functional language there isn't any Functional/OOP friction when interfacing with the native VM or with Erlang libraries. It's turtles all the way down, which I really appreciate after many times getting stuck in the mire of Java/OOP that lurks beneath the surface of Clojure.
Oh, and Phoenix blows any of the Clojure web systems out of water. It's awesome.
Are you referring to performance, or api design? In clojure there is almost no http apis by design, you're supposed to hook a library that follows the ring spec so it's not a nice comparison imho.
Then you realize that much of the code in the Luminus scaffold is managing state with mount (used to be with Component), and that's just a poor imitation of OTP from the Erlang world.
I dunno, I've been there, done that, and wasn't so fond of it. Phoenix, by contrast, strikes me as the right balance of lightness and pragmatism, with first-class support for managing stateful resources in a sane way (OTP mofos), and all the right defaults so I can be productive from day-zero on a new project.
[EDIT: to clarify, the Clojure way isn't _wrong_, and I do see the merit, but in my experience I prefer how things work out with Elixir and Erlang]
Read more here https://www.bignerdranch.com/blog/elixir-and-io-lists-part-1... and in part 2.
Is the app public? (If you don't want to mention its homepage, I'll understand since it's your employer.)
Here's the website for more information: http://goskip.com.
Elixir was just released 5 years ago, and despite some success, has not taken off as much as the absolute top programming languages released around that time. For example, Go, released just 2 years earlier, is by far the most successful of new languages from the last 10 years.
Given my skeptical mindset towards neomania, it might surprise you to hear that I'm a huge proponent of Elixir! Here are my reasons for studying Elixir and using it exclusively for my non-work projects, despite there being countless other recent, appealing languages:
- Although the language is young, it's built on Erlang, which is 30 years old. Even if Elixir fails, there is a lot of knowledge transfer between the two languages (probably 90% of what I learn from using Elixir transfers directly over even if I switch to exclusively Erlang).
- Web applications are a fantastic use case for the Erlang VM (BEAM). Take a look at this article (https://joearms.github.io/2016/03/13/Managing-two-million-we...) by Joe Armstrong, one of the creators of Erlang, written earlier this year.
- Elixir is quite a bit different from other languages I'm familiar with. It's compiled and functional, has powerful pattern matching, uses lightweight processes and the actor model, and comes with OTP, a complete set of tools that I can use for free. This means even if/when the language dies, I've added a lot of new skills to my programming toolbelt.
To anyone that has decided, like I have, that Elixir is worth putting some time into learning, I'd like to recommend the book Elixir in Action (https://www.manning.com/books/elixir-in-action) and the blog of the author of that book, which has infrequent but outstanding posts (http://theerlangelist.com/).
This is a really valuable point. My personal rule of thumb has been that every hardware or software technology takes 5 years to mature: it will useful long before then, but it take years for all the issues to be found and fixed and the ecosystem to fill out, so if you invest before the 5 years, expect less than perfection. Equally, if a technology does not seem to be maturing after 5 years in the field, it's probably not going to happen.
My personal long-term bet is Rust. It is an incredibly well-run project with a superb community, it has use cases that few other languages can fill, and I think that it has potential beyond it's currently defined position as a "systems language" (if you can write business applications in Swift, why not Rust?). Even if I'm wrong, it fills the criteria of being a programming language that is changing how I think about programming, so it will be a valuable experience.
Actually the adoption is quite good considering there is no industry giant backing it. There are plenty of companies using it in production and there is a job market for it.
Comparing the adoption with Go/Swift is a bit unfair.
What I'm finding is that every justifiable reason for using go outside of portable binaries...is that Elixir is the option I would have preferred or is simply a better fit. So much Go adoption came from concurrency needs of Ruby, Python and PHP Devs at a time when Elixir just wasn't ready yet.
The staying power of Elixir despite not being backed by Google or first to market here gives me great confidence. If nothing else, Elixir is educating a lot of people about what makes Erlang so good...and once you understand Erlang/BEAM you see everything that's missing everywhere else. Without learning it, you've got an ignorance is bliss situation.
We just released our software into two markets on the 1st of this month, and plan to release into markets nationwide beginning early 2017. I'm compelled to secrecy until then, but yes, I do plan on doing a thorough write-up of our product and our experiences with Elixir.
There's a lot of niceties you get out of the box (mix is pretty nice and the testing framework is included, the REPL is good, love that they improve the error messages and consider an unclear error message a bug). I'm already used to pattern matching from Prolog so that's a great plus (I wanted to use Erlang initially but Elixir has won me over). I also feel like I'm thinking in a functional way much clearer (I'm using the PragProg book and this video tutorial https://bigmachine.io/products/take-off-with-elixir/ which both stress it, both resources highly recommended).
Once I start dipping into OTP I'm sure I won't be looking back anytime soon. It's been a while since I was this excited about a language.
Phoenix (web framework) is also pretty awesome. The abstraction of chaining a request through a bunch of functions to generate a response is very fitting. Plugs make sense.
tl;dr: Try it!
Subjectively speaking, I really like the terse yet expressive syntax. It's also nice to have a smaller codebase.
There's an awesome package that creates HTML docs out of your comments. It's really useful for creating documentation on the fly. Elixir's official docs are made this way.
I'm about halfway through a course I think is very good for beginner-level programmers (https://www.udemy.com/the-complete-elixir-and-phoenix-bootca...).
Elixir School is also a good resource.
Phoenix shows a lot of promise too, I haven't taken to JS so it would be good not to have to use it as much as possible.
I signed up for the digest there and it's one of the few "bulk" emails I get that I actually read.
The ease of navigating an Elixir project is a huge benefit. If I want to know where a function is defined, it's very easy to find it. There's none of this class-reopening or meta programming malarkey that you get in Ruby (where is a Rails controller's render method defined exactly?)... it's all right there in the module.
Another thing that I love is that it's trivial to separate processing of several pieces of data into separate Elixir processes. To do something similar in Ruby, I would probably need to either use concurrent-ruby or spin them off into a background job with Sidekiq. In Elixir, it's baked right in.
Elixir is well-designed, the community is very friendly and it's just a pleasure to develop in.
I would view Elixir as an improvement (iteration?) of Ruby built on Erlang. The article points out it was written by Jose Valim . It derives its structure from the documented shortcomings of both parent languages.
http://elixir-lang.org/getting-started/meta/macros.html
Check out the Foreword section.
Our websocket endpoints, our app servers, and other services all run on Elixir, and pretty much without any incidents.
Erlang/OTP is battle-tested and it's really the first time I could comfortably sleep at night without worrying about stuff going down. Personally I think Elixir past the point of just having "potential" and is my default go-to language to solve any problem as long as it makes sense to solve it with Elixir.
Just curious, what other languages/frameworks have you tried in backend? Are you running Phoenix?
The thing that constantly gets me about Elixir and Phoenix is the default tends to be the correct way of doing it. Let me explain.
For example, the other day, I was looking at filtering a next parameter to remove the domain (for security- you could redirect someone to fake login box on your host after they log in)... however it's unnecessary as redirect/2 in phoenix if passed a URL rather than a path will throw an error by default. As an aside different exceptions will return different HTTP error codes - for example a database not found exception from Ecto will cause a 404. There are hundreds or thousands of these little decisions that are the correct/simpler decision.
Elixir and Phoenix, for want of a better way of saying it, show great programming taste. So to say it's a coat of paint is a bit harsh; it's the right coat of paint, in my opinion.
On top of that, the erlang vm has long been weak on heavy technical and numeric work and its really only ever been suitable for soft realtime telecom stuff.
Elixir is just a (worse) syntax over erlang, with shoehorned macros and obnoxious begging-for-attention-from-ruby-users language sugar.
Not to say that elixir won't succeed in the long-term, since we are talking about programmers that used to think rails was a good idea, but I guess it's just a shame that the path forward is a path through broken glass, barefooted.
I'm interested to hear though, can anyone care to comment on their experiences with Elixir's package ecosystem? How much developed is it and/or how much more to go to be suitable for most major projects?
We are using Elixir for more than a year now at work and in almost all cases where we couldn't find a Elixir lib we found an Erlang one.
If you can't find a package then you could try looking it up at https://github.com/h4cc/awesome-elixir or asking on the elixir slack (https://elixir-slackin.herokuapp.com/) or on the #elixir-lang channel on Freenode.
After all that if you can't find a package that suits your needs then it's very easy to create one. "mix new (your project)" and away you go.
That's what I did with my elastic package (https://github.com/radar/elastic) when I couldn't quite find something that suited my exact needs. There's Elastix and Tirexs out there (those are the ones I know of) but neither really suited what I needed, so I just built my own.
I don't know how it could be a deal breaker if a package didn't exist already. I'd encourage you to build whatever you don't find already existing and contribute back to the community.
As an example, I hit the issue recently where a changeset wouldn't accept nil for a relation via put_assoc. That seemed like an very trivial problem to be hitting for a project that's been around so long. And I hit a number of issues that had that sort of feeling.
Another thing was that, if you update a thing with new relation data, you have to force-reload the relationships from the database again. That was pretty surprising and seemed like it should be unnecessary.
I think there's room for an Ecto alternative that tries to be a bit less fancy and gains a lot because of it.
I am having a lot of fun as I find it to be a refreshing approach to web development.
Elixir's guide is quite exhaustive. You can easily start building a toy app over a weekend.
I have open sourced the source code for my blog/web-shop that I built using Elixir/Phoenix. I am not an Elixir expert and this is not the best written Elixir app, but if anyone wants to look at the code for a simple CMS and shop built with Elixir and Phoenix, here is the link - https://github.com/authentic-pixels/ex-shop.
Here is a link to the live website - https://www.authenticpixels.com/
https://github.com/elixir-lang/plug/issues/258
So, for a language that's primarely based around webserver, i find it really woorying that http2 support wasn't a primary concern, and depends on donation to a third party developper...
I guess it means the language is still young and so is the ecosystem.
Elixir leverages Cowboy quite a bit and HTTP2 requires substantial rewrite of Cowboy.
This will be completed in the release of Cowboy 2.0
If you want to read why Cowboy needs to be majorly refactored, read the link below
https://ninenines.eu/talks/cowboy-2/#/
The trade off there is prescheduling, where the VM caps execution time of processes in the scheduler guaranteeing that a heavy process isn't allowed to take over the machine VS cooperative scheduling where the code has to periodically check in with the scheduler to relinquish control.
Prescheduling won't be faster in a benchmark, but if you have millions of small requests their response time will remain consistent in the face of bad actors or infinite loops trying to takeover the machine.
For this web framework test Phoenix (Elixir) does almost as well as Play (Java) https://github.com/mroth/phoenix-showdown
The benchmarksgame's site quotes "Most (all?) large systems developed using Erlang make heavy use of C for low-level code, leaving Erlang to manage the parts which tend to be complex in other languages, like controlling systems spread across several machines and implementing complex protocol logic."
So it depends I guess.
The Ruby-inspired syntax have helped the language to gain traction amongst Rails developers but for somebody like me who only exposure to Ruby is Capistrano it doesn't do much.