For folks who have switched over, what are the things you don't like about Elixir?
edit: nm, plenty of discussion on this in the Elixir 1.3 thread: https://news.ycombinator.com/item?id=11945389
1) Erlang's (and by extension Elixir's) persistent data structures are great but there are times when (for performance reasons) they're completely unusable and you have to resort to things like using ETS or spawning a process for each value you want to store. There are times when I would kill for something like Clojure's transients.
2) The syntax has some weird edge cases, particularly around first-class functions. For example, having to call closures as "closure.(arg1, arg2)" rather than "closure(arg1, arg2)" or having to (seemingly) immediately invoke a lambda to make it fit in a pipeline like "7 |> (&(&1 * 2).())". I know WHY those two bits of ugliness exist but it doesn't really make me any happier about them.
3) The BEAM VM is very much a world of its own, with limited and well-defined entrance/exit points. It's very easy to do anything in Erlang/Elixir that stays inside the VM or communicates via network socket. It's difficult to do things that interact with the host OS or native processes, things that would be trivial in Perl/Ruby/Python.
The reason why none of these are deal-breakers is that I understand that they're the result of tradeoffs, not poor engineering. It would be easy to design a new language that has none of the above problems but it wouldn't have the massive benefits that the BEAM VM gives Erlang and Elixir.
[1] https://github.com/alco/porcelain
Also erlport looks interesting: http://erlport.org/docs/python.html
I don't have nearly the same breadth of exposure to functional languages that you do...I worry (prematurely, of course) that I don't have enough insight to understand what parts of the language are "weird" because I'm new, or legitimately weird, e.g. print-as-a-statement in Python 2 or `==` in Javascript.
Well used languages have large numbers of people complaining about them, because a) change is harder b) more people care about the result, so you get heard more c) they are more likely to be forced by circumstance to use the language.
Reviews of languages are generally a rubbish metric for deciding if it's any good.
While I agree that the nature and value of reviews is highly determined by things not inherent to the quality of the language (which is to be expected for anything that deals with the real-world), I do think reviews of nascent languages have significantly higher signal to noise ratio than they do for languages that are at their peak or heading towards legacy land:
1. New languages are rarely used by novice programmers. Which means that they are rarely written about by novice programmers. Doing a search for "state of Ruby/Node" requires a lot of work to find reviews authored by experienced developers who have a clear mindset (i.e not just personifying a shallow version of Bjarne Stroustrup's famous axiom), while filtering out everyone who just got out of coding bootcamp and has a good Medium presence.
2. The fact that a language is new means that nearly everyone, except for the creator and early dogfooders, is new to it, which means they come to it with roughly the same perspective (and needs and wants) as anyone who is curious to jump in. Moreover, they are often wont to compare the new language with whatever language they've been using, which helps as a metric for gauging the experience level and judgment of the reviewer.
Sure, there's the problem of early adopters not wanting to shit on a language before it is stable...on the other hand, the kind of people who like to try out languages before they hit saturation are generally opinionated and will make critiques as way to help influence the language, so it's not a total whitewash.
Speaking for myself, reviews are not my first metric for judging a new language or framework. Understanding why it was created and how it is currently doing in production is by far the most important thing to me. Even though React felt very strange to me and many others at first, I still gave it the benefit of the doubt knowing that it was being used in Instagram and Facebook.
This is why I don't trust new languages. Everyone starts off as newbies who do not know what they are doing and will struggle to develop best practices. These programmers are just going to make new mistakes...that they won't realize until after the language reaches legacy status and are forced to clean up their mess.
Elixir for example uses Erlang data-structures, and semantics for code execution, and functional calls/naming/parameters.
Elixir is an impure dynamic functional language where IO operates on its own green-threadlike process. This is from Erlang as well, but the concept of dynamic languages, and functional languages is not a new one. Neither is the concept of hygienic macros. Elixir is simply a very good implementation of such.
I'd want to see significant commercial support, a genuine need, library support, some code samples among other things at least.
I think most languages don't have a genuine need - i.e. why would I use them instead of another language. This has to be compelling enough to get over the learning curve.
That is absolutely mind-blowing. Can you explain a little more about what is causing that? Are there lots of HTTP calls or something? What machine is this running on?
(I'm not a Ruby dev, but I have heard Ruby is slow.)
At the edge, performance relies heavily on implementation, and the ErlangVM is great at dealing with high concurrency, and methods that do small pieces of work. If your implementation works against that, then the VM is going to work against you as well because it was designed with those assumptions in mind.
Elixir however is a very new language. Coming from Python, the first things I noticed was:
1. There's no real consensus on if we should use exceptions or error return types. Support for return types is improving with the new with syntax, so perhaps that's what most people will use. The standard library uses both, and occasionally will just return nil on error.
2. The standard library is still evolving. For example Date/Time/Calendaring was all out of the STL until 1.3, and support is still currently anaemic comparative to Python.
3. Most OTP in the Erlang ecosystem are built in Erlang. Those built in Elixir are derived from some specific use case of some specific company. Language support for OTP constructs is improving though, and more generic forms are being built into the STL for Elixir 1.4, upcoming.
With regards to Phoenix, its a well thought out, throughly implemented library.... but its not Django; and makes different philosophical choices.
Short list:
1. no user system
2. no authentication or permissions
3. templates do not follow the engine/loader structure of Django
4. Plug is like Rack, not like Django middleware so whilst it is more powerful in some respects, it is unidirectional in control flow unlike Django where data flows up/down the chain of middleware.
5. Ecto is a pretty solid database layer, but its not integrated into Phoenix at all because #1/#2 do not exist, and Phoenix doesn't have a admin layer at all... so there's no real reason for the framework itself to tie itself to a single database layer. So you get into a situation that's akin to using SQLAlchemy with Django. Yes it works, no this library wasn't built for your framework.