5 ms·

I cannot support much in terms of money or time currently, but somehow I'd wish there are ways to speed this up. Sure, sponsoring from big corps comes with the

I cannot support much in terms of money or time currently, but somehow I'd wish there are ways to speed this up. Sure, sponsoring from big corps comes with their own problems, but maybe that would be an option? There are quite some that use Elixir (or BEAM in general) out there... Idk what would be the best approach. But I am very convinced that Elixir and the wider ecosystem (not only phoenix liveview) is (or could be) the very best "default" web app stack we have right now in general. It solves _so many_ problems of other comparable tech stacks right out of the box, one way or the other, and is the only one I've noticed a sentiment of pure joy from seasoned devs that also lasts well after the novelty wears off. At this point it looks "only" like a number problem to become mainstream (again a number problem). No idea how to solve it, just felt I needed to share my thoughts as a data point here. Like the type system here: I'd _kill_ to have this exact implementation today rather than _maybe in a few years_. And yes, I can draw comparison to Typescript, Rust and Haskell which I used for projects in the past. Its like combining the very beast ideas (and adding some more) into one awesome thing.

tempotemporary 3y ago
> It solves _so many_ problems of other comparable tech stacks right out of the box Could you expand top 5(or more) major pain points that it solves?
- anonyfox 3y ago
  I don't thinks that would be a helpful discussion right here. Any one point there might come someone who points at some external "solution" (package, tool, ...) that might also do the same feature in some way for X, ignoring the fact that there are lot of Y without that particular thing still, but leads into derailing the argument anyways. Elixir (and esp. Phoenix for web dev) is more like the culmination of the best ideas and heavily draws/depends on the last decades of real-world experience. Most stuff isn't (or shouldn't) be surprising, but the point is that everything you might need for the vast majority of projects is right there, nicely packaged up into a unified nice thingy. But to give you a few of _my_ top points: 1. Architecture and DX for complex interactions: there is no need to bring in supplemental infrastructure crutches (Redis, AWS whatever service, ...) in many cases to begin with. OTP, which is like a core library always available, already includes the building blocks for things like cache servers, application clustering and supervision strategies, ... . 2. Reliability and availability: this tech is the original one achieving the "nine-nines" of uptime record. To get an idea of how, https://www.youtube.com/watch?v=JvBT4XBdoUE https://www.youtube.com/watch?v=JvBT4XBdoUE this talked is packed and excellent, and also highlights a few things why it can achieve my point 1 above. 3. "SPA-like" interactivity with full server side rendering without all the pains of exposing/consuming a dedicated HTTP API in between, or overcomplicated nuances of rendering pipelines (also see react server components) to achieve SSR/CSR in a way that not sucks or is noticeably slow. Liveview is tried to be replicated in other stacks, but they don't come close in reality today or complicate the apps' infrastructure with additional crudges. And don't get me started on the integration testing story compared with SPA+Backend setups. 4. Agents/Message passing parallelism (not only concurrency, but also distributed!) at your fingertips, which makes modeling current "async problems" kinda trivial. OTOH, building something like a proper async-based web framework in rust is quite a pain in the ass, with lots of type fiddling needed, instead of doing the solution you actually want to deliver with it. 5. Some absolutely awesome takes on some typical libraries. Take the ORM options for javascript/typescript (all with severe tradeoffs, and analysis paralysis ontop). Take Rails' ActiveRecord with lots of magic and while great to get started becomes quickly bloated (iE fat models) in bigger projects. And then Ecto got it "just right" with slim schemas, changesets, and basically pure functions + pipelines. Any "model" can be used within new usecases by adding new changesets/validations explicitly and easily, there is no "general" validation right on the model level you have to tiptoe around, and starting If-cascades.
  - clementai 3y ago
    I would add some more points. 6. Livebook, Jupyter notebook are amazing in Python, Livebook is the same but for Elixir. Also you can connect to your running environment and interact with it. 7. The Nx ecosystem, ML is not only a Python thing now, Elixir is completely usable for ML now. 8. Ash framework, this is not a web framework but a framework for your domain, it's amazing
    - anonyfox 3y ago
      absolutelt hard agree on livebook, but I think thats not an immediate thing every webdev needs. but speaking from recent practice, it is laughably simple and kinda mindblowing for non-experts in this stuff. Like, I klick me a few smart cells to interact with external data and get a connection/data, write a few straightforward logic modules to do something, and a super simple form for users of this thing (like two inputs and a submit button, and an event handler) and I can eliminate a business workflow or report. I can call a dev into it ad-hoc to help with a code snippet like a liveshare-coding-session. And finally I deploy it to a bookmarkable URL with a password. Maybe an hour worth of work, _including_ talking with people while fleshing this out in quick iterations as-we-speak. I mean people kinde get how cool phoenix is for one reason or the other, but livebook is really killing it for me. It's hard to talk with business people about tech internals no matter how awesome, but its a different game with lightweight livebooks. If you also happen to have phoenix as your actual product/app, linking the livebook indeed is nice to directly call functions instead of rewriting those snippets in SQL... but the endgame here is when the livebook starts to become unwieldly due to increasing feature requests, it can be integrated into a phoenix app rather easily, since a dev starts out with working code to begin with (and can play with it interactively).
      - throwawaymaths 3y ago
        > it can be integrated into a phoenix app rather easily I can't figure out how to do this.
        anonyfox 3y ago
daxfohl 3y ago
I read that Brex moved away from Elixir to Kotlin. If Elixir was really that great then why would a company put such a big effort to ditch it? That killed off my interest in learning it, but maybe their reasons were invalid? Genuinely curious.
- throwawaymaths 3y ago
  I hear new Cto came in, got nervous about hiring. They are still hiring for elixir positions, though?
  - weatherlight 3y ago
    i heard basically the same and also (the new CTO just really like kotlin and knew a bunch of people who know kotlin and wanted to bring them over. ) again, take the above with a grain of salt.
- WJW 3y ago
  Do you reject learning any language that has been migrated away from by any company? Why not make up your own mind about whether it is nice instead of depending on rumours about other companies? In any case you could have easily googled "brex elixir" and have found their blog explaining their reasoning as the first result: https://medium.com/brexeng/building-backend-services-with-kotlin-7c8410795e4b https://medium.com/brexeng/building-backend-services-with-ko...
  - indigo0086 3y ago
    "Development speed: The future will be great and we want to get there fast. Our choice needs to help us move with urgency and focus. A type-system was a non-negotiable choice here." While Jose Valim did a good job in his talk about dispelling the idea of type system offering all these promises that may or may not be true, the idea will never die. This could mean that it is the right idea, but it could also mean that now's the time to look into a way to offer it in away it attracts people who have that perception while offering a type system of value.
- 3y ago
di4na 3y ago
Tbf. While more money to allows stability of people involved would help, it would not really speed it up that much. Typescript had ms behind it and it still took a decade. At some point the engineering, experiments and learning take time and you can hardly speed it up with more ressources.
- anonyfox 3y ago
  Maybe more like different layers could do different strategies? I can't even imagine what could happen to the BEAM itself if there are the same amount of ressources put on it like in our modern JS engines that have come a loooong way. Its already an amazing piece of tech in itself, but I wonder what an army of experts could do ontop of it.
  - sodapopcan 3y ago
    Then we might have NPM for the BEAM--Uber popularity isn't always a good thing. Don't get me wrong, though, I want Elixir to get more popular.
josevalim 3y ago
I understand many would love to have this yesterday but I strongly believe we should not speed it up. :) This is potentially the largest change the language will ever go through and we are being very intentional and deliberate on every step and decision we make. Once we start collecting feedback from the community, it may speed up or slow down the process, but I want to make sure everyone gets plenty of time to experience and internalize the changes. When it comes to funding, the on-going work on Elixir type system is well funded by companies like Fresha, Starfish*, Supabase, and Dashbit. However, we also want to venture into new research areas, such as existential set-theoretic types, which would allow us to type behaviours (such as GenServer) similar to how one would type first-class modules in OCaml (or Typeclasses in Haskell). If someone is interested in sponsoring research work, hit me up (github.com/josevalim), and I can put you in touch with the proper institutions.
- moljac024 3y ago
  I would like to add that for what it's worth, I wouldn't mind slower compilation times if it means we get the type system as described. If it really does end up having a significant impact on performance, would you be open to making compile-time type-checking optional instead of scrapping the whole thing?
  - josevalim 3y ago
    If it comes to this, we will certainly need to have a discussion on the topic. So I am definitely open to discussing the idea!
