All programming languages are built-up abstractions over a set of basic operations. Choosing a programming language is accepting the abstractions presented in that language... Everything else is religion.
All religions are built-up myths over a basic set of life questions. Choosing a religion is accepting the myths presented in that religion. Everything else is programming.
Gerard Gauthier absolutely not, metalanguages and LISP dialects operate are entirely different than static languages. The difference between dynamic and static languages; intermediate verifiers and proof oracles, makes each language a different ‘flavor’ of the IPS
Wrong, "accepting the abstractions" is a way not a whole story, there are much more properties to consider. You have a very narrow understanding of the subject.
Static Typed like Java and C++. Faster than Java on every benchmark. Faster compile time than C++. Readability like Python. Go is absolutely great language.
Yeah right. No generics, inefficient utility-functions for basic things like finding the length of a slice, horrible code origanization (everything that has to do with text, both io and basic strings is containted in the same module), insanly rigid and basic concurrency model, and it's simply just ugly, like python. Who the hell would put Python in the cathergory of great programing languages. Also, nil everywhere. It has no exception nor error handling so you have to return errors everywhere and check for them. To even suggest it is a great language, what were you thinking? At best, it is an ok tool for small apps for people who like corky weird stuff that is very imperfect in nature. The this needs to stay as a niche and never ever be considered in real app development.
Nice talk. I was looking for a Go talk that I could have on in the background while cooking. This was the perfect level for me. When I have time to sit down and watch source code in front of a computer then I'll do that. Really nice talk.
45:00 - "Simplicity and the Greater Good - while it's often seen negatively, in the context of order, sustainability and group cohesion it's a benefit and it's imperative that in some aspects of the organization it has to be enforced." AGREED!!
So go combines the best of event and threads because it has thread programming model (not callbacks as in event loop) but channels and green threads are much faster than mutex locks and system calls in threads. That took a long time to come out, I think.
Unfortunately green threads are not the be all end all - they have their own issues. Early Java had them, and abandoned them. Other newer languages too, e.g. Rust tried them and opted for actual threads too.
From my experience I do not trust nodejs at the server side, you can't sleep peacefully with it. One of the bulk excel generation done in PHP was taking too much time even more than 45 mins , exact same thing rewritten in Go took only 50 seconds to complete. Also deployment is easy as we need only single binary, also binary size is very small in size compared to Java. But frameworks in Go is still not mature as in Java or other popular languages so you have to write lot of code yourself compared to them. But once written it will run super fast.
@@taliluvhengo5928 2x??? Amateur, gods use video speed controller chome plug in get on the 3x speed or more, time has invaluable don't waste it watching things at 2x
With regards to utf-8 it's not always the best. utf-32 is better if you are working with a lot text in some Asian languages for example, since every character is the same width meaning you can index into an array and know where the characters are. You can't do that with utf8 and utf16.
tbh, you very rarely need to pick a character by its absolute index or offset. Most real world text processing tasks need iteration, one character at a time, and in this case there's almost no difference. For UTF-8 it would require a bit more processing (like calculating whether it's the last byte of the character) but it's negligible and can be hidden in the iterator logic. Go's range does exactly that (in the form of "for _, c := range str" where c gets the next rune aka unicode character) and it's implemented in the language syntax itself, not even in the standard library.
There are not many videos that try to defend Go. So I appreciate this. I must say, I'm still not convinced, I'm skeptical. I could just as much use another language and turn off language features with a build plugin. OK, maybe concurrency is good in Go, but green threads are not unique to Go, nothing new there. Please enlighten me.
How Carmen Andoh say in this talk "Go isn't about revolution. It's about simplicity.", I think this pretty well sums Go. If you need language that is clean, simple, elegant Go can be very good choice. If you want something new, you need to check other languages. "I could just as much use another language and turn off language features with a build plugin." I guess that createors will respons along this line. "Yes, you can. But this is unelegant workaround, also can be very unstable. We want elegant language from the start.".
you are correct, but simply "turning features off" is not really something you can expect when dealing with someone else's code. the point of go's forced simplicity is meant to facilitate maintainability and readability, not only when revisiting your own code 1 year later but also to pick up other people's code.
That brings a lot of problems with it. It makes every single development team into a language design team as well, something the vast majority of developers are simply not qualified for. This can lead to very poorly designed sub-languages, overly complicated style guides and lots of wasted time in code reviews. The larger the development team is and the more opinionated "seniors" you've got, the worse this problem becomes. Doubly so if you need to keep your spec in sync of multiple departments. You are bound to end up with the worst of both worlds and something resembling a big bag of compromises, rather than a properly thought out language. Look at C++ if you want to know how bad that gets, or Haskell, where you've got compiler extensions that you can enable on a per-file basis, if you want to see what a complete clusterfuck that can lead to. Obviously those two are rather extreme examples, but most languages are affected by this to some extent. I do love some of the more "advanced" features that you get with languages like Rust, but there is no denying that having four different ways to do the same things, each with their own level of sophistication, can make for very hard to read/review and maintain code. It can certainly make you feel very smart in the moment, but that counts for very little in the long run. Obviously not every language has the same potential for abuse, but there is a good reason why languages like Go or Elm get a lot of praise for their "simplicity". There is typically one way to do and structure something and if you ask two developers to implement the same feature you are going to get very similar code with a low "WTF"-factor. Honestly, "being smart" is what lead us into this whole OOP mess to begin with.
I just stumbled across this video because I'm dipping my toe into the Golang waters. I don't know who this is, but she is a fantastic teacher. I love listening to someone who can explain WHY something is the way it is. That makes it so much more accessible.
On a tangential note, there's a project called OpenResty which takes nginx and embeds the lua programming language's LuaJIT into it and gives you a few different slots where you can plug in your code. I've been using it to serve a small website with this and it works like magic. It's probably not the right solution for everything, but it's neat for a lot of things.
32:37 I am confused, I tried this. The zero value of a map is nil! If you try to insert things it will panic (kind of like a null pointer exception waiting to happen)
This is not just a great talk.. it's one of THE GREATEST TALKS EVER. So well researched. So well presented. So well argued. If this was a Go file, we need to import "reaction" and use StandingOvation(). Thank you.
People give props to Erlang all the time. That’s a lot different than saying others should use it. I would personally say Elixir is more receivable by a wider audience but it still doesn’t have as much weight behind it or anybody pushing it or … essentially marketing.
don't waste your time. there is no concrete argument here. it's frankly all over the place. I came here looking for reasons to like go, she didn't help. What I would like to know: - In practice, what exactly are the benefits of green threads over async programming? I have never used green threads before so I'm very curious about how it actually works in practice. - How to handle errors? I do not exaggerate when I say I find it extremely tedious to check errors. This not only slows down my productivity, it also results in very complex code. There must be a better way of doing this (I'm a fan of how rust handles errors).
Hello Zen Shinmae. About your first question, they both solve different problems and you can actually implement many concurrency models in Go. Language supported green threads however create a common language for implementing many concurrency models, it's a productive system together with channels, and they enable you to write your code synchronous first. It's encouraged in Go to write all your code synchronous when possible, which makes it trivial to make sure it's correct. Then making it work async is something you can do really simple with the Go language support, similarly to running a task in the background in Bash. About errors, it's tedious but extremely necessary, and it avoids your code blowing up all over the place. That said, your prayers are heard and a first implementation of a less tedious way of handling errors without giving up the safety Go errors give is in the works for Go 1.14. But also, Go errors are just values, so you can program with them and handle them however you want. Rob Pike has a great article about this. It all boils down to many things she said in her talk, but you will have to try out and experience the difference to know that she is not talking nonsense.
You're right. But to her defence, she's more on the business development side of things and not the design and architect side. Her speech is more like a college essay and presentation.
Nowadays, the core war has been pumping those thread count #s up QUICK (i.e 64 cores on a single dye w/ 2 threads per core on a DESKTOP CPU WITH DESKTOP TEMPERATURES).
A good PHP programmer can, (with a little effort) become an adequate golang programmer. (I doubt that they would ever manage to become a good Erlang programmer.) If amazing things like Erlang, Haskell and Scheme were easy then we wouldn't need the {idiot} "languages" for children like PHP and node.js
The Genealogy tree moves Javascript as a sideline of Java. Besides the name similarity there are not futher similiarities than both are coded in textform...
Is goal of this presentation to convince developers to use go? Is it about go ? I see bunch of random historical and "captain obvious" facts which does not tell exactly "why to use Go:" :) This is presentation about everything and nothing. You can use this presentation, just change arguments to proof that any language is better than others. It's kind of typical to pepople who have some higher technology overview, they dont understand whats going on but they want to sell some idea. She has good presentaiton skills but I have feeling that she is going to sell me something I dont need. As a fan of go language I dont give a shit :) Lost 40 minutes.
Once again demonstrating how absolutely useless the term "OOP" is to actually describe anything. Simula and Smalltalk, as well as Smalltalk and the languages that have actually come to define OOP (mostly Java) are vastly different from one another. Nobody can give you a straight answer about what it is and the only thing that overlaps is the fact that you can call namespaced functions, which implicitly (though we've seen some positive moves towards making this explicit) take the instance of type as their parameter, and are callable on an instance of a type, taking it as an argument for that parameter. It's a shit term and needs to die.
@@JaconSamsta I didn't write that OOP is good. Just pointing out a fact that Simula-67 was the first language that came up with the concept of so-called OOP.
@@TheSurvivor1963 I didn't comment on any supposed judgement on your part, no idea where you are getting that from. I'm just pointing out that it's a beyond useless term, at least in the way that most people use it.
@@RyanMartinRAM Yes of course, you can just write p := &i to get pointer p. But it dosen't have pointer arithmetics so code like varArray := [3]int{0, 1, 2} p := &varArray p = p + 2 shouldn't work.
Worst talk I've ever seen. So much bla bla no actual content. It's titled 'The Why of Go' not 'The great big history of everything surrounding Go but nothing about go itself' Good talk would have been: Show problem > show solution > explain solution > contrast solution with alternatives > Conclude and that's what Go is for. This kind of back and forth was a waste of time.
This talk seems to exude arrogance. I was surprised to hear the “appeal to authority” logical fallacy right up front. If go is designed for our new world of multi core and massive parallelism, why does this new and simple language devolve into the sync module and locking primitives to solve difficult problems? Why go?
Was this the first time the speaker saw this presentation? Time and time again, the speaker did not seem to know what was coming up in the next slide? So many mistakes. Very distracting.
I agree, simplicity makes way and gets you to do the thing you want to do instead of having to deal with side issues. You would have to be either a complete egomaniac or an idiot to fight against it or not see it in that way. Ultimately as programmers we all just want to get to the meat as fast as possible.
Don't waste your time watching this. Whatever she (and everyone else) is telling, the real reason behind using Go is the lack of C/C++ skills. Look at the slide at 11:47: all five points she makes is the manifestation of a C/C++ programmer's incompetence. And her smug presentation style is really annoying.
C and C++ are definitely not the answer to write correct and safe programs simply. Whether Go delivers on that promise is an entirely different topic but the motivation behind it is more than justified
LOL. And where do u find those C/C++ skilled developers in necessary quantities? It's like saying the real reason behind using C is the lack of Assembly language skills. Yes, it makes life infinitely easier. Look up the stats on the C/C++ production systems problem. 80% are memory leaks. It's the fact of life. And no dick measuring context can change that. Besides, C++ is crap, as the whole OOP thing. No wonder languages like Go, Rust, Zig have none of it
I think everything said here is correct, (and even if it isn't, with the massive weight of google behind golang, it is unstoppable,) and I don't mind that. {Please golang, save us from the lame duck that Gosling gave us.}
All programming languages are built-up abstractions over a set of basic operations. Choosing a programming language is accepting the abstractions presented in that language... Everything else is religion.
Well said broski
All religions are built-up myths over a basic set of life questions. Choosing a religion is accepting the myths presented in that religion. Everything else is programming.
Gerard Gauthier absolutely not, metalanguages and LISP dialects operate are entirely different than static languages. The difference between dynamic and static languages; intermediate verifiers and proof oracles, makes each language a different ‘flavor’ of the IPS
Wrong, "accepting the abstractions" is a way not a whole story, there are much more properties to consider. You have a very narrow understanding of the subject.
@@dracoford755 Oh yeah! I keep forgetting that LISP resides in the realm of magic and not algorithms and hardware. Like I said... religion.
Static Typed like Java and C++.
Faster than Java on every benchmark.
Faster compile time than C++.
Readability like Python.
Go is absolutely great language.
Yeah right. No generics, inefficient utility-functions for basic things like finding the length of a slice, horrible code origanization (everything that has to do with text, both io and basic strings is containted in the same module), insanly rigid and basic concurrency model, and it's simply just ugly, like python. Who the hell would put Python in the cathergory of great programing languages. Also, nil everywhere. It has no exception nor error handling so you have to return errors everywhere and check for them. To even suggest it is a great language, what were you thinking? At best, it is an ok tool for small apps for people who like corky weird stuff that is very imperfect in nature. The this needs to stay as a niche and never ever be considered in real app development.
Rust > Go
@@uziboozy4540 rust is pozzed
@@TroenderTass What do you prefer over it?
@@pubsvm7355 ☕ my dear friend
Excellent talk. I like it when things are put into context.
Nice talk. I was looking for a Go talk that I could have on in the background while cooking. This was the perfect level for me. When I have time to sit down and watch source code in front of a computer then I'll do that.
Really nice talk.
45:00 - "Simplicity and the Greater Good - while it's often seen negatively, in the context of order, sustainability and group cohesion it's a benefit and it's imperative that in some aspects of the organization it has to be enforced." AGREED!!
Excellent talk. It expleins very well why programmers need language like Go.
So go combines the best of event and threads because it has thread programming model (not callbacks as in event loop) but channels and green threads are much faster than mutex locks and system calls in threads. That took a long time to come out, I think.
Unfortunately green threads are not the be all end all - they have their own issues. Early Java had them, and abandoned them. Other newer languages too, e.g. Rust tried them and opted for actual threads too.
Excellent talk
From my experience I do not trust nodejs at the server side, you can't sleep peacefully with it. One of the bulk excel generation done in PHP was taking too much time even more than 45 mins , exact same thing rewritten in Go took only 50 seconds to complete. Also deployment is easy as we need only single binary, also binary size is very small in size compared to Java. But frameworks in Go is still not mature as in Java or other popular languages so you have to write lot of code yourself compared to them. But once written it will run super fast.
True about node. Java is so bloated and being run by oracle is a big turn off for a lot of developers.
I might wonder what made it so slow. Have you tried the same with swoole Coroutine?
The whole part about "simplicity" was almost jaw dropping. "I thought it was just me"...
Thank google-ness for 1.25 speed!
1.25? Noob! Pros go 2X
@@taliluvhengo5928 2x??? Amateur, gods use video speed controller chome plug in get on the 3x speed or more, time has invaluable don't waste it watching things at 2x
@@hipstergod haha cool. Will check it out
same. I set it to 1.25 and then forgot that it's already at 1.25
God bless you sir, I was about to close the video :D
You're not paid to program, you're not even paid to maintain someone else's program, you're paid to deliver solutions to the business.
Great talk. History is important. Ignore the troll haters.
no one in the room laughed at the lougle joke smfh
With regards to utf-8 it's not always the best. utf-32 is better if you are working with a lot text in some Asian languages for example, since every character is the same width meaning you can index into an array and know where the characters are. You can't do that with utf8 and utf16.
tbh, you very rarely need to pick a character by its absolute index or offset. Most real world text processing tasks need iteration, one character at a time, and in this case there's almost no difference. For UTF-8 it would require a bit more processing (like calculating whether it's the last byte of the character) but it's negligible and can be hidden in the iterator logic. Go's range does exactly that (in the form of "for _, c := range str" where c gets the next rune aka unicode character) and it's implemented in the language syntax itself, not even in the standard library.
This video got me thinking about a lot of things, very interesting to think of the design choices.
Nice, detailed talk.
There are not many videos that try to defend Go. So I appreciate this. I must say, I'm still not convinced, I'm skeptical. I could just as much use another language and turn off language features with a build plugin. OK, maybe concurrency is good in Go, but green threads are not unique to Go, nothing new there. Please enlighten me.
How Carmen Andoh say in this talk "Go isn't about revolution. It's about simplicity.", I think this pretty well sums Go. If you need language that is clean, simple, elegant Go can be very good choice. If you want something new, you need to check other languages.
"I could just as much use another language and turn off language features with a build plugin." I guess that createors will respons along this line. "Yes, you can. But this is unelegant workaround, also can be very unstable. We want elegant language from the start.".
you are correct, but simply "turning features off" is not really something you can expect when dealing with someone else's code.
the point of go's forced simplicity is meant to facilitate maintainability and readability, not only when revisiting your own code 1 year later but also to pick up other people's code.
Just try it. Simple language, way more than the sum of its parts. Learning it is more exciting than you would think. It doesn't need defending.
Go to other languages is like comparing CISC to RISC or is it RISC to CISC?😊
That brings a lot of problems with it. It makes every single development team into a language design team as well, something the vast majority of developers are simply not qualified for. This can lead to very poorly designed sub-languages, overly complicated style guides and lots of wasted time in code reviews. The larger the development team is and the more opinionated "seniors" you've got, the worse this problem becomes. Doubly so if you need to keep your spec in sync of multiple departments. You are bound to end up with the worst of both worlds and something resembling a big bag of compromises, rather than a properly thought out language.
Look at C++ if you want to know how bad that gets, or Haskell, where you've got compiler extensions that you can enable on a per-file basis, if you want to see what a complete clusterfuck that can lead to. Obviously those two are rather extreme examples, but most languages are affected by this to some extent.
I do love some of the more "advanced" features that you get with languages like Rust, but there is no denying that having four different ways to do the same things, each with their own level of sophistication, can make for very hard to read/review and maintain code. It can certainly make you feel very smart in the moment, but that counts for very little in the long run.
Obviously not every language has the same potential for abuse, but there is a good reason why languages like Go or Elm get a lot of praise for their "simplicity". There is typically one way to do and structure something and if you ask two developers to implement the same feature you are going to get very similar code with a low "WTF"-factor. Honestly, "being smart" is what lead us into this whole OOP mess to begin with.
Loved this. Made me realise why some things in Go exist and don't exist
Excellent!!!!!
I just stumbled across this video because I'm dipping my toe into the Golang waters. I don't know who this is, but she is a fantastic teacher. I love listening to someone who can explain WHY something is the way it is. That makes it so much more accessible.
This has some programmingcirclejerk potential.
the 1st rule of PCJ is you don't talk about PCJ outside of PCJ.
this talk is on another level.
She has an impressive ability to talk while saying nothing.
But I've still watched the full 48 minutes.
Wow. That’s what I was thinking 😂
She hasn’t provided any coherent logic behind WHY. Yet the talk seems interesting 😝
On a tangential note, there's a project called OpenResty which takes nginx and embeds the lua programming language's LuaJIT into it and gives you a few different slots where you can plug in your code.
I've been using it to serve a small website with this and it works like magic. It's probably not the right solution for everything, but it's neat for a lot of things.
Bruh
32:37 I am confused, I tried this. The zero value of a map is nil! If you try to insert things it will panic (kind of like a null pointer exception waiting to happen)
Fantastic!
TLDR:
hype
appeal to authority
it should be faster than a JVM
straw man
assumptions about simplicity
Kinda fun that there is no php on the map.
why?
Spaghetti code language
Not in the map but she talks about it. ua-cam.com/video/bmZNaUcwBt4/v-deo.html
god bless her
Amazing talk
This is not just a great talk.. it's one of THE GREATEST TALKS EVER. So well researched. So well presented. So well argued. If this was a Go file, we need to import "reaction" and use StandingOvation(). Thank you.
Brilliant!
Lovely video . Excellent explanation
Thank you for taking the time to make this talk. Great work!
tbh i think the gopher picture is kind of ugly (pls don’t be mad lol)
All that problems was solved with Erlang. No one give love to Erlang that make me sad 😞
People give props to Erlang all the time. That’s a lot different than saying others should use it. I would personally say Elixir is more receivable by a wider audience but it still doesn’t have as much weight behind it or anybody pushing it or … essentially marketing.
don't waste your time. there is no concrete argument here. it's frankly all over the place.
I came here looking for reasons to like go, she didn't help. What I would like to know:
- In practice, what exactly are the benefits of green threads over async programming? I have never used green threads before so I'm very curious about how it actually works in practice.
- How to handle errors? I do not exaggerate when I say I find it extremely tedious to check errors. This not only slows down my productivity, it also results in very complex code. There must be a better way of doing this (I'm a fan of how rust handles errors).
Hello Zen Shinmae. About your first question, they both solve different problems and you can actually implement many concurrency models in Go. Language supported green threads however create a common language for implementing many concurrency models, it's a productive system together with channels, and they enable you to write your code synchronous first. It's encouraged in Go to write all your code synchronous when possible, which makes it trivial to make sure it's correct. Then making it work async is something you can do really simple with the Go language support, similarly to running a task in the background in Bash.
About errors, it's tedious but extremely necessary, and it avoids your code blowing up all over the place. That said, your prayers are heard and a first implementation of a less tedious way of handling errors without giving up the safety Go errors give is in the works for Go 1.14. But also, Go errors are just values, so you can program with them and handle them however you want. Rob Pike has a great article about this.
It all boils down to many things she said in her talk, but you will have to try out and experience the difference to know that she is not talking nonsense.
You clearly missed the point
You're right. But to her defence, she's more on the business development side of things and not the design and architect side. Her speech is more like a college essay and presentation.
Very Informative
Hi all, what do you think the future of GO? should i learn it and change my stack to GO?
You don't have to change your stack. Have it as one of your tools.
Loved this
Finally!!! I get to be first with a video comment!! Took years to get to this point.
oh yeah this channel is so crowded
_lol_
Oof!
Nowadays, the core war has been pumping those thread count #s up QUICK (i.e 64 cores on a single dye w/ 2 threads per core on a DESKTOP CPU WITH DESKTOP TEMPERATURES).
Thank you, _Lady from 1983_.
Great talk.
I wonder what she would say about async/await in NodeJS. Seems a bit more forgiving than callbacks.
All the Go's 21st Century Characteristics was addressed by Erlang in 80's \0/
Heck maybe Joe Armstrong was a time travel!
A good PHP programmer can, (with a little effort) become an adequate golang programmer. (I doubt that they would ever manage to become a good Erlang programmer.) If amazing things like Erlang, Haskell and Scheme were easy then we wouldn't need the {idiot} "languages" for children like PHP and node.js
@@recklessroges care to elaborate why these are "children" languages? you know that there are billion dollar companies running on this langs, right?
Carmen gets it - go is what the world needs today.
Wow. What a great talk. Thanks for sharing!
If you are interested in more content about Go you can check out the dedicated page on InfoQ www.infoq.com/golang
The Genealogy tree moves Javascript as a sideline of Java. Besides the name similarity there are not futher similiarities than both are coded in textform...
Amazing talk!
Is goal of this presentation to convince developers to use go? Is it about go ? I see bunch of random historical and "captain obvious" facts which does not tell exactly "why to use Go:" :) This is presentation about everything and nothing. You can use this presentation, just change arguments to proof that any language is better than others. It's kind of typical to pepople who have some higher technology overview, they dont understand whats going on but they want to sell some idea. She has good presentaiton skills but I have feeling that she is going to sell me something I dont need. As a fan of go language I dont give a shit :) Lost 40 minutes.
OOP didn't start with Smalltalk, it started with Simula-67 already in 1960s.
Once again demonstrating how absolutely useless the term "OOP" is to actually describe anything. Simula and Smalltalk, as well as Smalltalk and the languages that have actually come to define OOP (mostly Java) are vastly different from one another.
Nobody can give you a straight answer about what it is and the only thing that overlaps is the fact that you can call namespaced functions, which implicitly (though we've seen some positive moves towards making this explicit) take the instance of type as their parameter, and are callable on an instance of a type, taking it as an argument for that parameter.
It's a shit term and needs to die.
@@JaconSamsta I didn't write that OOP is good. Just pointing out a fact that Simula-67 was the first language that came up with the concept of so-called OOP.
@@TheSurvivor1963 I didn't comment on any supposed judgement on your part, no idea where you are getting that from. I'm just pointing out that it's a beyond useless term, at least in the way that most people use it.
I think it is so great that Go DOESN'T have things like pointers arithmetics.
Go has pointers.
@@RyanMartinRAM Yes of course, you can just write p := &i to get pointer p. But it dosen't have pointer arithmetics so code like
varArray := [3]int{0, 1, 2}
p := &varArray
p = p + 2
shouldn't work.
Worst talk I've ever seen. So much bla bla no actual content.
It's titled 'The Why of Go' not 'The great big history of everything surrounding Go but nothing about go itself'
Good talk would have been:
Show problem > show solution > explain solution > contrast solution with alternatives > Conclude and that's what Go is for.
This kind of back and forth was a waste of time.
This talk seems to exude arrogance. I was surprised to hear the “appeal to authority” logical fallacy right up front. If go is designed for our new world of multi core and massive parallelism, why does this new and simple language devolve into the sync module and locking primitives to solve difficult problems? Why go?
Completely agree with evrything! compliments!
Impressive talk!
"Before I get started, I guess my name is Carmen..."
O_o
You can see that Go was influenced by Modula-2, which also started out as a systems programming language.
@20:35 did she really say "a new idea of a callback"?! LOL
Was this the first time the speaker saw this presentation? Time and time again, the speaker did not seem to know what was coming up in the next slide? So many mistakes. Very distracting.
I agree, simplicity makes way and gets you to do the thing you want to do instead of having to deal with side issues. You would have to be either a complete egomaniac or an idiot to fight against it or not see it in that way. Ultimately as programmers we all just want to get to the meat as fast as possible.
Don't waste your time watching this. Whatever she (and everyone else) is telling, the real reason behind using Go is the lack of C/C++ skills. Look at the slide at 11:47: all five points she makes is the manifestation of a C/C++ programmer's incompetence. And her smug presentation style is really annoying.
Agree with you sir ☺
Good luck with your C++ servers and your dangling pointers mate.
It's not a great speech but that wasn't her entire point.
C and C++ are definitely not the answer to write correct and safe programs simply. Whether Go delivers on that promise is an entirely different topic but the motivation behind it is more than justified
LOL. And where do u find those C/C++ skilled developers in necessary quantities? It's like saying the real reason behind using C is the lack of Assembly language skills. Yes, it makes life infinitely easier. Look up the stats on the C/C++ production systems problem. 80% are memory leaks. It's the fact of life. And no dick measuring context can change that.
Besides, C++ is crap, as the whole OOP thing. No wonder languages like Go, Rust, Zig have none of it
wait, no ternary WAIT WUT?
Rust people be like 😂😂👌
@@ezengondolkozom3700 To be fair we have all control flow as expressions :D
Amazing talk, thank you so much.
why is no one laughing, what is this audience
Thank you for this talk, very insightful.
Go Rust!
Cool idea 🔥
Interesting speech
I am soooo happy not being part of this world.
TLDR: GO is simple
Came here for the memes, where are the memes?
Fuck you and the memes
pokemon GO to the polls
Lol, I made it to 6:00 and decided that was enough.
I don't like the video. Stayed for the delorean.
WOW!
I think everything said here is correct, (and even if it isn't, with the massive weight of google behind golang, it is unstoppable,) and I don't mind that. {Please golang, save us from the lame duck that Gosling gave us.}
One word for this talk
Generic
Hmmm ... Nice
我听不懂啊
she is so full of hate , chillout
ok, c++ it is then.