6 ms·

We're building a startup ( https://www.batteriesincl.com/ https://www.batteriesincl.com/ ) with Elixir and Phoenix 1.7rc (git master really). It's been amazing;

• eddsh1994 4y ago
  What does your startup do? I'm not 100% sure based on the blurb, but keen to see product ideas where that tech stack shines :)
  • eclark 4y ago
    We haven't launched yet (Q1 Next year is the target), so the landing page isn't great yet. We're a platform as a service that you can install on any cloud via Kubernetes, or on your own self hosted Kubernetes. So distributed systems, automated remediations, machine learning ops, etc are the areas we're using elixir.
• tiffanyh 4y ago
  What’s been your experience with Live View? I ask because I’m under the impression that using it comes with some sizable scaling problems, which somewhat defeats the point of using Erlang in the first place. I could be wrong though. Would like to learn more.
  • eclark 4y ago
    LiveView has been pretty great. Mostly it's just a couple of `handle_event` methods away and we have a fully reactive UI. I haven't seen any scaling issues for LiveView. Under the hood there's a websocket that push and pull events from a running GenServer for each session. Since each process is independent it's horizontally scalable as long as your able to route websockets to the same process in a cluster. While not the same, I do know that single machine has been able to scale to a couple of million connections ( https://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections https://www.phoenixframework.org/blog/the-road-to-2-million-... ) with phoenix channels. Which are harder to scale than independent live views. Also our use case is for smaller scale than that (Not too many companies have a million people looking at their ml deploy pipelines) so I haven't been too worried.
    • tiffanyh 4y ago
      @chrismccord If you’re reading this, would be super interesting to update this 7-year-old benchmark to use Live View (and the latest stack). Thanks for all you do btw.
      • h0l0cube 4y ago
        Could even switch over to Bandit which was on a recent Thinking Elixir podcast > In recent performance tests, Bandit's HTTP/1.x engine is up to 5x faster than Cowboy depending on the number of concurrent requests. When comparing HTTP/2 performance, Bandit is up to 2.3x faster than Cowboy https://github.com/mtrudel/bandit https://github.com/mtrudel/bandit
        • tiffanyh 4y ago
          That’s a great point and Phoenix 1.7 is the first release to support the usage of other web servers. 2-5x speed up would make Erlang surprise Java/Go/etc. https://stressgrid.com/blog/webserver_benchmark/ https://stressgrid.com/blog/webserver_benchmark/
          • h0l0cube 4y ago
  • hn92726819 4y ago
    > I’m under the impression that using it comes with some sizable scaling problems Interesting. I have the exact opposite impression (I'm not experienced in live view; only written 2 small utilities). Erlang (therefore elixir) is fundamentally distributed, so as you mentioned, it would defeat the purpose. So why gives you that impression? LiveView is just a smart/reactive socket built on Phoenix that behaves just like any other elixir process right? Why would it specifically have scaling issues?
  • josevalim 4y ago
    Each LiveView requires a persistent WebSocket connection to the server. This means it does have a different scaling profile than the usual request/response lifecycle, but the Erlang VM is greatly capable of holding millions of connections at the same time and therefore is a perfect fit for the LiveView model. In fact, LiveView is built on top of the same Phoenix Channels we used to achieve 1 million connections on a single server. So I would say that LiveView fully leverages the Erlang VM strengths. :)
    • tiffanyh 4y ago
      Thank you Jose for all you do, create and how you help developers around the world.
    • dmix 4y ago
      What situations would face possible issues with the persistent-socket-per-view approach? A sprawling app with hundreds of distinct views that over-use LiveView? Would there also be multiple persistent sockets for each particular page? I can't imagine the type of site that would need that sort of structure. Typically you'd have your highly-interactive primary subset of your app, about <10-25% of the routes/views which gets 75-90% of your traffic. While the other 75%+ of routes are just simple static-y/REST CRUD/server-rendered pages.
      • brightball 4y ago
        In a situation where you hit the scaling limitations of the BEAM, you’re going to have the budget to address it.
      • TylerE 4y ago
        IIRC (don’t claim to be an expert) the main issue is gracefully handling the case where the server end goes away unexpectedly - network issues, reboots, that kind of thing.
        • dmix 4y ago
          Does that include deploys?
• Mizza 4y ago
  I'm also doing a solo-startup right now that relies heavily on LiveView and Channels/Websockets. I wouldn't have been able to build it by myself without Elixir/Pheonix. It's absolutely fantastic, can't recommend it highly enough.
  • sickcodebruh 4y ago
    How did you settle on Elixir/Phoenix? Did you consider any other languages + frameworks?
  • eclark 4y ago
    100% this. I started with it solo and I was able to achieve what would have been very hard for a three person team with the standard js app + api app + backend app.
• sph 4y ago
  > The community is full of very senior people who freely answer your noob questions. The role of José Valim, the creator of Elixir, can't be understated. He's everywhere, he's got his hands in many of the top used libraries, and he's incredibly welcoming and responsive to all the inane GitHub issues I've opened over the years. People wrongly compare Elixir to Ruby, but I wonder if he decided to recreate the welcoming and newbie friendly community and leadership of Ruby. (Chris McCord, the creator of Phoenix, seems like a pretty swell guy too) Also, a note on the upstream code: Elixir and its core libraries are some of the few projects you get a quick answer to your issues and they aren't closed because they've gone stale. 18 open issues, 5k closed on the core repo is an impressive ratio these days.
  • mlambie 4y ago
    To highlight this point, Jose’s in this thread and across HR. He’s an inspirational leader.
• brigandish 4y ago
  What are you using for the component library? I was thinking of trying out Elixir and if there’s something that works well with it I’d rather start there than by trial and error.
  • eclark 4y ago
    I would recommend Petal: https://petal.build/ https://petal.build/ It's what I used for quite a while and I think it's the most comprehensive currently. We're building two different UI's that share a common design language so we ended up creating a common UI application in the umbrella project.
    • brigandish 4y ago
      Thank you.
    • aarpmcgee 4y ago
      Do you happen to know if this was built with accessibility in mind? There's no mention of it on the website as far as I'm able to tell. Looking from the outside in, it is also unclear what relation the Petal framework has with the PETAL stack, I am confused by the name collision.
• ctvo 4y ago
  > Elixir is a very nice language to write distributed systems in. Functional in all the right places plus it has OTP. This is the biggest blocker for introducing Elixir to any company I work at. I don't want to become / hire experts in the OTP and the Erlang VM. I'm ignorant about it in general, but my feeling is it's not only a new language, it's built on abstractions that I'm not sure I'm comfortable owning or operating. Is that wrong and how did you handle the tradeoffs for your company?
  • bongobingo1 4y ago
    You can kinda ignore OTP outside of the initial "run these (erlang) processes when the vm boots", which is a few lines - often scaffolded out automatically. But then when you suddenly need some async task x service x parallelism its there. I guess if you're building a company it does behoove you to at least read a bit about it but you don't need every team member to be an OTP expert. If you can understand how an OS runs processes at the most basic level and how javascripts async/await works you're already most of the way in a practical day-to-day sense.
  • throwawaymaths 4y ago
    The abstractions you need to critically know are map and reduce. It's not functional like Haskell, the limit at which you need to "think about it being functional" is that a value inside a variable can't change from underneath you when you pass it to a function. It pretty quickly changes from "I have think about values not chamging" to "I don't have to worry about values changing"
    • ctvo 4y ago
      The abstractions I’m talking about are the Erlang VMs and the primitives like actors that are provided by the OTP. I have cold sweats thinking about needing to debug a non-obvious performance issue and diving into that layer.
      • throwawaymaths 4y ago
        Ok. Well there are a lot of other options for performance and no matter what system you're in (python, ruby, rust, jvm, c++) those kind of performance debugging is going to be a slog, and GenServers are relatively easy to work with and the VM gives you a lot of tools to figure it out. Most people at scale seem to be doing okay with elixir. I will say the one thing that I do see coming up over and over again is OOM errors, but I personally feel that's because there are a few gotchas that juniors don't always know about