13 ms·

My company is moving away from it. We built a few services but after a few years some of the original people that introduced it left the company and it became v

by midrus 5y ago

My company is moving away from it. We built a few services but after a few years some of the original people that introduced it left the company and it became very difficult to hire for. 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 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.

benwilson-512 5y ago
> Specially now we are using all the hotwire stuff. 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).
- midrus 5y ago
  Liveview (as well as stimulus-reflex) promote minimal JavaScript by trying to push most interactions to the server, and let the server decide what should change in the frontend. So for example, to show a modal, you send an event that signals the user wants to show a modal, so the backend sends back the html for the modal. You click to close the modal, this sends an event to the backend, the backend sends you the diff or the instructions to remove the modal from the dom. In the hotwire world, the encouraged approach would be to already have the html in the dom, and use a stimulus controller to show or hide it [1]. And you only issue backend calls when you really need to reach to the backend anyway (like submitting a form, or refreshing some actual content). You don't call the backend just to signal a button was clicked so that the backend removes html if you can already do that in the frontend. Hotwire is not about avoiding JavaScript, hotwire is avoid organizing it well and reducing the amount you need. Of course you can do things wrong on both approaches, but it is what one approach promotes vs the other. As an example of why this is a problem, see this [2] example. I'm in Europe on a fiber connection, and clicking in one of the calendar days, and closing the modal feels just so terrible.... [1] https://tighten.co/blog/stimulus-101-building-a-modal/ https://tighten.co/blog/stimulus-101-building-a-modal/ [2] http://expo.stimulusreflex.com/demos/calendar/2021-05-01 http://expo.stimulusreflex.com/demos/calendar/2021-05-01
  - granshaw 5y ago
    Yup. And as illustrated by OP's example links, avoid Stimulus Reflex (NOT stimulus.js) for production too. Apart from the stated reasons, the fact that websocket connections aren't scoped by User by default is a really, REALLY sharp edge!
    - hopsoft 5y ago
      As far as security is concerned, it's the application's responsibility to properly scope websocket connections... if and when that's appropriate. This is true of any websocket connection, not just those used by StimulusReflex or even ActionCable. As noted by the parent, latency is certainly a consideration when using such tools, but there are a myriad of libs and techniques that can be leveraged to help you build great user experiences with StimulusReflex and LiveView. You just need to consider your options and architect accordingly. Note also that the expo demos for StimulusReflex are incredibly old (a few major versions behind at this point) and were created in haste to help people grok concepts via example. They were never intended to be a canonical guide of how to best architect such apps at scale. We're considering taking the expo site offline in favor of more specific and better architected demos.
minhajuddin 5y ago
> We also found many times missing libraries, or found libraries which are incomplete, or unmaintained or just not well documented 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&target=VSCode&category=All%20categories&sortBy=Relevance 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.
- pavel_lishin 5y ago
  > 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. ctrl-f for "dialyzer" in this thread, and you will :)
  - 5y ago
poisonta 5y ago
In addition to that, I struggled to find a well maintained library similarly to Devise. Also, many people won’t agree to me, but Ecto is also a kind of pain. I think Phoenix would have been in a better position if there were libraries like ActiveRecord and Devise.
- hnedeotes 5y ago
  Probably there's no one in the Elixir community with enough know how to build a Devise-alike lib, it's what it is.
  - pmarino90 5y ago
    Here a good blog post on this exact topic https://dashbit.co/blog/a-new-authentication-solution-for-phoenix https://dashbit.co/blog/a-new-authentication-solution-for-ph...
    - hnedeotes 5y ago
      The problem with the internet is that you can't markdown irony...
      - pmarino90 5y ago
        ahah sorry about that! I merely wanted to add that to the conversation but I should've replied to the previous message.
  - brightball 5y ago
    Jose Valim, the creator and primary author of Elixir, actually wrote Devise.
  - yoneyone 5y ago
    Jose Valim, creator Elixir, was one of the core developers of Devise...
    - 5y ago
airhead969 5y ago
Erlang and Elixir ecosystem has a bunch of unmaintained throw-away projects. 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.
pmarino90 5y ago
> 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. 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 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.
pera 5y ago
I strongly disagree with your generalisation regarding the tooling: Mix and Hex are without any doubt some of the most pleasant tools I have ever used. (I personally don't care about IDEs so can't comment on the lsp implementation or idea plugins)
- fastball 5y ago
  > complains about tooling in IDEs >> I strongly disagree (doesn't use IDEs) ??
  - pera 5y ago
    "Tooling is just terrible." <- this is a generalization, to which I strongly disagree :)
