I'll be starting to work on a new project from next month and I've been reading all but good news about Elixir. I have talked to people in real life, most of the devs had positive things to say about it. Does anyone have any arguments against selecting Elixir? Question coming from RoR developer.
[+] [-] midrus|4 years ago|reply
We also found many times missing libraries, or found libraries which are incomplete, or unmaintained or just not well documented. Just compare the total amount of libraries in Hex, vs the total amount of libraries in rubygems. Somebody will say "but Elixir libraries are higher quality so we need less, etc,etc" as if there were not good developers in the ruby world and every elixir developer were a rockstar.
Tooling is just terrible. The VSCode plugin is crap, kills the CPU unless you disable features. There is no IDE from jetbrains. There is a plugin but last time I tried it, it was even worse than the VSCode plugin.
Also, I've read some comments where people mention "we don't need redis", "we don't need workers" everything is so much easier. That was our thinking at first. But then you realize on deployments you will lose your cache, or your background jobs, etc. So you have to persist them either in mnesia or in the database. At that point you're just reinventing your crappy undocumented and untested version of delayed_job.
Most of what you get from elixir in terms of redundancy, high availability, etc you can have that anyway from kubernetes, heroku or any PaaS.... you will need more than 1 server anyway, so...
Liveview sounds amazing until you try to use it in the real world. The most minimum latency kills the experience.
In the end, we are back to Rails and much happier. Specially now we are using all the hotwire stuff. Not fancy, and not fashionable though.
[+] [-] pmarino90|4 years ago|reply
I am using VSCode too and the experience is not as good as with Typescript/Javascript but is not that terrible either. I would compare it with Rust's experience, so far.
> Also, I've read some comments where people mention "we don't need redis", "we don't need workers" everything is so much easier. That was our thinking at first. But then you realize on deployments you will lose your cache, or your background jobs, etc. So you have to persist them either in mnesia or in the database. At that point you're just reinventing your crappy undocumented and untested version of delayed_job.
Of course you need _other_ libraries to achieve some of those things. You do not have a queue built it but there are some very good tools like Oban https://github.com/sorentwo/oban that are basically doing what Sidekiq does, just relying on the main database you are already using. There are also very good libraries for caching that rely on ETS and that simply replaces what you could do with Redis.
> Most of what you get from elixir in terms of redundancy, high availability, etc you can have that anyway from kubernetes, heroku or any PaaS.... you will need more than 1 server anyway, so...
This is partially true. The ability of BEAM to cluster and execute processes inside the cluster, internal communication between actors and so on are not _just_ achievable with k8s, not without a good added complexity.
[+] [-] benwilson-512|4 years ago|reply
Maybe I'm missing something, but doesn't this have precisely the same latency characteristics as live view?
I do agree that some of the "you don't need redis" and similar are overblown (particularly claims about tasks replacing background jobs), but I think there is truth to these claims in the following sense: Particularly in Rails, Redis gets used not just as a tool, but also to manage shortcomings in the language / runtime. Eg: Hotwire. Ruby doesn't have a good way to concurrently manage stateful connections, so it has to fallback to Redis. Ruby doesn't have a good way to manage inter-process or inter-node communication, so once again Redis steps in to fill that gap.
There's nothing wrong with using Redis, it's a fantastic tool. Using it as a state holder for an event loop through ends up feeling extremely convoluted after you've written a few GenServers (Phoenix channels / liveview).
[+] [-] josevalim|4 years ago|reply
For what is worth, that's one of the reasons why Elixir exists in the first place. I find the Erlang VM a fantastic platform and there is no reason to restrict it to high availability/distributed scenarios. Elixir developers should be productive and write performant and maintainable applications, even if at the end of the day they are just pushing to Heroku. Especially if you are coming from another dynamic language, such as JS/Ruby/Python.
As I like to say, in the "worst" case scenario, you can use Elixir as you would any other language, and that's completely fine!
If you want/need to go deeper, the abstractions are there to do so, and that's the difference compared to K8s: it is happening one layer inside. The high-level principles of redundancy and availability exist at the library level, so you can look at your connection pool, message queue, http clients, and find the same ideas there. Another area where K8s directly complements Erlang is in helping establish clusters. Overall, they are rather working together rather than stepping on each other toes. I wrote more about this here: https://dashbit.co/blog/kubernetes-and-the-erlang-vm-orchest...
[+] [-] whalesalad|4 years ago|reply
> Tooling is just terrible. The VSCode plugin is crap, kills the CPU unless you disable features. There is no IDE from jetbrains.
This is a bizarre criticism of Elxir the language. There are a lot of developers out there who prefer a more lightweight editor and do not want the bells, whistles and crutches of a heavy duty environment. I would never complain about a language just because an IDE does not exist for it.
Tooling in Elixir is really some of the best I have ever used as far as the consistency had with mix, hex, hexdocs, etc...
> Also, I've read some comments where people mention "we don't need redis", "we don't need workers" everything is so much easier.
You can still use all the same battle tested tools with Elixir... but it is true that there are lots of situations where those things are genuinely not needed thanks to some of the things that come out of the box on BEAM.
[+] [-] lbhdc|4 years ago|reply
We faced similar issues to you, bad tooling, weak libraries, and very few knowledgeable devs.
Finding people to hack on elixir was extremely difficult, and likely the driving force that killed the project. Having an inexperienced team who had no experience with many of the language features elixir offered created a very difficult to work in code base.
This killed productivity, so management threw resources at it. Code quality dropped further when we were no longer just a group of noobs interesting in hacking on elixir, and became a group of noobs begrudgingly hacking on elixir.
I feel pretty scared from the experience, and wouldn't be interested in using elixir professionally again. Which is a shame, it can be a nice language to write, and some of its tooling like hex is quite nice.
[+] [-] minhajuddin|4 years ago|reply
Can you give some examples here. This may have been true in the past, but isn't true anymore. I can give an example where ruby is lacking: Performant HTTP libraries, Elixir and Erlang are so good in this space, look at `finch`, `httpoison` etc,. there is first class support for HTTP2 and connection pooling / persistent connections which is very hard to find in ruby.
> Tooling is just terrible. The VSCode plugin is crap, kills the CPU unless you disable features. There is no IDE from jetbrains. There is a plugin but last time I tried it, it was even worse than the VSCode plugin.
Which plugin are you referring to? Is it using dialyzer? Using dialyzer gives you so much static analysis for free as opposed to the default ruby vscode plugin. I have never heard of complaints about tooling. On the other hand, I know lots of developers who love the tooling, mix is great, iex gives you documentation with just `h String`. Plus with language server support, you have really good IDE support in vscode and vim. Look at the number of stars on the `ElixirLS` plugin here: https://marketplace.visualstudio.com/search?term=elixir&targ...
> Also, I've read some comments where people mention "we don't need redis", "we don't need workers" everything is so much easier. That was our thinking at first. But then you realize on deployments you will lose your cache, or your background jobs, etc.
Yes, you'll lose data in your cache. Caches are supposed to be ephemeral, not everyone needs their caches to be persisted. However, if your use case requires persistence, you have a lot more options than just sticking it in redis. Plus, `oban` is a high quality background processor with persistence, without the need for adding redis to your stack.
For applications where performance matters, Elixir and Erlang give you lots of tools to build a truly performant app, However, if you don't need those tools, you might be better off building it in something more familiar.
[+] [-] jswny|4 years ago|reply
Yes, the extension uses a ton of CPU for 15 minutes the first time you set it up. It’s building a giant database for type information to give you type checking and hints.
It does this ONE TIME when you first set it up. It explains this. It’s really not a big deal. I’ve found the extension to be great, I’m not really sure what you are referring to there.
[+] [-] pera|4 years ago|reply
[+] [-] poisonta|4 years ago|reply
[+] [-] jerf|4 years ago|reply
I used Erlang for 5-6 years in a production environment in a deployment that wasn't the world's biggest, but did seriously need clustering because we needed more than one machine to handle the load, not just redundancy. This comment leads to my core observation about the entire ecosystem for anyone considering using anything in the Erlang ecosystem.
Erlang started in the late 1990s. Joe Armstrong was brilliant, and I would imagine was also surrounded by some other very smart people whose names I do not know. Despite what I'm about to say, let nothing I say be construed as disrespect for either the language or the people making it.
Let me set some context here. C++ ruled the day, and still looked to inevitably replace all C. Python, Perl, and the entire dynamic scripting language category had just been invented. Java was in the news, but not on your computer yet. Haskell... pre-monadic IO... had just been standardized somewhere in here. Threading was possible but was every bit the nightmare it has been presented as, and you had to be careful spawning more than single-digit threads because of the resource consumption. Open source was just beginning to be A Thing... that is, it had existed in its embryonic form for decades, of course, but it was just beginning to cohere into the Linux world we know now. Machines were still measured in the hundreds of megahertz and the single-digit megabytes of RAM.
Erlang was a far more radical departure from anything else in this era than it is today. There was a lot of academic work on this stuff, and there was a lot of very specialized high-end work on multiprocessing, but it wasn't being done by "mere mortals" and it wasn't very simple. Erlang's designers looked out into the world, and what they saw was a huge jungle, where what maps we had had huge regions that just said "Here There Be Dragons". And they started in, hacking and slashing and slicing their way through, guided by a few intuitions and a whole lot of engineering firepower.
And they largely succeeded in creating a settlement in the wilderness. They grew and managed to pave over the hack & slash paths into roads, built a community, built a pretty incredible VM, built an ecosystem around them. Let this accomplishment not be underestimated; this is a land that had eaten many others in that era.
However, sitting here in 2021, this is no longer a wilderness. Much of the area has been razed, highways driven through it, McDonald's by every exit, and millions of people living here in various bustling metropolises.
And I think what we've found is that where Erlang plopped itself down is OK... but not more than that.
As a consequence of its isolation, Erlang bundles a lot of things into itself that just didn't exist back in the day. It bundles in messaging passing and a network-aware message bus, almost literally decades before anyone else even thought of a "message bus" as a distinct product segment. (i.e., they existed, you could find academic discussion and some early passes at it, but it wasn't really a distinct category yet.) It has a threading environment. It has these "supervision trees" idea which are cool. It has immutability at a time where Haskell was even crazier than it is now. It has a mechanisms for bundling and distributing applications. It has this entire alternate-reality ecosystem in it. But...
... in 2021, none of these are best-of-breed anymore. Many of them are deeply quirky. Immutability is cool, but we only needed to not be able to pass mutable references on the message bus, not be fully immutable within an Erlang process. I believe Elixir fixes this one. A modern message bus going between processes gives you this whether you like it or not because it also can't carry mutable references between OS processes and systems. Having a message bus integrate into the language is a big mistake, because it makes it hard to hook up anything but Erlang nodes to Erlang. (I say "hard" and not "impossible" because I know it can be done, but it's hard.) A modern message bus like Kafka or the dozen other choices doesn't impose an implementation language on you, nor does it impose that implementation language being the only one. Process restarting is a necessity for production-grade systems, but we've settled to a large degree on OS-level handling for restarts, and within a system, there are easier ways to accomplish the goal than bring in the entire Erlang supervision setup. Mnesia, a clustered DB was a neat idea, but in 2021 is so poorly featured and unreliable it doesn't even qualify as one anymore; nobody in their right mind would bring up an Erlang cluster just to back some other language's code to Mnesia as a database. Pattern matching is cool, but not cool enough to justify all the other issues that come with it, and proper use of other language functionality is often good enough anyhow. (I don't tend to miss it; I tend to properly use some form of polymorphism instead. Trivial pattern matching is replaced by this, and to be honest, non-trivial pattern matching is probably a code smell if not an antipattern; if you're reaching three levels down into a data structure, you know too much about that data structure!) Modern Erlang performance is meh; it used to have the clear advantage when dealing with lots of sockets but now there's a lot of things that can comforably exceed it. Its type system is an annoyance even by dynamically-typed standards, if you like static types than just stay away. (They will cite Dialyzer, but it isn't anything remotely resembling a replacement.) And if I reviewed the docs I could find a few more of these, plus I find there's a lot of cases where Erlang has solutions to problems only Erlang has in the first place, e.g., "gen_server" is neat, but the entire gen_server set up, with its initialization phase and its three proscribed ways to call it and the need for an explicit "gen_server" module type are largely the creation of Erlang in the first place... in other languages you generally get the functionality packed up differently but it's all there without having to exactly match what Erlang does.
So, in 2021, the problem is that going into the Erlang ecosystem tends to lock you into a whole package of things that vary from "not best of breed but mostly OK" to "significantly inferior to the modern alternatives". All it really has is very nice integration of its not-best-of-breed stuff, but even that kinda becomes a trap after a while, like when you realize you need a real database after all, then maybe you have to integrate with another message bus so you can integrate with non-Erlang code, and, you know, a couple more cycles around that loop and you'll really regret having chosen Erlang.
One thing that I think it has going for it, and why it's probably still got a cult following today, is that if you're a relatively new developer, or not experienced in network programming, it is a heck of a trip when you get into it, because the tutorial will introduce you to half-a-dozen ideas you've never seen before. Cross-server message buses? Amazing! A network database with an easy API? Amazing! Spawn a million processes on a commodity box? Amazing! I think this explains a lot of the appreciation it gets today. But no longer are any of those things unique. It's just that the normal developer lifecycle will tend to encounter those, one at a time, over the course of years, instead of having them all thrown at you in one amazing, mind-blowing language introduction.
But in 2021, you can do not just "better" than Erlang for all of them, you can do much better. Except that whatever you put together will be something you had to put together, and it won't be quite as nicely integrated. But it will allow for multiple languages, it'll allow you to better integrate with the direction modern ops is going, it'll scale better both internal to your language and in terms of performance, and you'll be better able to hire for it.
The Erlang ecosystem was brilliant and far ahead of its time. I honor it as an incredible pioneer and recommend, even after everything I said, that anybody thinking of writing some incredible new language spend some time in the Erlang ecosystem to see some of what is possible with that sort of integration. But I can't in good conscience recommend it, in either its Erlang flavor or its Elixir flavor (or its Lisp flavor or anything else) to a modern developer. Everything Erlang does is much better done now by other things, minus the language/ecosystem lockin. This is not because Erlang lost, it is because it to a large degree won. It blazed a trail, and we all now agree, it was a trail very worth blazing. But the next waves of settlers & builders ultimately have created something better.
[+] [-] carlosf|4 years ago|reply
Yeah, last time I tried to get a hang in Erlang I felt it was trying to solve stuff that is already being solved by my infrastructure in a language agnostic way.
[+] [-] bennyp101|4 years ago|reply
This whole thing sounds very much "ruby good, elixir bad"
[+] [-] syspec|4 years ago|reply
That's my main blocker, proper JetBrains IDE support just makes everything so much easier. I need a debugger.
I tried the plug-in, and kudos to the author but it did not work for me. In the end they're only one person so of course they could not test every single configuration
-
I wonder why JetBrains has not put their weight behind it.
[+] [-] 29athrowaway|4 years ago|reply
Erlang (and by extension Elixir) is a concurrent language. You use it when you have non-trivial concurrency challenges. When tackling the right problems, the language shines.
Implementing a simple CRUD application with Elixir is overkill, because you can make your servers stateless and delegate most of the concurrency problems to the database.
[+] [-] digianarchist|4 years ago|reply
[+] [-] joelbluminator|4 years ago|reply
[+] [-] srivathsaharish|4 years ago|reply
[+] [-] pmarreck|4 years ago|reply
> We built a few services
So you never really committed to it in the first place. Also, this complicates the deployment problem.
> after a few years some of the original people that introduced it left the company
Probably left for a company that actually committed to Elixir. :P
> and it became very difficult to hire for
In a world where everyone is remote and where 10 Elixir people apply to every job, this product must have been pretty unappealing
> New hires were either people wanting to learn (so we had to spend a good bunch of resources into teaching + end up with a system built by noobs to the language) or very expensive developers with a lot of experience in erlang and elixir.
"We didn't want to pay employees their worth and instead bitched about what we couldn't get without hiring those employees"
(Why couldn't you hire an assortment? One experienced guy and a couple noobs?)
> We also found many times missing libraries, or found libraries which are incomplete, or unmaintained or just not well documented
Alright, fine. Sometimes you have to "roll your own" in this space, still.
> Tooling is just terrible. The VSCode plugin is crap
You should not use the word "tooling" here because VSCode is not an IDE, Elixir should not require an IDE, and moreover, Elixir should not be judged because "there is no good IDE for Elixir". "Tooling" should refer to the support libs and tools that ship with the language, all of which are excellent.
> At that point you're just reinventing your crappy undocumented and untested version of delayed_job.
Spotted the guy who never heard of Oban https://github.com/sorentwo/oban Benefit of the doubt: Perhaps it didn't exist yet.
> Most of what you get from elixir in terms of redundancy, high availability, etc you can have that anyway from kubernetes, heroku or any PaaS
This is entirely missing the point. If a bug or runtime error crashes your Ruby interpreter, you better have another one ready to go from a pool (because Rails stacks can take a while to load), and then you better not exhaust that pool! If such an error crashes Elixir, it just restarts the process, which only takes a millisecond because forking an immutable language's state is trivial compared to a mutable language's state.
> Liveview
I actually haven't played with it much yet so can't comment
> In the end, we are back to Rails and much happier
"We can underpay cheap devs again"
You also repurchased entire classes of bugs that are impossible in Elixir such as: mutation bugs, monkeypatch bugs, and concurrency bugs (just forget running your test suites in parallel). Also, these are literally the hardest types of bugs to fix (nondeterministic behavior), and will likely cost you more in the long run than any differential salary you balked at (I have spent entire months debugging something in the Ruby space, you'll remember my comment once this bites you in the *** one day).
[+] [-] dudul|4 years ago|reply
[+] [-] airhead969|4 years ago|reply
I wrote a bunch of Erlang and Elixir tooling before I realized the most useful projects were thrown over the wall FOSS codebases.
If it's stupid and it works, it's not stupid. Fashionable is for runway models.
[+] [-] dorian-graph|4 years ago|reply
- Elixir is good for just getting stuff done. I came from a previous startup that used Go and Elm.
- The community isn't as small as people make it out to be, or, it's quality over quantity. ;)
- There's a lot of good modules out there, and if you need to write your own, it's easy and there's well-defined patterns. E.g. I recently improved our internal Zendesk client and it was a breeze.
- https://dashbit.co/ for paid support/advice is amazing.
- The console for experimentation, debugging, inspection, etc. is fantastic.
- The let it crash, and other Elixir/Erlang philosophies, have been very helpful.
- There's a solid amount of batteries-included, but not in an overbearing/restrictive way.
- It's such a pleasant day-to-day dev experience.
I didn't know Elixir before joining this startup. For myself, and workmates who also didn't have prior experience, it's been a breeze to get up to speed in.
[+] [-] klohto|4 years ago|reply
[+] [-] phtrivier|4 years ago|reply
- Be careful about libraries. If you know that your system has to interact with X, don't assume that there is a running, idiomatic, maintained libary for X on `hex.pm`. Do a bit of due diligence. We had experience ranging from `meeh` (oauth2, graphql, http) to `pretty bad` (mqtt, swagger.)
But as other say, if you're doing vanilla Phoenix/Plug/Ecto with exactly the right kind of DB, you'll should be ok.
- Give a little though about how you'll be deploying and operating. `releases` and `configuration` haved changed in pretty big ways in the past (https://elixir-lang.org/blog/2019/06/24/elixir-v1-9-0-releas...), the ecosystem is constantly in flux (`config.exs` vs `Application.get_env` vs ENV_VAR vs..) . Plus, the erlang virtual machine (BEAM) has knobs that are not always easy to play with. And if you hide it behind, say, docker containers, you'll have other troubles. Don't expect an `heroku do-some-magic` experience.
- Unless you're familiar with the Actor Model already, and your application is very simple, expect a learning curve made of:
- Finally, you're coming from RoR, so you're probably fine with not having static types anyway ; may St Isidore help you ;) There is a thing called `dialyxir`. It might help a bit ; It will disappoint a lot.[+] [-] iroq|4 years ago|reply
I personally found that with rigorous enough usage, I don't even miss having actual static typing anymore ;)
[+] [-] jswny|4 years ago|reply
It has absolutely changed a decent amount over the last few years. Because it used to suck. It’s not really in flux, more like being improved because everyone knew it sucked. It’s in a much better state now and I’m very happy with it where I wasn’t before.
Also, I would say that “in flux” isn’t a proper characterization because it was always backwards compatible. Nothing broke, they just improved the experience through better methods.
[+] [-] toolz|4 years ago|reply
Which graphql library do you prefer over absinthe in other ecosystems?
[+] [-] pmarino90|4 years ago|reply
I would also say that the "library" one is basically valid for every language. In general is always a good thing to spend some time analyzing the possibilities before importing an external lib into your application.
[+] [-] canadianfella|4 years ago|reply
[deleted]
[+] [-] pavel_lishin|4 years ago|reply
What a god-awful piece of software.
[+] [-] samgranieri|4 years ago|reply
The first thing that tripped me up with Elixir is the difference between single quoted and double quoted strings. They’re different data types!
Most of the work I’ve done has been writing JSON or GraphQL apis that react apps consume. We’re about to start using Phoenix LiveView.
I like using Phoenix + Ecto. It’s lightweight and very fast. I learned Ruby through my work with Rails, and I did not have the same experience with Phoenix. And that’s for the better.
Deployment-wise, we moved from Edeliver to Kubernetes and it’s worked great.
I need to figure out the right editor experience for NeoVim, I haven’t gotten an LSP to work just right. Sometimes Dialyzer is a pain in the ass. Also, I’ve had some issues installing erlang via ASDF lately and sometimes I’ve had to use homebrew symlinks to skip that problem.
I recommend that OP give Elixir a shot and see what you think. There’s also very nice community on the Elixir language slack server.
[+] [-] gamache|4 years ago|reply
Previously I wrote Scala for a few years, then RoR for a few years before that, following about a decade of Perl. I recommend you try Elixir.
Anyone complaining about a talent pool is focusing too hard on prior Elixir experience. We hire backend engineers and teach them Elixir. This has worked out great so far, especially now that we're a fully remote business and are no longer as constrained by geography.
[+] [-] atonse|4 years ago|reply
Apart from application bugs we’ve caused, it just keeps chugging along and working beautifully. It’s never once been the bottleneck in our stack.
Finding people has not been tough at our scale, and they’ve been good quality.
We are just scratching the surface with OTP. And between that and the data processing tools, we know we can handle pretty much any scale.
Deployment is nearly as crude as it was 5 years ago though. We use distillery and edeliver. We are moving to docker containers soon.
We use Exq for background jobs and have processed 75 million in a year without a sweat (most of that in the last two months). We handle 55 million requests per month on t3.mediums. We are looking to switch from Exq to Oban but I’m nervous about whether Oban’s Postgres based architecture will handle it. It’ll probably be totally fine.
[+] [-] morbicer|4 years ago|reply
That's not very impressive, you could achieve that easily on something deemed "slow" like Django or RoR
But I guess your load is not constant. How many reqs/sec can it handle in the peak time?
[+] [-] aczerepinski|4 years ago|reply
Five years ago I spent time learning Elixir on the side thinking I was investing in an upcoming technology that would pay off for me financially. I eventually built some services in Elixir at work and really enjoyed it. They performed well but the language didn’t catch on with the rest of the team.
However, five years later the mainstream languages (Ruby, Go) are still paying more. I still get recruiter messages for Elixir jobs offering less than market value but I haven’t used the language in over a year.
[+] [-] grumpy-de-sre|4 years ago|reply
It's only a matter of time until you hit something as confusing as https://elixirforum.com/t/dbconnection-connectionerror-pid-x...
[+] [-] stefanchrobot|4 years ago|reply
The popular packages are top-notch, but as others have said - there might be issues finding what you need. My personal experience seems to be the opposite though - when going from Elixir to Ruby, it turned out that some of the gems were really, really far from perfect.
In terms of deployment, my take is that the community has finally figured it out. Elixir is a compiled language, so there is a build-time configuration and runtime configuration and I think it's best to keep the two separate, which is now well supported by the new runtime config (Elixir >= 1.11). Mix releases + runtime.exs + Docker works for me perfectly.
If you're coming from RoR, you'll be able to pick up Phoenix really quickly. It draws a pretty clear line between your web layer and your business/app layer though. Writing controllers and views should be similar, but I'd suggest spending some time on Ecto - it's quite different from ActiveRecord (in a good way, IMO).
One thing I'm missing in Elixir is optional static typing akin of TypeScript, but that's not coming anywhere soon. Other than that, no regrets.
I got introduced to Elixir in 2015 and was trying to work with it full-time since then. I was able to get a full-time Elixir job and I'm really happy about that. If you're looking for opportunities, I'd suggest attending ElixirConf or ElixirConf EU - last year I got 5 interesting job opportunities from ElixirConf EU alone (it was a virtual event, so the ticket was cheap).
[+] [-] scottmessinger|4 years ago|reply
As for training people, I taught my non-technical co-founder Elixir for some backend scripts he needed to write. He found it much simpler to pick up then Javascript or Ruby and his code was idiomatic rather quickly.
As for the IDE support in VSCode, I've found ElixirLS[1] great. I do have to restart it sometimes (delete the .elixir_ls folder), but that's a small cost to pay for a pretty great experience.
After spending years in RoR in multiple code bases, I find Elixir code bases to be easier to debug and libraries easier to grok. Without the mutable state of OOP, I don't find myself asking, "Where is this state coming from and when/how was it set?" Of course, macros can be hard to follow, but I still find an Elixir library more straight forward than a Ruby one.
We've also experience the great performance and reliability shared by others on this
We haven't had difficulty finding the right libraries even though the ecosystem isn't as mature as Ruby or Javascript.
[1] https://marketplace.visualstudio.com/items?itemName=JakeBeck...
[+] [-] mattbaker|4 years ago|reply
New hires new to Elixir have spun up on it very quickly, in my opinion what a team needs is one or two people experienced in Elixir to give some initial guidance but you don’t need a staff of experienced Elixir engineers to do great work. I have not found it a hard language to teach.
Personally I’ve found the library ecosystem very strong, and writing our own libraries has not been hard. It’s important to note that interop with Erlang is quite good, so you have access to decades of library development from the Erlang ecosystem in addition to libraries written in Elixir.
The basic elements you’re given out of the box for handling fault tolerance and concurrency are graceful and intuitive. The performance has also deeply impressed us.
On a personal level, it’s also the most enjoyable language I’ve worked in and I’ve had very good experiences with the community. I find the tooling very good, including the VSCode extension (I have contributed a few features) but the default dialyzer setting definitely does hog the CPU on first build. I disabled it since we don’t get much out of it.
I’ve built and run software in production in a lot of different languages over the last 15 years. Nothing has compared to Elixir, not even close.
YMMV, I’m not here to refute the experiences of others, I’m just here to say for us it’s been an incredible experience. Absolute joy to use.
[+] [-] toolz|4 years ago|reply
Everything from ecto, and branching logic by pattern matching function signatures to the easy composition and cohesive community around the amazing tooling (mix/hex) and testing. Plenty more I love for productivity
But because of OTP and it's capacity to scale and distribute computation I thoroughly stay loving how deep the topic is and how there's always more to learn.
[+] [-] bandris|4 years ago|reply
Thinking in processes and knowing/using the GenServer abstraction is the core of Elixir programming.
So, one negative is that difficult to use without Erlang knowledge. Also some good libraries are Erlang only for compatibility/historical reasons.
[+] [-] bluevlah|4 years ago|reply
It’s winter of elixir land. The hype cycle has died. If I have to start a project I will think twice unless it really needs distributed system.
My personal opinion - talent pool, plugins and ecosystem is kind of stagnated. First talent pool is really limited and not readily available. Very few companies use elixir in production. More hobbyists in the community than people who actually use it.
Hex has a lot of plugins which are not updated from long. For many there won’t be a plug-in. You have to write it from scratch.
In Phoenix, they are reinventing magic with LiveView.
Few guys who do elixir consulting gain most from the ecosystem.
As a developer if I have to invest my time learning a new language, I would choose rust or Go.
As a company if I have to start a project, I will check whether I have a requirement of distributed systems.
PS: I have used elixir for past 5 years in production.
[+] [-] travisgriggs|4 years ago|reply
I may or may not regret using it in the big picture (libraries, esoteric ness, performance, a 5th language/platform in our soup of tech we use to solve our problem, etc, and who knows) eventually; it's too early for me to tell.
But I wont regret learning Elixir. There's a certain zen in the "ah so you're a programmer, eh? But can you do it without any references/pointers or for loops, huh?" This from a guy who spent 20 solid years as an "objects all the way down" smalltalker, and does a lot of multi paradigm hybrid Python/Kotlin/Swift these days with a bunch of C as well.
What I really noticed last week when I did a day of Python after a week of Elixir is how much time I spend in other languages writing branch logic code. Code where you decide what direction your code should go next. Should it do this or that now. Or if it should optionally do that. I'm writing an order of magnitude less of that code (it moves to a more orthogonal place in multi function matching) in Elixir. It's stretching me and I'm learning new ways of seeing things that ultimately make me a better programmer; the slack channel has been really nice.
I tried Haskell to try and get the taste for pure functional a year ago; it did not go anywhere near as well as this.
[+] [-] mrjoelkemp|4 years ago|reply
And we haven't even spoken about an app-aware repl that lets you manipulate/inspect your running app (even in prod). There are so many game-changing layers in this stack. It's hard to beat once you've explored it.
Very happy customer here.
[+] [-] dugmartin|4 years ago|reply
I think the only downside for me is having to squint sideways to figure out how to convert a complex SQL query into Ecto. I've been writing SQL for almost 30 years and I find myself dropping into using Ecto's `fragment` too often. I've been meaning to pickup "Programming Ecto" to educate myself more (https://pragprog.com/titles/wmecto/programming-ecto/).
I've done my share of RoR apps too and the nice thing about Elixir is there is very little magic and what magic there is (mostly via macros and code auto added via a `use` statement) can be seen and changed directly in your code instead of being hidden in some gem somewhere.
[+] [-] pmontra|4 years ago|reply
[+] [-] iudqnolq|4 years ago|reply
[+] [-] cultofmetatron|4 years ago|reply
Currently on my 3rd year as CTO of a startup. I chose elixir for the greenfield project because we wanted realtime sync for all devices and the smaller projects I worked on before in elixir went off without a hitch. I also found its concurrenly handling and performance far superior to node and I was producting far less bugs due to its functional nature.
3 years in and I'm very satisfied. There are a few epics we took on that would have been much more expensive to do in go or node. For example, we made a partnership with a credit card device terminal. Their interface required one persistent webocket connection per restaurant. IN another language, I would have had to coordinate with my devops guy to have a dynamic system to allocate a process for each of our accounts and route that to our devices. The intended use case were on premise POSes so our cloud based solution wasn't somethign they had planned on supporting.
Anyways, I was able to configure horde and a dynamic registry to boot up a process for each active account and automatically resserect on crash. Since pubsub is built in, It was easy to pass along data from it to all the devices over the channels interface. Best part is it was all doable within the code base running without any changes to out deployment.
Overall, I've been happy with elixir. the only bg downside is its gotten a bit boring. Things just work which leaves me spending time on rust in my free time when I want a challenge.
[+] [-] sb8244|4 years ago|reply
I picked up Elixir probably 4-5 years ago when a co-worker kept recommending it and wanted to explore it more. We finally got the approval to do a microservice in it that was well-suited for it. Over time it became one of the two "blessed languages" alongside Ruby, and was probably adopted by 40% of teams. Our monolith was still Ruby, so a lot of teams had to use Ruby.
I found that people could pick up the language fairly quickly, but it would take a few stumbles on OTP before things started to click there. People generally seemed to like learning it, though. Maybe they were just being polite.
For me, Elixir has been the most fun I've had programming since I started. It allows me to more consciously design my systems because I don't really feel limited by it—this is why I'm bullish on the language. I enjoyed programming in Ruby, but felt limited to doing things a certain way.
There's also still a ton of opportunity in the community (which is excellent as it is, imo). For example, I wrote a book with Pragmatic that I don't think I would've been able to write in the Ruby world. If you're the type of person who likes exploring, figuring things out, and documenting afterwards, then you could make a nice name for yourself in the community.
Hiring is still a bit rough. If you're trying to scale to 50+ engineers then you're going to need someone skilled in training to bring the team up. Throwing them into the deep end won't work. I think smaller teams should generally not have as big of a problem? I'm curious to see how my former employer will maintain Elixir—grow or shrink adoption—over the next 2 years.
[+] [-] minhajuddin|4 years ago|reply