Even with that, it's still difficult for them to recruit.
You can't hire or rent devs that know Erlang without a multi-month search in most markets. This is a non-starter for most businesses.
Train them on Erlang yourself? Why? Any possible productivity benefits offered by Erlang over a more mainstream option are dwarfed by training and hiring costs.
Nobody gives a shit about hot code patching in real business systems; the telco switch architectures which demanded such features are basically bonkers and unnecessary in a packet-switched world.
The 'banking industry' is huge. While what you say is true in many parts of the banking industry, I also know people in the banking industry for example who write and use an in-house DSL written Haskell for their day to day work.
I have been a Python developer since 2006/2007 and every time I depart to another community for a while, I return with a ton of new ways to think about problems. Not only that, you'll usually have a newfound appreciation for things in Python you might not have really cared about before (eg decorator syntax)
- Becoming a Rails developer was a game changer. The Pythonistas tout it to be 'magic', but it's really not. It's easy to understand what is going on. Once you use a tool like Rails in more advanced situations – every Python web framework looks like a horse drawn carriage.
- On a related note, reading Eloquent Ruby was one of the most epic nonfiction reading experiences of my life. After reading that book, I rarely see "programming magic" to be magic anymore. I understand it all. A lot of the knowledge from that book translates well to Python too, since Python and Ruby are very similar.
- Learning Clojure and using it day-to-day at FarmLogs has made me think more functional than I did previously.
It's usually not just the language that is going to open your mind - but the frameworks, tools and communities that grow around the language. It's like visiting a new country. You're gonna love certain customs and dislike others.
Anyway... saying you don't have time for something that will open your mind and make you a better programmer sounds like a grumpy old man who's missing out on the world.
So, yes, learning is good. But we are still finite beings with limited time. Having priorities about what you will spend your time learning, and choosing Elixir to not be one of those priorities, is a legitimate stance. Thanks for sharing.
Whether you use the other language doesn't mean there is no benefit to learning it
This is a very limiting view of the programming space and world in general, hopefully with time you will understand that learning a new language will only help you to get better in your old language. You don't need to invest years in a new language to get the gist of it.
It's already an issue with Erlang. It's made 10 times worse with Elixir.
Pick something proven.
I worked in a Scala shop and people spent tons of time flailing about arguing over syntax, dealing with bad IDE plugins / slow tools, etc. They'd have been better off just sticking with Java.
I've done a decent amount of Elixir in prod over the last year and a bit and I've found the lack of a decent, modern static type system pretty frustrating. I love the idea of failing fast, but most of the time we're throwing 500s from trivial developer mistakes (and yes, we do TDD). Lazily evaluated libraries like Streams or Ecto.Multi explode in weird, non-local ways because the types are not checked at the call-site, making refactoring and iterating a chore.
I have tried out Dialyzer, but it lacks many things you would expect from a modern type system (eg. parametric polymorphism). While experimenting with it I've been able to get it to accept trivially broken programs without complaint, which means I've never been really be sure it's got my back, so have given up on it. And yes, this is with the flags ratcheted to their highest settings. Not to mention all the third party libraries who forget to keep their typespecs up to date.
I realise designing a type system that can handle hot-reloading in a cluster is still an open problem (interesting work in progress on this front though), but most folks aren't really at the scale where that is a problem. They'd probably be far better served using a more traditional deployment process while getting the immediate benefits of the improved iteration speed, refactoring confidence, and data modelling that languages with modern type systems provide. The front end is beginning to 'get it' with the likes of Typescript, Flow, Elm, Reason, Purescript, etc, and I can only hope that their good work and excitement will eventually flow back to us on the back-end...
I really have to say it’s been a joy writing the backend for a Bitcoin-related app[1] in Haskell. It took me a while to adapt to Haskell — probably a couple of years or so — but in the end it has left me with such strong compiler guarantees that I can literally grep through my codebase for “error|throw” and see where a 500-error may be thrown by the server.
The only somewhat laborious part is categorizing all the exceptions, that can be thrown when performing requests, into retryable and non-retryable ones, so requests that throw these intermittent, retryable errors are automatically retried (the retry package makes automatic retrying super easy).
This post[2] gets to the crux of how my coding has adapted over the years: getting rid of runtime-decisions (e.g. looking at a Maybe value at runtime to figure out what to), by moving the relevant parameters to the type level, such that program flow is determined at compile-time by which type an operation is parametized over. For example, the app is parametized over two types: DB implementation and Blockchain implementation[3], which makes the compiler construct a program for these specific implementations at compile-time, rather than making it a runtime-decision based on reading a config file at startup.
[1] https://github.com/runeksvendsen/rbpcp-handler
[2] http://www.parsonsmatt.org/2017/04/08/maybe_use_a_type_param...
[3] https://github.com/runeksvendsen/rbpcp-handler/blob/master/s...
Like e.g. Java, Scala, C#?
Any pointers?
Sample size of 1, self selected, your mileage may vary, things in the mirror are closer than they appear. That is, it isn't really meaningful as a data point in isolation.
I only clicked this link out of morbid curiosity, on why someone would make such a presumptuous statement. Put another way, the question asked is heavily loaded. I was more interested in the discussion around the statement, to see what people thought, than the content of the question.
You may have what you and others consider the greatest thing since sliced bread. And you might not fathom why others would not see it that way. After all, it is the greatest thing since sliced bread. It is a dessert topping and a floor wax (obligatory SNL skit reference).
Even with all this, the criteria for success, oddly, rarely has being "the greatest thing since sliced bread" as part of the core elements of being successful. You don't need to be superior to be successful (though I am not stipulating that Elixir is superior, I've never seen it, used it, etc.)
The question is why would people choose this over others? What benefit would this language provide that others simply cannot?
I've used many languages during my professional and educational life. I've never seen one that was universally appropriate for all tasks. I some that fit the majority of tasks I worry about, very well. I've seen others fit very poorly. I have no opinion on Elixir, other than to note a small vocal group wondering aloud how anyone could not use it.
Reminds me of Python in the 90s.
Ok maybe 90% :-)
I think use what fits your brain is the kind of advice that sounds good but does most people a disservice. At work use what allows you to ship high quality code, on time, within the business constraints that you have. But you'll have much better options in your career if you take at least some time to expand your brain so more things fit in it.
On many platforms, the best practice is to have stateless application servers, with separate stateful data stores. On the other hand, the big advantages of Erlang/Elixir are in managing state along with your application logic.
In a vacuum, that can be a big win. But I'm worried that the advantages are not enough to overcome the weight of tooling, services, and best practices built around the stateless model. For example, Heroku explicitly tells you to avoid application state, and Docker is built around a destroy-and-rebuild ethos.
For my project, Elixir/Phoenix is great as a "better Rails", but I know I'm only scratching the surface of the platform's strengths.
I am actually moving components of my apps away from erlang to f# to shield it from the destruction of beam that elixir will bring about.
2/10
I'm a big fan of Erlang and OTP, and really wish for that style of concurrency, failure tolerance and distributed computing. For me, the lack of static typing in Elixir struck me as a missed opportunity from the outset. The Ruby-like syntax isn't enough to change the game for me (I find it significantly less attractive than Ruby, but that's not important), even with macros.
Since I don't use Elixir, the above isn't necessarily a criticism of it -- I'm sure it's great. Just not for me.
Go is what I'm using now, and I've been playing with Rust and will probably start using that when I have a new project. I've been using Haskell for some side projects. I like OCaml a lot, but I won't touch it until multicore support lands and matures. For web projects, my plan is to transition everything from JavaScript to TypeScript, precisely for the type system.
No more dynamically types languages except for scripting.
That said, I built https://gigalixir.com to try and help with some of these issues and improve the deployment story for Elixir.
Elixir has helped us reduce our costs by 1/3 and improve our API response times from 50ms to 5ms. (Ruby -> Elixir)
Using erlang/Elixir processes forced us to reevaluate the way we handle state and were able to find many ways to optimize.
I believe our code is now more organized, extensible and powerful. Our infrastructure is also more complicated, but much more fault tolerant as we have fallbacks for fetching data etc.
Deployment was pretty terrible but a simple scaleable solution with AWS is build with a docker container, push to ECS and launch ECS + ElasticBeanstalk and you're good to go.
However, I don't think anyone else was getting excited about Elixir, or more broadly about functional programming. When it came time to choose a stack for a much bigger project, Go won out. The only specific complaint about Elixir I'm aware of is that ramp up time would be too long every time we bring a new dev onto the project. In hindsight I don't think Go is any different in that regard. A Ruby/JS dev either needs to learn pattern matching, macros, list comprehensions, and a bit of OTP for Elixir, or they need to learn static typing, pointers, goroutines, and idiomatic error handling for Go.
Personally, I'm happy either way. I'd still probably choose Elixir if it were my choice to make, but I'm loving Go too.
There are solutions out there,though documentation may not cover every use-case, especially if you are deploying to something like AWS or GCP (Not everyone can adopt Docker just yet).
The Hot-Upgrade is a great idea though you will have to do your research to integrate this with your Cloud Provider.
Overall I'm betting adoption will be niche, and primarily via Teams coming from Rails. Until a major cloud provider starts offering native support + the community grows to a sizable percentage, it will be slow to catch on.