jswny 5y ago
It astounds me how much I hear about the “VSCode extension uses all my CPU” thing. 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.
- hgershman 5y ago
  It isn't just "ONE TIME" for me. The extension freezes up often and completely stops giving autosuggestions or warnings, and the only way to fix it is to delete the .elixir_ls file and rebuild the database. When I say "often", I mean there are some days where I have to do that at least once an hour, and 5-15 minutes of high CPU usage every hour is just way too much to be acceptable. I love Elixir and the ElixirLS extension is the best I've found so far, but that's not saying much. The extension has enough issues with it to make it very frustrating to work with, and even enough to make the entire Elixir experience not worth it in many cases.
  - juhatl 5y ago
    Is it possible to share more details about your particular setup? I believe you, but this doesn't sound right. I've used the plugin on all three major operating systems in a wide variety of projects and configurations, and have never had this happen to me. Curious to learn more about what could be the culprit for you.
    - enraged_camel 5y ago
      I have had the same issue as the parent poster. I'm on Windows 10. Everything was fine when I was on Elixir 1.9.2, but the moment I upgraded to 1.11.2, the ElixirLS extension just started to break frequently, or getting stuck while building. I ended up disabling it until I have time to troubleshoot further.
whalesalad 5y ago
I am bummed out to see that this is the top comment. I don't doubt your experiences but I hope that other people do not latch on to this and use it as a strong argument against using Elixir. All of these complaints are skin deep and kinda petty, to be honest. > 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.
- ncallaway 5y ago
  > 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. Right, but...there are also developers out there who do want those things. It feels very dismissive to dismiss a complaint like that as "petty" just because there's a set of people who don't have the same needs. I feel like it's a very useful piece of information about the language that doesn't feel at all petty to me. If you don't want the IDE-like tooling, then you can read the comment and think: "ah, they want more tooling than I do, so this critique doesn't apply to my use-case". If you do want that style tooling, then you might read the comment and think: "Ah, that's good to know. That applies to me, and I'll definitely take it into consideration". Someone having priorities that are different from you doesn't seem "petty" to me. It just seems...like different priorities.
  - jimbob21 5y ago
    Exactly. One of the MOST valid criticisms of a language is the way (or lack of ways) in which it can be used.
bennyp101 5y ago
"There is no IDE from jetbrains" Is that now a thing that is important? I've only just started using an IDE from them - and I don't see how it's miles better than say vscode? This whole thing sounds very much "ruby good, elixir bad"
carlosf 5y ago
> 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... 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.
- srivathsaharish 5y ago
  they are not the same kind of concurrency model though
- svrtknst 5y ago
  I'd say it's rather the other way around. Your infrastructure now solves what Erlang did 25 years ago. Not to argue your point, though.
joelbluminator 5y ago
Rails is awesome nothing comes close to being as fun and productive. Tried php and django, not bad but not Rails.
- nickthemagicman 5y ago
  Have you tried Laravel? Asking because I'm just curious about the comparison between the two
  - joelbluminator 5y ago
    A bit, its ok. Im just a sucker for the combination between ruby and rails. php wont do it for me, but its a solid language.
- midrus 5y ago
  Can't agree more with this. I've used both, Rails since a few years ago and Django for about 8 years or so, and while I still like Django I think rails is far, far superior in every aspect. The only thing I like more from django is the migrations system (not even the ORM, just the migrations) and maybe the admin as a tool to browse the database. Other than that, Rails all day.
  - joelbluminator 5y ago
    Yes the Django admin was cool, the Rails core team didnt want to bring something similar to Rails for reasons I dont quite remember..maybe its a shame
dudul 5y ago
Can you name a few of the libraries you didn't find?
jerf 5y ago
"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..." 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.
srivathsaharish 5y ago
ah, well, another ruby or python enthusiast trying to avoid other models of concurrency at all costs
lbhdc 5y ago
I worked on an elixir project at a ruby shop for about a year. We had complex distributed system, and were replacing core ruby services with elixir. Ultimately the project was a failure, and was re-re-written in Ruby, and the Elixir devs were let go. 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.
- joelbluminator 5y ago
  I think new languages wont be able to break in the top 10 without a mega corp pushing them. The market is too saturated and there is a language for everything under the sun. Elixir is just facing too much competition for web stuff and doesnt enjoy Google pushing it.
  - pmarreck 5y ago
    I don't think it's necessary for a language to be in the top 10 to be considered a success. If the people who use it, wouldn't use anything else, then that is the success.
    - joelbluminator 5y ago
      As long as you're aware that hiring and maintaining will be significantly harder then yes you're right. But that also means there's no reason to choose esoteric tech X for yet another CRUD app; you would pick Erlang/Elixir when it actually makes sense and only then.
