My only gripe with Elixir is how rough the LSP autocompletion is, since the language uses argument based pattern matching to define functions. I can't wait for the new LSP that they started last Fall. If the LSP delivers, it will be a huge win.
Erlang's preemptive scheduler is underrated. When it comes to soft realtime systems, it makes all the difference. The peace of mind it gives you is liberating. Predictable latency FTW.
The BEAM and OTP are remarkable technologies. Elixir makes them more accessible, and the new type system is (I think) moving in the right direction. Phoenix is excellent, and it's really moving the standard for web frameworks forward. Jose is a great ambassador for these technologies, and every time I listen to him I learn something
Elixir is my 17th and final language. I remember back in the day working in telco watching the 5E phone switch engineers working with zero downtime. I used to think it was magic. Now I get to use that software every day.
Fascinating video that from an infrastructure perspective sounds kinda like attempts to extend the OSI model beyond the application layer. Makes me wonder if coders knew more about the OSI they could leverage it’s damn near bullet proof continuity of operations (error correction, fault tolerance, etc). I’m not a coder, yet, so I can’t know any of these answers but it’s still a fascinating conversation. I think many of the “spirent’ish” simulators use erlang. I know tsung does or did.
Listening more and more, ur kinda talking about switching, layer 2 switching which happens on MAC address (process id)…store and forward or cut through. All that codes opensource. I think the Cisco’s and junipers do this in asics however, which is how they get to full wire speed across unfathomably fast backplanes.
Focusing on learning Elixir and probably C or Odin this year. I'm trying to build something in those languages. I'm liking Elixir a lot so far! I'm also a huge fan of Scala, which seems to be massively slept on by tech streamers for some reason (probably the outdated bad rap from the earlier days when people went crazy overloading operators and abusing the type system).
I always wanted to develop in Elixir but I've never found anyone willing to adopt it even for a small project. Teams I've been a part of were scared of FP vs OOP and losing people that could maintain the code.
Elixir looks great aside from the syntax imo. Some people love it but I think it looks a bit ugly. Gleam to me seems like a nice alternative. Static typing, JS and Elixir package interop, and for me prettier and simpler syntax.
I love Gleam’s syntax and type system too. For now I use its JS target whenever I can get away with it. For backend, Elixir is just a lot farther along in terms of ecosystem maturity, as well as having a complete implementation of OTP, and to me that outweighs a great syntax
@ As someone who has never used any BEAM language, I don't know anything about OTP so you may have a point there. On your other point - can't all Erlang and most Elixir modules be used from within Gleam, unless the Elixir modules use some macro stuff? That was my understanding
@@tylerhainer8540 yes but in practice this comes with a lot of complications. I haven’t seen a great example of Gleam doing seamless interop with Elixir. A lot of the most important Elixir libraries rely heavily on macros. Also you usually have to treat data from other languages as “dynamic” and need to explicitly decode it for Gleam’s type system
I stack-hopped for like a year looking for the perfect fit and Elixir was it. Building something rad with it and just love working with it. Also it pairs great with Rust if you have CPU intensive tasks
@@jimmylarsson5425 So Elixir and BEAM languages have the ability to run native binaries (NIFs - natively implemented functions), which is particularly good if you want to crunch a lot of numbers. However a NIF is one of the few ways you can actually take the whole BEAM down - I think because it doesn't surrender control back to the scheduler like a normal process. So if you are using NIFs on the BEAM, Rust's memory safety can give you a lot of peace of mind. There's a great Elixir library called Rustler for using Rust NIFs.
@@jimmylarsson5425 So Elixir and BEAM languages have the concept of "NIFs" (natively implemented functions) where you can call functions compiled from C or Rust or Zig etc. Erlang is reasonably fast, but it's just not intended for CPU intensive number-crunching etc. So the catch with NIFs is that the BEAM scheduler can't "see" NIFs the same way it sees other functions etc, so you have to be careful using them because if something goes wrong NIFs are one of the very few ways you can crash the whole BEAM. Hence why Rust pairs well with Elixir - the safety guarantees are extra valuable in this context. There's an Elixir library called Rustler that's great for writing Rust NIFs. I've only played around with it. It works great and I might bring it into my current project if some of the more math-y stuff turns into a bottleneck.
¡Ojalá que la próxima entrevista técnica que me toque me la hagas vos, así no necesito esforzarme en inglés! ¿Precisás alguien que trabaje en el backend y que sepa Go? Bueno, llamame. 😁 ¿Cuándo te hacés la entrevista a vos mismo hablando de cómo fuiste a parar a Paraguay?
Here we go again bois, Ocaml isn't even on the list mentioned but gets mentioned, 2025 gonna be the year of people falling in love with Ocaml my Caml 🐫
Elixir is built on quicksand, there is no logical reason to learn it in 2025. It is actively pursuing its Python 3 moment. In a very real way, Gleam really signifies the beginning of the end. Elixir compiling to Erlang AST worked for a time but now they bear the burden of that decision.
@@pookiepats gleam also looks very interesting especially on the types, but as things stand, it's a niche language within what is already a niche ecosystem, and it's always difficult to bet on that. Elixir has broader support at this time, so that at least is a reason to learn it. A lot of the important beam and OTP ideas will be common across both languages - You can learn both.
@@krumbergify the issue is its lack of a proper type system, every time you hear the creator speak he speaks out of both sides of his neck-on the one hand “the importance of types is overstated” and on the other they’re in the throws of a multi year project to try and shoehorn a type system into the language when the community already has “Dialyzer” which aims to provide some semblance of static checking from a tooling perspective during dev. So why put so much effort into something that will displace an established tool if the importance is overstated and you already have your pattern matching? That’s a rhetorical question, anybody that has experienced static typing understands why. Anybody that has worked with Dialyzer at scale understands why. The issue is further exacerbated by Elixir compiling to Erlang AST and not bytecode (like Gleam does if you choose the Erlang runtime). It’s a problem because by compiling to Erlang AST, you’re now married to the decision making of an entirely different ecosystem (Erlang being a language that is proudly dynamically typed) unto itself. This is why I say it is built on quicksand. I’m sorry that it offends people but it’s just s fact, what is unfortunate is that people get so invested into a tool to the point where they get emotional and hurl insults. I experienced these shortcomings firsthand so I feel it’s necessary to put forth real experiences around the language to counter what I feel is a cultish language circle *** that goes on in most Elixir circles to the point where a newcomer might not get a real word view of what they’re signing up for until it’s too late.
@@SteveDoesStuff sure but better advice in my opinion and what spurned my comment is with the existence of Gleam, any newcomers are better served by Learning Gleam to access the benefits of the BEAM and use a different language like in place of Elixir that doesn’t suffer from its lack of static typing. The vast majority of devs will at some point converge with JavaScript, so why willingly introduce yet another dynamically typed language into your backend stack when you have statically typed alternatives-it’s just foolish/willed suffering at some point. People’s time is their own though, if you have that time to spare by all means learn all the languages you like.
My only gripe with Elixir is how rough the LSP autocompletion is, since the language uses argument based pattern matching to define functions. I can't wait for the new LSP that they started last Fall. If the LSP delivers, it will be a huge win.
Erlang's preemptive scheduler is underrated. When it comes to soft realtime systems, it makes all the difference. The peace of mind it gives you is liberating. Predictable latency FTW.
The BEAM and OTP are remarkable technologies. Elixir makes them more accessible, and the new type system is (I think) moving in the right direction. Phoenix is excellent, and it's really moving the standard for web frameworks forward. Jose is a great ambassador for these technologies, and every time I listen to him I learn something
Idk why this is my favorite tech podcast. It just is. Been waiting for the return!
We don't know why either
Brazil mentioned!
fr
Elixir is my 17th and final language. I remember back in the day working in telco watching the 5E phone switch engineers working with zero downtime. I used to think it was magic. Now I get to use that software every day.
José makes me proud of being a Brazilian (which is rare)
we are so back
I just started the video and i realized that i'm going to be here for while (need a cup of coffee)
I'm so excited that there's going to be 420 episodes this season!!!!!!!!!!
WELCOME BACK LANE 🚀
we are so back (and thanks)
Backend banter is back baby
José is the man! 🎉🎉
I was randomly watching an interview with Prime, TJ and Jose and you dropped this video.. wtf
Thanks!
np, enjoy!
Yoooooo this is fire 🔥🔥🔥
Thanks for the hard work to the whole team!
Banger first episode
not enforcing purity is a more pragmatic approach to FP
I've already learned some elixir in the past, but in the future I will come back. I am just waiting for the new LSP and more news on the type system
Watching Backend Banter for learning how to write good software: ❌❌❌
Watching Backend Banter just for Lane: ✅✅✅
Offended and flattered at the same time, love it
Fascinating video that from an infrastructure perspective sounds kinda like attempts to extend the OSI model beyond the application layer. Makes me wonder if coders knew more about the OSI they could leverage it’s damn near bullet proof continuity of operations (error correction, fault tolerance, etc).
I’m not a coder, yet, so I can’t know any of these answers but it’s still a fascinating conversation.
I think many of the “spirent’ish” simulators use erlang. I know tsung does or did.
Listening more and more, ur kinda talking about switching, layer 2 switching which happens on MAC address (process id)…store and forward or cut through. All that codes opensource. I think the Cisco’s and junipers do this in asics however, which is how they get to full wire speed across unfathomably fast backplanes.
If all the systems (vms) are in the same broadcast domain, which is very often the case. ARP tables maintain machine state automatically.
Let's goooo 💯🙌🏿💯
Gleam mentioned ⭐
Focusing on learning Elixir and probably C or Odin this year. I'm trying to build something in those languages. I'm liking Elixir a lot so far!
I'm also a huge fan of Scala, which seems to be massively slept on by tech streamers for some reason (probably the outdated bad rap from the earlier days when people went crazy overloading operators and abusing the type system).
I always wanted to develop in Elixir but I've never found anyone willing to adopt it even for a small project. Teams I've been a part of were scared of FP vs OOP and losing people that could maintain the code.
1:02:35 I thought you were going to call the rock Wilson.
I have done the exact thing you mentioned, Lane. I have tried to speak Spanish to non-spanish speakers hahaha
Elixir looks great aside from the syntax imo. Some people love it but I think it looks a bit ugly. Gleam to me seems like a nice alternative. Static typing, JS and Elixir package interop, and for me prettier and simpler syntax.
I love Gleam’s syntax and type system too. For now I use its JS target whenever I can get away with it. For backend, Elixir is just a lot farther along in terms of ecosystem maturity, as well as having a complete implementation of OTP, and to me that outweighs a great syntax
@ As someone who has never used any BEAM language, I don't know anything about OTP so you may have a point there. On your other point - can't all Erlang and most Elixir modules be used from within Gleam, unless the Elixir modules use some macro stuff? That was my understanding
@@tylerhainer8540 yes but in practice this comes with a lot of complications. I haven’t seen a great example of Gleam doing seamless interop with Elixir. A lot of the most important Elixir libraries rely heavily on macros. Also you usually have to treat data from other languages as “dynamic” and need to explicitly decode it for Gleam’s type system
I stack-hopped for like a year looking for the perfect fit and Elixir was it. Building something rad with it and just love working with it.
Also it pairs great with Rust if you have CPU intensive tasks
How are you pairing it with rust? :)
i have rust knowledge but just dipped a toe in Elixir land!
@@jimmylarsson5425 So Elixir and BEAM languages have the ability to run native binaries (NIFs - natively implemented functions), which is particularly good if you want to crunch a lot of numbers.
However a NIF is one of the few ways you can actually take the whole BEAM down - I think because it doesn't surrender control back to the scheduler like a normal process.
So if you are using NIFs on the BEAM, Rust's memory safety can give you a lot of peace of mind. There's a great Elixir library called Rustler for using Rust NIFs.
@@jimmylarsson5425 So Elixir and BEAM languages have the concept of "NIFs" (natively implemented functions) where you can call functions compiled from C or Rust or Zig etc. Erlang is reasonably fast, but it's just not intended for CPU intensive number-crunching etc.
So the catch with NIFs is that the BEAM scheduler can't "see" NIFs the same way it sees other functions etc, so you have to be careful using them because if something goes wrong NIFs are one of the very few ways you can crash the whole BEAM.
Hence why Rust pairs well with Elixir - the safety guarantees are extra valuable in this context.
There's an Elixir library called Rustler that's great for writing Rust NIFs. I've only played around with it. It works great and I might bring it into my current project if some of the more math-y stuff turns into a bottleneck.
@@jimmylarsson5425 I've now replied twice to this and seen it get deleted or something so if this reply sticks around I'll try again.
@@jimmylarsson5425 You can export Rust code to NIFs and import/call them via the `rustler` Hex package.
¡Ojalá que la próxima entrevista técnica que me toque me la hagas vos, así no necesito esforzarme en inglés! ¿Precisás alguien que trabaje en el backend y que sepa Go? Bueno, llamame. 😁
¿Cuándo te hacés la entrevista a vos mismo hablando de cómo fuiste a parar a Paraguay?
We're so back
never been more back
Yes
Wazzzuppp nerds
theo mentioned
Here we go again bois, Ocaml isn't even on the list mentioned but gets mentioned, 2025 gonna be the year of people falling in love with Ocaml my Caml 🐫
Lane keeps dunking on Rails in front of ex Rails maintainer and author of Rails book
I just can't help it
Short answer: No.
And now elaborate ...
Elixir is built on quicksand, there is no logical reason to learn it in 2025.
It is actively pursuing its Python 3 moment.
In a very real way, Gleam really signifies the beginning of the end.
Elixir compiling to Erlang AST worked for a time but now they bear the burden of that decision.
Please elaborate about what the issue is.
whole bunch of words to say nothing
@@pookiepats gleam also looks very interesting especially on the types, but as things stand, it's a niche language within what is already a niche ecosystem, and it's always difficult to bet on that. Elixir has broader support at this time, so that at least is a reason to learn it. A lot of the important beam and OTP ideas will be common across both languages - You can learn both.
@@krumbergify the issue is its lack of a proper type system, every time you hear the creator speak he speaks out of both sides of his neck-on the one hand “the importance of types is overstated” and on the other they’re in the throws of a multi year project to try and shoehorn a type system into the language when the community already has “Dialyzer” which aims to provide some semblance of static checking from a tooling perspective during dev. So why put so much effort into something that will displace an established tool if the importance is overstated and you already have your pattern matching? That’s a rhetorical question, anybody that has experienced static typing understands why. Anybody that has worked with Dialyzer at scale understands why.
The issue is further exacerbated by Elixir compiling to Erlang AST and not bytecode (like Gleam does if you choose the Erlang runtime).
It’s a problem because by compiling to Erlang AST, you’re now married to the decision making of an entirely different ecosystem (Erlang being a language that is proudly dynamically typed) unto itself.
This is why I say it is built on quicksand.
I’m sorry that it offends people but it’s just s fact, what is unfortunate is that people get so invested into a tool to the point where they get emotional and hurl insults.
I experienced these shortcomings firsthand so I feel it’s necessary to put forth real experiences around the language to counter what I feel is a cultish language circle *** that goes on in most Elixir circles to the point where a newcomer might not get a real word view of what they’re signing up for until it’s too late.
@@SteveDoesStuff sure but better advice in my opinion and what spurned my comment is with the existence of Gleam, any newcomers are better served by Learning Gleam to access the benefits of the BEAM and use a different language like in place of Elixir that doesn’t suffer from its lack of static typing.
The vast majority of devs will at some point converge with JavaScript, so why willingly introduce yet another dynamically typed language into your backend stack when you have statically typed alternatives-it’s just foolish/willed suffering at some point.
People’s time is their own though, if you have that time to spare by all means learn all the languages you like.