Why We've Adopted Elixir
HTML-код
- Опубликовано: 16 май 2024
- Pusher is a hosted service with APIs, developer tools and open source libraries that greatly simplify integrating real-time functionality into web and mobile applications.
Pusher will automatically scale when required, removing all the pain of setting up and maintaining a secure, real-time infrastructure.
Pusher is already trusted to do so by thousands of developers and companies like GitHub, MailChimp, the Financial Times, Buffer and many more.
Getting started takes just a few seconds: simply go to pusher.com and create a free account. Happy hacking! 
Наука
Very Insightful, I really loved the presentation skills and technical clarity of the speaker. Outstanding slides with beautiful animations.
This is one of the best elixir presentations i've seen. Thanks mates! Been thinking a lot to move from ruby to elixir in the next years
I believe the default runtimes for Ruby and Python have something called a global interpreter lock, which prevents Threads in the language from actually running in parallel
What a great presentation. I appreciate the way you have shown what concurrency, parallelism are. The best explanation I've ever seen.
Amazing presentation. Really appreciate it!
Cool presentation. Thank you!
Elixir is built on the beam, not Erlang. They both compile down to the same bytecode and run on the beam virtual machine. It's different.
Nice presentation!
Great talk man, really funny examples :D
Amazing presentation, usually i use this video to convince people to join the community haha. I have been playing with elixir (and phoenix) for a while now, and absolutely love it.
Really good talk !
I'm looking forward to learn Elixir this year insha'Allah.
I'm a little disapointed that you built your tech on elixir but dont' have an official elixir client library
Really good and kind of down-to-earth presentation. The only thing I would probably add is that functions can have "catch all" pattern matching, so if none of the previous function definitions match the parameter(s) passed, you can have the last definition to handle any other case.
Example:
def convert("dog"), do: "good"
def convert("cat"), do: "evil"
def convert("duck"), do: "a bit quirky"
def convert(other), do: "don't know animal #{other}" # if a single string is passed but does not match the above
def convert(_), do: "invalid animal" # "fallthrough" variant - whatever comes to this stage, ignore the input and do what you want to do (like error handling)
You don't need def convert(_) here, since def convert(other) will catch everything. You'll get compilation warning here
@@oobaelda4264 Thanks for correcting me :)
No
@@Stopinvadingmyhardware yellow.
The thing I don't get it is - Yeah, let's have this bad match crash. But is it a 500 error tho? It should be handled as a 400 imho. Then, the whole "let's not focus on edge cases" argument begins to be flaky to me.
In other words, what is the elixir way to distinguish between bad input (400) and the actual "let it crash" philosophy? Do these two concepts overlap in some ways? Should I "let it crash" for 4XX errors? Should I raise a custom error, and let the supervisor handle it? But then, again, this starts to feel like a try-catch pattern from oo. I'm confused.
Good presentation but I still don't understand the benefit because we now run apps in containers which has orchestration. If a container fails a new one spins up. Containers are isolated so an error doesn't cause the whole app to go down.
I'll read more on Erlangs concurrency benefits.
Let containers self heal your network while elixir/Erlang can self heal the app. With app written in other languages you need both. In this case you can separate those concerns
A container is billions of times heavier in resources than an Elixir green thread
I think it's unfortunate that Erlang is described as a "weird" language. It might be unusual (unless you know Prolog) but it's very simple and can be learned in a day or two. Erlang is, in my view, much more succinct and elegant than Elixir. You'll spend orders of magnitude more time learning OTP if you use Erlang or Elixir, time spent learning the language is trivial by comparison.
My cat feels bad.
All the coughing in the background is weird in hindsight
To me it seems that elixir's concurrency model is like go's. Green threads called processes that are like go's goroutines.
They're both based on message passing (goroutines communicating through channels), so there's a lot of overlap! :)
@@Honken yup
Except in go, if a goroutine panics, it takes out the whole app.
They also share mutable state, and are not isolated for garbage collection.
Goroutines run in the same process space as main. Erlang equivalents can be running on different machines!
Erlang concurrency is on a different level to go. Go is handy, but primitive in comparison to Erlang
@@ChaoticTrack Well, you can make it do anything, given enough code :) In Go, you could catch panics in each individual goroutine using recover (see www.digitalocean.com/community/tutorials/handling-panics-in-go for example) ... but thats messy as hell :)
In the bigger scheme of things, your Go executable might be wrapped in a script / daemon that respawns it in a loop if it should die. Or launch it under Kubernetes or something similar to manage keeping the instance(s) alive. Thats a lot of complexity, but thats how you would manage "let it crash" in Go (or nodejs or a million other things that you would run under Kubernetes for example)
In Elixir, you get pretty much all of that Kubernetes' functionality already bundled into the runtime, using the Supervisor abstraction. Thats a bit mind blowing when you first run into it, but its essentially pretty simple once you start using it.
The main difference between a Go goroutine and an Elixir goroutine equiv (called a Process in Elixir speak) is that the Elixir goroutine is completely isolated from other goroutines. Isolated such that if it panics, just the goroutine stops, and its supervisor process will restart the goroutine automatically. Isolated also means that it has its own namespace for variables - there is no shared state between goroutines at all ! In Go, each goroutine can access all public data all over the app. Not so in Elixir. The only way to communicate is via sending a message and getting a reply.
This also affects garbage collection - in Go, the entire app stops everything and cleans everything at once. In Elixir, each individual goroutine / process has an independent garbage collector, that can make better choices about when it is safe to GC.
Elixir also gives you multi-node clustering for free. Imagine if you had a system with 12 machines on a network, and 1 single Go application you wanted to run. Then imagine each time you spawned a goroutine in that app, it would automatically host the goroutine on a separate physical machine, load balancing the 12 nodes. Elixir does that out of the box. It can only do that though because of the isolation - there is no shared data between processes, and you have to use messages to talk to them. Doing the same thing in Go would mean splitting up your app into multiple instances, and using gRPC or something to synch everything up.
Another major difference is that Elixir is more like an Operating System than a programming language. Using the REPL on a running app, its sort of like you can "ssh in" to your running app, and do stuff like list files, process statuses, examine variables, get a stack trace on each process ... hotload and recompile bits of code on the fly without restarting the app. Its nuts !
Its good fun - I found it a bit harder to get into that straight Go, but lots of hard problems are already solved before you write a single line of code. Dive in and have fun ! There are some decent videos floating around.
multiple instances of same node can solve concurrency problem
6:48 "concurrency is about the ability to handle multiple tasks at the same time". Umm.. not really, you're still only doing one thing at a time.
I guess accepting more requests at a time and not needing to wait for the previous request to be processed (I am a noob correct me if wrong)
He was careful to say "handle" and "execute" in the two definitions but unfortunately he didn't really clarify the distinction.
The dragging deep breaths every 4-5 words is just too annoying
XD cmon man, leave a nice word for the lad though
I don’t find it annoying
I agree. Loud breathing, swallowing sounds with a super sensitive mic placed literally 2 inches from the mouth makes for a super distracting and annoying experience. This is something that is as important as the content. Imagine if a speaker was chewing gun while doing presentation or spitting in a jar every now and then. It's in the same category and distracting from an otherwise great presentation.