- abledon 5y ago
josevalim 5y ago
> 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... 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-orchestration-on-the-large-and-the-small https://dashbit.co/blog/kubernetes-and-the-erlang-vm-orchest...
29athrowaway 5y ago
Rails is very productive but it has problems of its own. Many companies move away from Rails once they reach certain growth milestones. 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.
- midrus 5y ago
  In my personal experience (the last bunch of companies I've been at) that milestone you mention is more like what is the current fashion and what the new hires want to work on because of the latest blog post they've read. At my previous job we had *ALL* of them. Each service or project you opened you could guess the date it was started because of how it was built. Rails -> Node -> Elixir -> Go -> Next.js and the frontend backbone -> ember -> react (redux -> mobx -> rxjs -> [some other random state lib] -> just context! -> recoil) -> typescript and probably by now they're already using whatever the new trend is by this morning. It is insane. None of the companies needed any of the performance provided by this tools, in fact, they all struggle with developer productivity more than any other metric, and every time they switch to the new shiny toy, productivity takes another huge cut. But hey, people get paid anyway at the end of the month, so let's keep playing.
  - joelbluminator 5y ago
    The CTO should be fired, what the hell. In fact maybe we should start naming the companies (not the CTOs I will respect their privacy) so we can know where NOT to work.
  - 29athrowaway 5y ago
    Next.js is node-based.
- joelbluminator 5y ago
  I really don't see any reason to move from Rails other than a new CTO trying to shake things up with a tech he's more familiar with. If Shopify/Github/Gitlab/ can build it on Rails so can you. If the monolith is too big you can break it down with engines or to separate apps. Now I like Rails but I would say the same about PHP/Node or most popular stacks. Rewrites to another language are almost always unnecessary.
syspec 5y ago
> 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. 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.
pmarreck 5y ago
oh boy. where to begin > 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 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).
digianarchist 5y ago
Just on the hiring point. There are three companies to my knowledge using Elixir in Toronto. I applied at two and the responses were 1. Not enough professional experience using the language. 2. Very low salary expectations on their end. Pretty bad for Toronto but especially poor for hiring in what is essentially a niche language.

by midrus 5y ago

benwilson-512 5y ago

> Specially now we are using all the hotwire stuff. 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).

midrus 5y ago
Liveview (as well as stimulus-reflex) promote minimal JavaScript by trying to push most interactions to the server, and let the server decide what should change in the frontend. So for example, to show a modal, you send an event that signals the user wants to show a modal, so the backend sends back the html for the modal. You click to close the modal, this sends an event to the backend, the backend sends you the diff or the instructions to remove the modal from the dom. In the hotwire world, the encouraged approach would be to already have the html in the dom, and use a stimulus controller to show or hide it [1]. And you only issue backend calls when you really need to reach to the backend anyway (like submitting a form, or refreshing some actual content). You don't call the backend just to signal a button was clicked so that the backend removes html if you can already do that in the frontend. Hotwire is not about avoiding JavaScript, hotwire is avoid organizing it well and reducing the amount you need. Of course you can do things wrong on both approaches, but it is what one approach promotes vs the other. As an example of why this is a problem, see this [2] example. I'm in Europe on a fiber connection, and clicking in one of the calendar days, and closing the modal feels just so terrible.... [1] https://tighten.co/blog/stimulus-101-building-a-modal/ https://tighten.co/blog/stimulus-101-building-a-modal/ [2] http://expo.stimulusreflex.com/demos/calendar/2021-05-01 http://expo.stimulusreflex.com/demos/calendar/2021-05-01
- granshaw 5y ago
  Yup. And as illustrated by OP's example links, avoid Stimulus Reflex (NOT stimulus.js) for production too. Apart from the stated reasons, the fact that websocket connections aren't scoped by User by default is a really, REALLY sharp edge!
  - hopsoft 5y ago
    As far as security is concerned, it's the application's responsibility to properly scope websocket connections... if and when that's appropriate. This is true of any websocket connection, not just those used by StimulusReflex or even ActionCable. As noted by the parent, latency is certainly a consideration when using such tools, but there are a myriad of libs and techniques that can be leveraged to help you build great user experiences with StimulusReflex and LiveView. You just need to consider your options and architect accordingly. Note also that the expo demos for StimulusReflex are incredibly old (a few major versions behind at this point) and were created in haste to help people grok concepts via example. They were never intended to be a canonical guide of how to best architect such apps at scale. We're considering taking the expo site offline in favor of more specific and better architected demos.

