He compared Go + Kubernetes to Erlang on BEAM. BEAM is not in the same category as K8. They may achieve the same goal of fault tolerance, but the level of complexity between the two setup are staggering.
14:43 This is why such mutex should be locked in a constructor and unlocked in a destructor. What if between f() and mutex.Unlock() there is more code that has a sneaky return statement? If for some reason unlocking must be managed outside RAII, put try{}catch(...){}, but this should only be your plan B.
Exceptions fit quite nicely in C++ because of RAII, which allows you to have both deterministic resource disposal and recovery, without introducing hacks like Go's defer, which forces you write a lot of copypasted boilerplate (increasing chances for a bug) and which isn't actually well designed to work with error handling. C++ doesn't have that problem with mutexes like 15:00 I guess people at Google were trying to write C++ more in the style of Java, hence they banned ecxeptions. And it's understandable why Go didn't include RAII like C++ because a proper implementation would have too complex semantics.
Keith R yes, there's two typos (and I mention it) No, I do not think I mixed stack and heap. The one calling new does allocate on the stack. That's the whole point. Thanks for the feedback, though.
Hmm the typo correction (to return *v) would mean you'd also want to change the return value type of value() to int, which means the space for the int would (generally) be already allocated in the stack of the calling function, so ultimately we're doing a ostensible heap allocation that gets promoted to a stack allocation (your well taken point, very cool) in the value() function, if stored in a variable and not just used as an intermediate value (say in a register), for a value that actually's already been allocated (if it needed to be at all, just for the sake of generating a throw-away pointer, so it might just get optimized away entirely). Anyways, now I want to play around with this :)
The comparison of the robustness of languages is not really useful. You can compare how easy it is to make robust programs, how much a language is able to guide you into robustness, but in the end, you can make robust programs in Go (or even C) and non-robust programs in Erlang. It just depends on how you use the tools the respective languages provide.
Sure you can technically make a robust program in any language, but I'd say the robustness/cost curve does matter. Consider trying to write a robust program in brainfuck vs C vs Go. If you hold everything else constant, I would guess C to be several orders of magnitude cheaper to write than brainfuck, and Go something like an order of magnitude cheaper to write than C, in the average case. This would be further exaggerated when adjusting for experience. Consider an inexperienced programmer writing in C vs an inexperienced programmer writing in Go.
JustForFunc: Programming in Go Yes, I commented halfway through. He went for the "surprise thesis" style of talk, so I commented when I got tired of him saying that Go was missing things required for robustness that had very intuitive idioms in any language, Go included.
You conflated the language with the runtime and VM. The Erlang VM provides features that the Go runtime lacks. But there is nothing inherent in the Go language that makes it not robust, it just comes with less out of the box: you have to plan for robustness. You point this out in the end (clearly Go as a language is fine for robustness if all you have to do to fix it's problems is add tools, not modify syntax), but only after spending more than half the talk comparing the languages.
Hot disappointing. It''s not about robustness, or any programming languages, it's boils down to a commercial talk about Kubernetes and the advantages of distributed architectures. You can replace Go with any decent statically typed language and Kubernetes with some other container/VMs orchestrator.
except Kubernetes is written in Go and wouldn't really be easy/possible without Go, and there are not really that many decent statically typed machine statically compiled languages ;)
@@LaPingvino I don't understand why that has anything to do with the language. BEAM is made for Erlang and one consider BEAM like a language feature of Erlang. In comparison K8 is a 3rd party tool that ameliorates some of the shortcomings of the language.
![Lp. Сердце Вселенной #60 РОЖДЕНИЕ ЛОЛОЛОШКИ [Финал] • Майнкрафт](http://i.ytimg.com/vi/YoR0pAV9FVQ/mqdefault.jpg)
Listening to Francesc Campoy is not only informative, is also fun.
He compared Go + Kubernetes to Erlang on BEAM. BEAM is not in the same category as K8. They may achieve the same goal of fault tolerance, but the level of complexity between the two setup are staggering.
Robustness was the comparison point, not environment complexity. That's a whole other debate.
14:43 This is why such mutex should be locked in a constructor and unlocked in a destructor. What if between f() and mutex.Unlock() there is more code that has a sneaky return statement? If for some reason unlocking must be managed outside RAII, put try{}catch(...){}, but this should only be your plan B.
Go has a better way of doing that, it's using the defer statement which executes a line of code after the function returns.
¡Buen video Francesc!
Exceptions fit quite nicely in C++ because of RAII, which allows you to have both deterministic resource disposal and recovery, without introducing hacks like Go's defer, which forces you write a lot of copypasted boilerplate (increasing chances for a bug) and which isn't actually well designed to work with error handling. C++ doesn't have that problem with mutexes like 15:00
I guess people at Google were trying to write C++ more in the style of Java, hence they banned ecxeptions. And it's understandable why Go didn't include RAII like C++ because a proper implementation would have too complex semantics.
What was the D talk about how hard it is to write a correct Hello World in C++? I didn't find it by searching.
Carl Johnson I'll try to find it, but it was by the creator of D itself
Great talk
I think I found it, check this one out: ua-cam.com/video/RlVpPstLPEc/v-deo.htmlm46s
Could you add a link to the interview that you mention at 27:00? Sounds interesting... Thanks.
hey @FrenchPirate83 found it!!
twitter.com/francesc/status/987492883904192512
"cuz i hate my life" lmao
Two typos (not one) in first code slide, then confuses stack and heap in the second slide commentary.
Keith R yes, there's two typos (and I mention it)
No, I do not think I mixed stack and heap. The one calling new does allocate on the stack. That's the whole point.
Thanks for the feedback, though.
Hmm the typo correction (to return *v) would mean you'd also want to change the return value type of value() to int, which means the space for the int would (generally) be already allocated in the stack of the calling function, so ultimately we're doing a ostensible heap allocation that gets promoted to a stack allocation (your well taken point, very cool) in the value() function, if stored in a variable and not just used as an intermediate value (say in a register), for a value that actually's already been allocated (if it needed to be at all, just for the sake of generating a throw-away pointer, so it might just get optimized away entirely).
Anyways, now I want to play around with this :)
The stack vs heap confusion I think came because I didn't realize 'value' was the name of your function lol
The comparison of the robustness of languages is not really useful. You can compare how easy it is to make robust programs, how much a language is able to guide you into robustness, but in the end, you can make robust programs in Go (or even C) and non-robust programs in Erlang. It just depends on how you use the tools the respective languages provide.
Sincere question: did you actually watch the talk?
Because that's exactly the point.
Sure you can technically make a robust program in any language, but I'd say the robustness/cost curve does matter.
Consider trying to write a robust program in brainfuck vs C vs Go. If you hold everything else constant, I would guess C to be several orders of magnitude cheaper to write than brainfuck, and Go something like an order of magnitude cheaper to write than C, in the average case.
This would be further exaggerated when adjusting for experience. Consider an inexperienced programmer writing in C vs an inexperienced programmer writing in Go.
JustForFunc: Programming in Go
Yes, I commented halfway through. He went for the "surprise thesis" style of talk, so I commented when I got tired of him saying that Go was missing things required for robustness that had very intuitive idioms in any language, Go included.
Nathan Schulzke that "him" is me, btw
You're telling me what I say about the language having issues is not true? In what ways?
You conflated the language with the runtime and VM. The Erlang VM provides features that the Go runtime lacks. But there is nothing inherent in the Go language that makes it not robust, it just comes with less out of the box: you have to plan for robustness. You point this out in the end (clearly Go as a language is fine for robustness if all you have to do to fix it's problems is add tools, not modify syntax), but only after spending more than half the talk comparing the languages.
Hot disappointing. It''s not about robustness, or any programming languages, it's boils down to a commercial talk about Kubernetes and the advantages of distributed architectures. You can replace Go with any decent statically typed language and Kubernetes with some other container/VMs orchestrator.
except Kubernetes is written in Go and wouldn't really be easy/possible without Go, and there are not really that many decent statically typed machine statically compiled languages ;)
I agree that the title is not really fitting but the talk is quite good imo
@@LaPingvino I don't understand why that has anything to do with the language. BEAM is made for Erlang and one consider BEAM like a language feature of Erlang. In comparison K8 is a 3rd party tool that ameliorates some of the shortcomings of the language.