Aerbil313 3y ago
I’m curious. What exactly is Elixir good for? What do you find in it more appealing than other languages?
- anonyfox 3y ago
  I have listed a few points here in the other comment: https://news.ycombinator.com/item?id=37596258 https://news.ycombinator.com/item?id=37596258 as a more general/subjective/emotional note: The very pragmatic take on FP makes code in most cases so much easier to reason about. Immutability, no magic coming from some dark corner of the codebase unexpectedly, thinking in steps of data transformation from the get go, piping operator to make this visually pleasant, handling edge cases with pattern matches right at the function head level explicitly, ... and to have stateful stuff, there is OTP right on your fingertips with GenServer/Actor/ETS/... . And a genserver basically is only just another module that implements certain callbacks and then gets spawned. Modelling some scenarios are are breeze with that. And when I feel like I need some better syntax for some exotic problem I am dealing with, I can bend and stretch my language constructs via hygienic macros right away. And the whole experience is _extremely_ polished in terms of DX. docs, tests, doctests, interactive shell, a AOT-compiler, a JIT-runtime, and some very high-quality ecosystem bangers, like phoenix/livebook/membrane/boradway/Nx/Axon/... . Its like best of all worlds, and definitively the _very best_ choice for orchestrating stuff, which is a boon when you run into a problem you'd rather not use elixir for. Like building a native extension in rust/zig for some raw CPU task is a breeze. Its not so much the individual feature (no matter which one) but the overall package.