minhajuddin 5y ago

> We also found many times missing libraries, or found libraries which are incomplete, or unmaintained or just not well documented 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&target=VSCode&category=All%20categories&sortBy=Relevance 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.

pavel_lishin 5y ago
> 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. ctrl-f for "dialyzer" in this thread, and you will :)
- 5y ago

poisonta 5y ago

In addition to that, I struggled to find a well maintained library similarly to Devise. Also, many people won’t agree to me, but Ecto is also a kind of pain. I think Phoenix would have been in a better position if there were libraries like ActiveRecord and Devise.

hnedeotes 5y ago
Probably there's no one in the Elixir community with enough know how to build a Devise-alike lib, it's what it is.
- pmarino90 5y ago
  Here a good blog post on this exact topic https://dashbit.co/blog/a-new-authentication-solution-for-phoenix https://dashbit.co/blog/a-new-authentication-solution-for-ph...
  - hnedeotes 5y ago
    The problem with the internet is that you can't markdown irony...
    - pmarino90 5y ago
      ahah sorry about that! I merely wanted to add that to the conversation but I should've replied to the previous message.
- brightball 5y ago
  Jose Valim, the creator and primary author of Elixir, actually wrote Devise.
- yoneyone 5y ago
  Jose Valim, creator Elixir, was one of the core developers of Devise...
  - 5y ago

airhead969 5y ago

Erlang and Elixir ecosystem has a bunch of unmaintained throw-away projects. 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.

pmarino90 5y ago

> 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. 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 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.

pera 5y ago

I strongly disagree with your generalisation regarding the tooling: Mix and Hex are without any doubt some of the most pleasant tools I have ever used. (I personally don't care about IDEs so can't comment on the lsp implementation or idea plugins)

fastball 5y ago
> complains about tooling in IDEs >> I strongly disagree (doesn't use IDEs) ??
- pera 5y ago
  "Tooling is just terrible." <- this is a generalization, to which I strongly disagree :)

jswny 5y ago

It astounds me how much I hear about the “VSCode extension uses all my CPU” thing. 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.

hgershman 5y ago
It isn't just "ONE TIME" for me. The extension freezes up often and completely stops giving autosuggestions or warnings, and the only way to fix it is to delete the .elixir_ls file and rebuild the database. When I say "often", I mean there are some days where I have to do that at least once an hour, and 5-15 minutes of high CPU usage every hour is just way too much to be acceptable. I love Elixir and the ElixirLS extension is the best I've found so far, but that's not saying much. The extension has enough issues with it to make it very frustrating to work with, and even enough to make the entire Elixir experience not worth it in many cases.
- juhatl 5y ago
  Is it possible to share more details about your particular setup? I believe you, but this doesn't sound right. I've used the plugin on all three major operating systems in a wide variety of projects and configurations, and have never had this happen to me. Curious to learn more about what could be the culprit for you.
  - enraged_camel 5y ago
    I have had the same issue as the parent poster. I'm on Windows 10. Everything was fine when I was on Elixir 1.9.2, but the moment I upgraded to 1.11.2, the ElixirLS extension just started to break frequently, or getting stuck while building. I ended up disabling it until I have time to troubleshoot further.

whalesalad 5y ago

I am bummed out to see that this is the top comment. I don't doubt your experiences but I hope that other people do not latch on to this and use it as a strong argument against using Elixir. All of these complaints are skin deep and kinda petty, to be honest. > 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.

ncallaway 5y ago
> 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. Right, but...there are also developers out there who do want those things. It feels very dismissive to dismiss a complaint like that as "petty" just because there's a set of people who don't have the same needs. I feel like it's a very useful piece of information about the language that doesn't feel at all petty to me. If you don't want the IDE-like tooling, then you can read the comment and think: "ah, they want more tooling than I do, so this critique doesn't apply to my use-case". If you do want that style tooling, then you might read the comment and think: "Ah, that's good to know. That applies to me, and I'll definitely take it into consideration". Someone having priorities that are different from you doesn't seem "petty" to me. It just seems...like different priorities.
- jimbob21 5y ago
  Exactly. One of the MOST valid criticisms of a language is the way (or lack of ways) in which it can be used.

bennyp101 5y ago

