No, a goroutine that writes to a channel doesn’t necessarily block until another goroutine reads from the channel. It depends on if the channel is buffered or not.
Unbounded channels are dangerous as they will result in unbounded memory use if the receiver doesn’t manage to read them fast enough. That is why Go doesn’t support them through regular channels.
There were zero references to Elixir and not one concept discussed is related directly to Elixir. Elixir provides programmers with an arguably (very arguable) sweeter syntax. Its popularity speaks for itself: 4 out of 5 dentists surveyed prefer Elixir over Erlang which it sits on top of. Seasoned Erlang programmers see Elixir as a solution without a problem. IMO start with Erlang and stick with Erlang unless there is a compelling reason to switch.
tl;ngr: I felt like I've wasted my time with this one, so if you (fellow youtube user) know anything about channels and/or reactive programming, maybe move on to something else. Sorry but I really didn't like it. In my opinion this talk was very long winded with low information density, had bad slides and mediocre analogies. It was also bugging me a bunch that her whole point on Go channels forcing synchronization - which is okay in a lot of scenarios - is entirely built on not acknowledging the existence of buffered channels. (despite her even proposing a workaround that would emulate just that in her message queue example)
You must have watched a completely different talk then I did. She outlines the major differences that matter between message passing w/ CSP and actor model and the analogies made a lot of sense. For anyone looking at fundamental differences between Elixir and Go, that would be necessary to know. Also, while she didn't mention buffered channels in the talk, the blog post on unbounded channels she references touches on buffered channels. Not sure why it wasn't included and the message queue example was put there instead, though.
In a 29 minute talk comparing and contrasting the actor model in Erlang/Elixir and the CSP model in Go, your takeaway is about the pronouns on the first slide? Really?
Really helpful presentation, but really bad slides! The slide animations were making me feel dizzy!
Nicely done! Your short summary does a really good job of highlighting the benefits of the actor model in Erlang/Elixir.
Wow , you are great at this , thanks
22:49 - It's about 2000 times as much as a C program not 2 times...
Yeah I was thinking that too.
... beeecause .... Go binary includes garbage collector and the runtime?
2 mb hello world is "just twice as large as a C program"? was it some reference/analogy that i didn't understand?
This was great and very informative. Thank you.
No, a goroutine that writes to a channel doesn’t necessarily block until another goroutine reads from the channel. It depends on if the channel is buffered or not.
Thank for this talk :)
Thanks for watching!
No, a hello Go program is not twice as large as a hello world C program. Not that the size of hello world matters much in practice.
Did she just summarized all of operating systems in first few minutes?
Great talk!
Thanks Jeff!
This talk feels too opiniated for me. Anna should explain the drawbacks of both technologies (Execution, VM, consistency, etc.).
Unbounded channels are dangerous as they will result in unbounded memory use if the receiver doesn’t manage to read them fast enough. That is why Go doesn’t support them through regular channels.
1:28
Elixir seems to be nailing it....Quiet well
There were zero references to Elixir and not one concept discussed is related directly to Elixir. Elixir provides programmers with an arguably (very arguable) sweeter syntax. Its popularity speaks for itself: 4 out of 5 dentists surveyed prefer Elixir over Erlang which it sits on top of. Seasoned Erlang programmers see Elixir as a solution without a problem. IMO start with Erlang and stick with Erlang unless there is a compelling reason to switch.
Damn she is so interesting ❤
Slides were bad despite memes. :( But good talk.
And last rock climbing thing was a terrible analogy.
tl;ngr: I felt like I've wasted my time with this one, so if you (fellow youtube user) know anything about channels and/or reactive programming, maybe move on to something else.
Sorry but I really didn't like it. In my opinion this talk was very long winded with low information density, had bad slides and mediocre analogies. It was also bugging me a bunch that her whole point on
Go channels forcing synchronization - which is okay in a lot of scenarios - is entirely built on not acknowledging the existence of buffered channels. (despite her even proposing a workaround that would emulate just that in her message queue example)
You must have watched a completely different talk then I did. She outlines the major differences that matter between message passing w/ CSP and actor model and the analogies made a lot of sense. For anyone looking at fundamental differences between Elixir and Go, that would be necessary to know. Also, while she didn't mention buffered channels in the talk, the blog post on unbounded channels she references touches on buffered channels. Not sure why it wasn't included and the message queue example was put there instead, though.
Most people who enjoyed this talk are Erlang fanboys
@@StEvUgnInthey're still waiting for their app to compile
8:26 concurrency explained 3 black dudes on one chick, doing the process all at the same time.
I knew the slides were gonna be bad the moment I noticed she put her pronouns in the intro slide lol
Shoulda put pronouns on every slide
@@AlkzandrDenmanm1_x As an indication they're all bad?
Pronouns were clearly presented and there were diversity sponsors. Solving the big problems.
In a 29 minute talk comparing and contrasting the actor model in Erlang/Elixir and the CSP model in Go, your takeaway is about the pronouns on the first slide? Really?
@@johnneiberger😂 yall lost. woke dribble