- OkayPhysicist 3y ago
  It's a functional, concurrent-first language. People have talked about the upsides of functional programming to death, either you prefer it or you don't. The concurrency story, though, is a significant advantage exclusive to the BEAM languages. They utilize green threads with message passing queues that we call "processes" (not to be confused with OS-level processes). A good almost-toy level project I built in Elixir was a Minecraft server proxy. At the top level, you've got a listener process, that waits for an incoming TCP connection, and a Supervisor process, who's responsible for the existing connections. When the listener receives a new TCP connection, it spawns a process under the Supervisor to handle that incoming connection, and goes back to listening. That's about 10 lines for code: 4 in the initiation (function declaration, start Supervisor, start Listener, end), and 6 in the Listener (function declaration, get new TCP connection, spawn process as a child of the Supervisor, assign TCP connection, recurse, end) The child processes are running a little state machine to do some parsing of the TCP stream. They receive TCP packets as a series of messages, and based on those messages they do various things. Unimportant for the purposes of explanation, except to say that the built-in gen-statem state machine handler simplifies it down to a series of functions that match a message, and produce a new state. But what if I receive a packet that I don't have a defined response to? Well, I don't need to write any extra code for that. When it fails to pattern match any of my states, the process is going to crash. Then it's children will crash (including the tcp connection, which will be closed by this operation), then it'll tell it's Supervisor "Alas, I am slain". By default, the Supervisor would replace it with a clone, passed the same initial arguments. But that's not the behavior we want here, we want it to just accept that the process has died, and maybe pass an alert to some process for logging or monitoring purposes. That's a built-in option, so it was just an argument in our declaration of the Supervisor in the first place. The key thing to notice there is that anything that causes that child to crash will resolve the same, safe, way, from unpredicted packets, to the processor core it's running in being struck by a meteor. The other, perfectly fine child processes will keep chugging along, doing their own thing. Likewise, the Supervisor and Listener are protected from each other's failings. If the Listener fails, the top-level application supervisor will replace it, and likewise for the Supervisor for all the connection handlers. This synnergy of fault tolerance and concurrency is the key idea of Erlang, and by extension Elixir. It lets you code the pretty path, and accept that there are failure modes you can't or don't want to bother anticipating.

