4 ms·

That's a pretty good write up. There's a fine line between making things easier and more readable and having less boilerplate code, and pouring a bit too much

• cschmatzler 3y ago
  Phoenix is obviously “the big thing” and no other language/framework combination has something as good as LiveView. Rails cannot compete there. Other than that, building Livebook apps for our customer success team has been really great and easy. There’s quite a big push for ML in Elixir right now, and then there’s also Nerves for embedded programming, which I’ve never dabbled in but it looks nice.
  • OkayPhysicist 3y ago
    LiveView is definitely Elixir's killer app. It's what takes Phoenix from "a really good web framework" to "the singular best web framework", in my experience. Ecto is also a best-in-class data-layer adapter (ORM seems wrong and reductive).
    • sethammons 3y ago
      I'm primarily a Go developer who loathes ORMs. I have to admit that Ecto is pretty great.
  • cultofmetatron 3y ago
    ecto is also just an amazing db wrapper in general. you basically write sql in elixir which means you can optimize the crap out of your queries and its easy to steop down to actual sql where needed via fragments.
    • hosh 3y ago
      And you can still use composable queries if you still want to (equivalent to Rail’s named scopes).
  • slekker 3y ago
    Do you have any write up about Livebooks for your CS team? Sounds like an interesting use case!
  • metaltyphoon 3y ago
    > no other language/framework combination has something as good as LiveView You just have to look. Blazor does what LiveView do and on upcoming. NET 8 it will leapfrog it.
    • porker 3y ago
      People have been saying this about Blazor for years, and it's never reached that point. Where can I see what .NET 8 will bring to Blazor to change this?
    • OkayPhysicist 3y ago
      As someone currently using bleeding edge Blazor at work, and Phoenix on my own time, this is wromg to the point of comedy. The big thing that LiveView has going for it is that it transforms the client session into just another process to communicate with, using the same message passing tools as the rest of the language, with very little headache because concurrency is already an expectation. Blazor can never achieve this, because C# is not a concurrency focused language.
• sodapopcan 3y ago
  > Rails is going to be a better pick in some circumstances because of the huge number of libraries. This isn't really as big a problem as many people think. I've been out of Rails for a while now but haven't really felt the pain of missing anything with Phoenix. I've noticed there aren't often Elixir wrappers around third party APIs, but those are really not a big deal to create a small version on your own with only what you need. I always used to wrap the wrappers anyway! As far as UI stuff goes, there are actually a lot of really nice vanilla JS libs out there which play really nicely with LiveView's JS hooks. I would be interested to hear what people have been sorely missing, though. EDIT: Said "are" when I meant "aren't"
  • arrowsmith 3y ago
    Your experience matches mine. And ChatGPT has been a game-changer - if there isn't an Elixir library for some third-party API, GPT is very good at generating some wrapper functions in Elixir using the API docs.
  • davidw 3y ago
    Oh, I don't think the library thing and ecosystem is really an obstacle for using Elixir so much as it makes Rails a 'safe bet'. If I'm putting on my business hat, I need a reason to use Elixir instead of Rails and that probably has something to do with a better concurrency story, but I'm always curious to hear what other people are getting out of it. My previous experience with BEAM was using Erlang in a semi-embedded environment and it was fantastic for that. Solid, dependable, deterministic, great response times... all of that. But while we did have a web interface to the system, it wasn't a web site.
    • bcrosby95 3y ago
      For us its the simplified production environment. We use BEAM's clustering capability to forgo things like redis and/or a message queue. It probably doesn't matter for every company, but it helps for us where we have zero full time ops people.
      • 3y ago