"There is no IDE from jetbrains" Is that now a thing that is important? I've only just started using an IDE from them - and I don't see how it's miles better than say vscode? This whole thing sounds very much "ruby good, elixir bad"

carlosf 5y ago

> 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... 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.

srivathsaharish 5y ago
they are not the same kind of concurrency model though
svrtknst 5y ago
I'd say it's rather the other way around. Your infrastructure now solves what Erlang did 25 years ago. Not to argue your point, though.

joelbluminator 5y ago

Rails is awesome nothing comes close to being as fun and productive. Tried php and django, not bad but not Rails.

nickthemagicman 5y ago
Have you tried Laravel? Asking because I'm just curious about the comparison between the two
- joelbluminator 5y ago
  A bit, its ok. Im just a sucker for the combination between ruby and rails. php wont do it for me, but its a solid language.
midrus 5y ago
Can't agree more with this. I've used both, Rails since a few years ago and Django for about 8 years or so, and while I still like Django I think rails is far, far superior in every aspect. The only thing I like more from django is the migrations system (not even the ORM, just the migrations) and maybe the admin as a tool to browse the database. Other than that, Rails all day.
- joelbluminator 5y ago
  Yes the Django admin was cool, the Rails core team didnt want to bring something similar to Rails for reasons I dont quite remember..maybe its a shame

dudul 5y ago

Can you name a few of the libraries you didn't find?

jerf 5y ago

"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..." 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.

srivathsaharish 5y ago

ah, well, another ruby or python enthusiast trying to avoid other models of concurrency at all costs

lbhdc 5y ago

I worked on an elixir project at a ruby shop for about a year. We had complex distributed system, and were replacing core ruby services with elixir. Ultimately the project was a failure, and was re-re-written in Ruby, and the Elixir devs were let go. 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.

joelbluminator 5y ago
I think new languages wont be able to break in the top 10 without a mega corp pushing them. The market is too saturated and there is a language for everything under the sun. Elixir is just facing too much competition for web stuff and doesnt enjoy Google pushing it.
- pmarreck 5y ago
  I don't think it's necessary for a language to be in the top 10 to be considered a success. If the people who use it, wouldn't use anything else, then that is the success.
  - joelbluminator 5y ago
    As long as you're aware that hiring and maintaining will be significantly harder then yes you're right. But that also means there's no reason to choose esoteric tech X for yet another CRUD app; you would pick Erlang/Elixir when it actually makes sense and only then.
abledon 5y ago

josevalim 5y ago

> 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... 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-orchestration-on-the-large-and-the-small https://dashbit.co/blog/kubernetes-and-the-erlang-vm-orchest...

29athrowaway 5y ago

Rails is very productive but it has problems of its own. Many companies move away from Rails once they reach certain growth milestones. 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.

midrus 5y ago
In my personal experience (the last bunch of companies I've been at) that milestone you mention is more like what is the current fashion and what the new hires want to work on because of the latest blog post they've read. At my previous job we had *ALL* of them. Each service or project you opened you could guess the date it was started because of how it was built. Rails -> Node -> Elixir -> Go -> Next.js and the frontend backbone -> ember -> react (redux -> mobx -> rxjs -> [some other random state lib] -> just context! -> recoil) -> typescript and probably by now they're already using whatever the new trend is by this morning. It is insane. None of the companies needed any of the performance provided by this tools, in fact, they all struggle with developer productivity more than any other metric, and every time they switch to the new shiny toy, productivity takes another huge cut. But hey, people get paid anyway at the end of the month, so let's keep playing.
- joelbluminator 5y ago
  The CTO should be fired, what the hell. In fact maybe we should start naming the companies (not the CTOs I will respect their privacy) so we can know where NOT to work.
- 29athrowaway 5y ago
  Next.js is node-based.
joelbluminator 5y ago
I really don't see any reason to move from Rails other than a new CTO trying to shake things up with a tech he's more familiar with. If Shopify/Github/Gitlab/ can build it on Rails so can you. If the monolith is too big you can break it down with engines or to separate apps. Now I like Rails but I would say the same about PHP/Node or most popular stacks. Rewrites to another language are almost always unnecessary.

syspec 5y ago

> 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. 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.

pmarreck 5y ago

oh boy. where to begin > 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 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).

digianarchist 5y ago

Just on the hiring point. There are three companies to my knowledge using Elixir in Toronto. I applied at two and the responses were 1. Not enough professional experience using the language. 2. Very low salary expectations on their end. Pretty bad for Toronto but especially poor for hiring in what is essentially a niche language.