tempotemporary 3y ago

> It solves _so many_ problems of other comparable tech stacks right out of the box Could you expand top 5(or more) major pain points that it solves?

anonyfox 3y ago
I don't thinks that would be a helpful discussion right here. Any one point there might come someone who points at some external "solution" (package, tool, ...) that might also do the same feature in some way for X, ignoring the fact that there are lot of Y without that particular thing still, but leads into derailing the argument anyways. Elixir (and esp. Phoenix for web dev) is more like the culmination of the best ideas and heavily draws/depends on the last decades of real-world experience. Most stuff isn't (or shouldn't) be surprising, but the point is that everything you might need for the vast majority of projects is right there, nicely packaged up into a unified nice thingy. But to give you a few of _my_ top points: 1. Architecture and DX for complex interactions: there is no need to bring in supplemental infrastructure crutches (Redis, AWS whatever service, ...) in many cases to begin with. OTP, which is like a core library always available, already includes the building blocks for things like cache servers, application clustering and supervision strategies, ... . 2. Reliability and availability: this tech is the original one achieving the "nine-nines" of uptime record. To get an idea of how, https://www.youtube.com/watch?v=JvBT4XBdoUE https://www.youtube.com/watch?v=JvBT4XBdoUE this talked is packed and excellent, and also highlights a few things why it can achieve my point 1 above. 3. "SPA-like" interactivity with full server side rendering without all the pains of exposing/consuming a dedicated HTTP API in between, or overcomplicated nuances of rendering pipelines (also see react server components) to achieve SSR/CSR in a way that not sucks or is noticeably slow. Liveview is tried to be replicated in other stacks, but they don't come close in reality today or complicate the apps' infrastructure with additional crudges. And don't get me started on the integration testing story compared with SPA+Backend setups. 4. Agents/Message passing parallelism (not only concurrency, but also distributed!) at your fingertips, which makes modeling current "async problems" kinda trivial. OTOH, building something like a proper async-based web framework in rust is quite a pain in the ass, with lots of type fiddling needed, instead of doing the solution you actually want to deliver with it. 5. Some absolutely awesome takes on some typical libraries. Take the ORM options for javascript/typescript (all with severe tradeoffs, and analysis paralysis ontop). Take Rails' ActiveRecord with lots of magic and while great to get started becomes quickly bloated (iE fat models) in bigger projects. And then Ecto got it "just right" with slim schemas, changesets, and basically pure functions + pipelines. Any "model" can be used within new usecases by adding new changesets/validations explicitly and easily, there is no "general" validation right on the model level you have to tiptoe around, and starting If-cascades.
- clementai 3y ago
  I would add some more points. 6. Livebook, Jupyter notebook are amazing in Python, Livebook is the same but for Elixir. Also you can connect to your running environment and interact with it. 7. The Nx ecosystem, ML is not only a Python thing now, Elixir is completely usable for ML now. 8. Ash framework, this is not a web framework but a framework for your domain, it's amazing
  - anonyfox 3y ago
    absolutelt hard agree on livebook, but I think thats not an immediate thing every webdev needs. but speaking from recent practice, it is laughably simple and kinda mindblowing for non-experts in this stuff. Like, I klick me a few smart cells to interact with external data and get a connection/data, write a few straightforward logic modules to do something, and a super simple form for users of this thing (like two inputs and a submit button, and an event handler) and I can eliminate a business workflow or report. I can call a dev into it ad-hoc to help with a code snippet like a liveshare-coding-session. And finally I deploy it to a bookmarkable URL with a password. Maybe an hour worth of work, _including_ talking with people while fleshing this out in quick iterations as-we-speak. I mean people kinde get how cool phoenix is for one reason or the other, but livebook is really killing it for me. It's hard to talk with business people about tech internals no matter how awesome, but its a different game with lightweight livebooks. If you also happen to have phoenix as your actual product/app, linking the livebook indeed is nice to directly call functions instead of rewriting those snippets in SQL... but the endgame here is when the livebook starts to become unwieldly due to increasing feature requests, it can be integrated into a phoenix app rather easily, since a dev starts out with working code to begin with (and can play with it interactively).
    - throwawaymaths 3y ago
      > it can be integrated into a phoenix app rather easily I can't figure out how to do this.
      - anonyfox 3y ago

daxfohl 3y ago

I read that Brex moved away from Elixir to Kotlin. If Elixir was really that great then why would a company put such a big effort to ditch it? That killed off my interest in learning it, but maybe their reasons were invalid? Genuinely curious.

throwawaymaths 3y ago
I hear new Cto came in, got nervous about hiring. They are still hiring for elixir positions, though?
- weatherlight 3y ago
  i heard basically the same and also (the new CTO just really like kotlin and knew a bunch of people who know kotlin and wanted to bring them over. ) again, take the above with a grain of salt.
WJW 3y ago
Do you reject learning any language that has been migrated away from by any company? Why not make up your own mind about whether it is nice instead of depending on rumours about other companies? In any case you could have easily googled "brex elixir" and have found their blog explaining their reasoning as the first result: https://medium.com/brexeng/building-backend-services-with-kotlin-7c8410795e4b https://medium.com/brexeng/building-backend-services-with-ko...
- indigo0086 3y ago
  "Development speed: The future will be great and we want to get there fast. Our choice needs to help us move with urgency and focus. A type-system was a non-negotiable choice here." While Jose Valim did a good job in his talk about dispelling the idea of type system offering all these promises that may or may not be true, the idea will never die. This could mean that it is the right idea, but it could also mean that now's the time to look into a way to offer it in away it attracts people who have that perception while offering a type system of value.
3y ago

di4na 3y ago

Tbf. While more money to allows stability of people involved would help, it would not really speed it up that much. Typescript had ms behind it and it still took a decade. At some point the engineering, experiments and learning take time and you can hardly speed it up with more ressources.

anonyfox 3y ago
Maybe more like different layers could do different strategies? I can't even imagine what could happen to the BEAM itself if there are the same amount of ressources put on it like in our modern JS engines that have come a loooong way. Its already an amazing piece of tech in itself, but I wonder what an army of experts could do ontop of it.
- sodapopcan 3y ago
  Then we might have NPM for the BEAM--Uber popularity isn't always a good thing. Don't get me wrong, though, I want Elixir to get more popular.

josevalim 3y ago

I understand many would love to have this yesterday but I strongly believe we should not speed it up. :) This is potentially the largest change the language will ever go through and we are being very intentional and deliberate on every step and decision we make. Once we start collecting feedback from the community, it may speed up or slow down the process, but I want to make sure everyone gets plenty of time to experience and internalize the changes. When it comes to funding, the on-going work on Elixir type system is well funded by companies like Fresha, Starfish*, Supabase, and Dashbit. However, we also want to venture into new research areas, such as existential set-theoretic types, which would allow us to type behaviours (such as GenServer) similar to how one would type first-class modules in OCaml (or Typeclasses in Haskell). If someone is interested in sponsoring research work, hit me up (github.com/josevalim), and I can put you in touch with the proper institutions.