• pdimitar 3y ago
  The transparent parallelism makes it an amazing fit for pretty much anything and everything that doesn't require minimum system resources and microsecond-level of response times. 1. Web apps work awesomely because they tolerate sudden bursts of load much, much better than Rails. Rails deployments regularly fall over on bursty workloads unless complex load-balancing setups have been put in front of them. 2. Which brings me to: operations / infra story is much simpler, and it is thus cheaper and easier to maintain Elixir apps, even when they span multiple nodes (because Erlang's builtin mechanism to do mesh networking / distribution works well enough for 99% of the projects out there). 3. Complex service trees f.ex. scrapers that also present their data in a visual CMS backoffice UI and background tasks infrastructure -- all of that can live on literally the same node, share the same code repo and be very easy to manage and maintain as a result. 4. Oh, that also reminds me: almost anything and everything you would need Redis for, you can have it natively with Erlang/Elixir. 5. Corollary to point 3: long-lived daemons that are not even web apps / APIs work really well under Elixir due to the supervision tree guarantees of Erlang's underlying OTP framework. If you configure it well (the defaults are not always optimal) you can have your invisible mesh of services survive extended outages of the 3rd party APIs it depends on. 6. In the last years, LiveView and Livebooks are amazing additions that help severely reduce the need of JS and provide an alternative to Jupyter Notebooks, respectively. Though it has to be said that LiveView works best when the latencies to the backend aren't too big, say, 200ms or less. Beyond one certain human perception threshold it starts to feel sluggish however. I could go on and on and give plenty of examples from my career. I've replaced a lot of shell scripts and PHP / Python / JS services with Elixir, and each migration was a crushing success in every way. We're talking 15+ such projects. Only 1-2 of them got back to their original language simply because the companies / teams were too risk-averse and didn't want to hire Elixir devs (or train their current people). But the network effects are always a chicken-and-egg problem; if people never want to bet something on the tech then it obviously is never going to be appealing to them. There are many who made the plunge though and are happy with the results.
  • davidw 3y ago
    > If you configure it well (the defaults are not always optimal) you can have your invisible mesh of services survive extended outages of the 3rd party APIs it depends on. This is something that annoyed me a bit with OTP. The basic strategies aren't really enough for that, so you need something like https://github.com/jlouis/fuse https://github.com/jlouis/fuse I wrote something like that myself, but it hasn't seen a ton of use: https://github.com/davidw/hardcore https://github.com/davidw/hardcore
• megaboy101 3y ago
  Where I previously worked we used Elixir as the backend for a early-stage social app. We only really encountered the lack-of-libraries issue a single time (we needed a Neo4j driver that supported their hosting platform). But aside from that, Elixir was a great choice and served us well. When our app went semi-viral all we needed to do was increase our instance size in AWS, never really needed to worry about horizontal scaling thankfully. Our app also needed a lot of realtime messaging and updates, which was genuinely a breeze with Phoenix. I don’t think I could ever to back to trying to finagle a websocket API in Python.
  • hosh 3y ago
    If anything, scaling Elixir apps favors vertical scaling. Horizontal scaling starts hitting the limits of dist erlang (since, unless you restrict the topolog, every node connects with every other node). It makes for an interesting time when deploying to Kubernetes. But we figured out how to increase the number of cores per erl node during peak daily traffic. I’m working for a Nodejs shop now. For all its use of async stuff, it simply does not scale as well as Elixir (not to mention the deep dysfunctions in the Nodejs ecosystem).
    • dsiegel2275 3y ago
      If I recall the things I've read on this in the past, the horizontal scaling limitations of distributed Erlang are encountered around like 500 to 1,000 nodes? Which I have to imagine means the large, large majority of shops using Elixir and scaling horizontally will be just fine, as they are typically in the size of 2 - 10, or maybe 20 nodes.
      • hosh 3y ago
        There is a reason stuff like Partisan were conceived - https://arxiv.org/abs/1802.02652 https://arxiv.org/abs/1802.02652 If you do a lot of cross node talk with say, the Phoenix channels, then lowering the total number of nodes helps (n*(n-1) for a full mesh). And since the BEAM scheduler will try to use up all available cores by default, past a certain threshold of nodes, it makes more sense to use smaller numbers of nodes with more cores per node. When you also have say, an observaility agent taking up 1000 mcore, doubling the instance size makes a difference. In the last shop, we would idle at 4-cores, jump to 16-cores instance sizes for the morning rush, and go back to 8-cores for the late afternoon traffic. I had tried to horizontally scale it with 4-cores machines, but saw a lot more instability and performance issues. This is one of the advantages with using Elixir or Erlang. You simply don’t get this kind of operational characteristics with Ruby, Python, or Nodejs.
• hosh 3y ago
  Having done both Rails and Elixir, Elixir is vastly easier to scale. Not just because it can use up all the available cores, but also because a REPL in a production environment makes troubleshooting and identifying bottlenecks easier. When I scaled Rails, it was a struggle, and the epiphany I had when I had to modify how Sidekick worked was that Elixir and Erlang had built-in primitives to do what is major refactor of Sidekick to get Sidekick to do what I want. One of the things I had success with in a non-web applications is writing Kubernetes Operators in Elixir. Though I also want to experiment with the embedded Prolog-in-Elixir for those.