moljac024 3y ago
I would like to add that for what it's worth, I wouldn't mind slower compilation times if it means we get the type system as described. If it really does end up having a significant impact on performance, would you be open to making compile-time type-checking optional instead of scrapping the whole thing?
- josevalim 3y ago
  If it comes to this, we will certainly need to have a discussion on the topic. So I am definitely open to discussing the idea!

Aerbil313 3y ago

I’m curious. What exactly is Elixir good for? What do you find in it more appealing than other languages?

anonyfox 3y ago
I have listed a few points here in the other comment: https://news.ycombinator.com/item?id=37596258 https://news.ycombinator.com/item?id=37596258 as a more general/subjective/emotional note: The very pragmatic take on FP makes code in most cases so much easier to reason about. Immutability, no magic coming from some dark corner of the codebase unexpectedly, thinking in steps of data transformation from the get go, piping operator to make this visually pleasant, handling edge cases with pattern matches right at the function head level explicitly, ... and to have stateful stuff, there is OTP right on your fingertips with GenServer/Actor/ETS/... . And a genserver basically is only just another module that implements certain callbacks and then gets spawned. Modelling some scenarios are are breeze with that. And when I feel like I need some better syntax for some exotic problem I am dealing with, I can bend and stretch my language constructs via hygienic macros right away. And the whole experience is _extremely_ polished in terms of DX. docs, tests, doctests, interactive shell, a AOT-compiler, a JIT-runtime, and some very high-quality ecosystem bangers, like phoenix/livebook/membrane/boradway/Nx/Axon/... . Its like best of all worlds, and definitively the _very best_ choice for orchestrating stuff, which is a boon when you run into a problem you'd rather not use elixir for. Like building a native extension in rust/zig for some raw CPU task is a breeze. Its not so much the individual feature (no matter which one) but the overall package.
OkayPhysicist 3y ago
It's a functional, concurrent-first language. People have talked about the upsides of functional programming to death, either you prefer it or you don't. The concurrency story, though, is a significant advantage exclusive to the BEAM languages. They utilize green threads with message passing queues that we call "processes" (not to be confused with OS-level processes). A good almost-toy level project I built in Elixir was a Minecraft server proxy. At the top level, you've got a listener process, that waits for an incoming TCP connection, and a Supervisor process, who's responsible for the existing connections. When the listener receives a new TCP connection, it spawns a process under the Supervisor to handle that incoming connection, and goes back to listening. That's about 10 lines for code: 4 in the initiation (function declaration, start Supervisor, start Listener, end), and 6 in the Listener (function declaration, get new TCP connection, spawn process as a child of the Supervisor, assign TCP connection, recurse, end) The child processes are running a little state machine to do some parsing of the TCP stream. They receive TCP packets as a series of messages, and based on those messages they do various things. Unimportant for the purposes of explanation, except to say that the built-in gen-statem state machine handler simplifies it down to a series of functions that match a message, and produce a new state. But what if I receive a packet that I don't have a defined response to? Well, I don't need to write any extra code for that. When it fails to pattern match any of my states, the process is going to crash. Then it's children will crash (including the tcp connection, which will be closed by this operation), then it'll tell it's Supervisor "Alas, I am slain". By default, the Supervisor would replace it with a clone, passed the same initial arguments. But that's not the behavior we want here, we want it to just accept that the process has died, and maybe pass an alert to some process for logging or monitoring purposes. That's a built-in option, so it was just an argument in our declaration of the Supervisor in the first place. The key thing to notice there is that anything that causes that child to crash will resolve the same, safe, way, from unpredicted packets, to the processor core it's running in being struck by a meteor. The other, perfectly fine child processes will keep chugging along, doing their own thing. Likewise, the Supervisor and Listener are protected from each other's failings. If the Listener fails, the top-level application supervisor will replace it, and likewise for the Supervisor for all the connection handlers. This synnergy of fault tolerance and concurrency is the key idea of Erlang, and by extension Elixir. It lets you code the pretty path, and accept that there are failure modes you can't or don't want to bother anticipating.