The Why of Go
Вставка
- Опубліковано 26 бер 2018
- InfoQ Dev Summit Boston, a two-day conference of actionable advice from senior software developers hosted by InfoQ, will take place on June 24-25, 2024 Boston, Massachusetts.
Deep-dive into 20+ talks from senior software developers over 2 days with parallel breakout sessions. Clarify your immediate dev priorities and get practical advice to make development decisions easier and less risky.
Register now: bit.ly/47tNEWv
--------------------------------------------------------------------------------------------------------------------------------------
Download the slides & audio at InfoQ: bit.ly/2pK6Uwi
Carmen Andoh provides the historical context around the technical decisions of the Go language to better understand its concurrency primitives, garbage collection, and small standard library.
This presentation was recorded at QCon San Francisco 2017.
For more awesome presentations on innovator and early adopter topics check InfoQ’s selection of talks from conferences worldwide bit.ly/2tm9loz - Наука та технологія
Excellent talk. I like it when things are put into context.
The whole part about "simplicity" was almost jaw dropping. "I thought it was just me"...
Excellent talk
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.
Excellent talk. It expleins very well why programmers need language like Go.
This video got me thinking about a lot of things, very interesting to think of the design choices.
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.
This has some programmingcirclejerk potential.
the 1st rule of PCJ is you don't talk about PCJ outside of PCJ.
no one in the room laughed at the lougle joke smfh
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
Brilliant!
Loved this
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
Excellent!!!!!
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?
Fantastic!
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.
Amazing talk
this talk is on another level.
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)
I wonder what she would say about async/await in NodeJS. Seems a bit more forgiving than callbacks.
Very Informative
Loved this. Made me realise why some things in Go exist and don't exist
Great talk. History is important. Ignore the troll haters.
Thank you, _Lady from 1983_.
Great talk.
Amazing talk!
Thank you for taking the time to make this talk. Great work!
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).
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
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?
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
Insightful talk. thanks
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.
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.
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.
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.
Lovely video . Excellent explanation
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
@20:35 did she really say "a new idea of a callback"?! LOL
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.
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...
Completely agree with evrything! compliments!
Impressive talk!
Thank you for this talk, very insightful.
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.
tbh i think the gopher picture is kind of ugly (pls don’t be mad lol)
You can see that Go was influenced by Modula-2, which also started out as a systems programming language.
Carmen gets it - go is what the world needs today.
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.
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!
She stopped right at the point that she was supposed to tell us how better goroutine is compared to other thread model. Guess we need to read it ourselves, but then why I am watching this.
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.
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 😝
Cool idea 🔥
Amazing talk, thank you so much.
"Before I get started, I guess my name is Carmen..."
O_o
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.
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.
Interesting speech
WOW!
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.
TLDR:
hype
appeal to authority
it should be faster than a JVM
straw man
assumptions about simplicity
我听不懂啊
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?
wait, no ternary WAIT WUT?
Rust people be like 😂😂👌
@@ezengondolkozom3700 To be fair we have all control flow as expressions :D
Go Rust!
Lol, I made it to 6:00 and decided that was enough.
TLDR: GO is simple
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.
Hmmm ... Nice
Came here for the memes, where are the memes?
Fuck you and the memes
pokemon GO to the polls
why is no one laughing, what is this audience
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 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.}
I don't like the video. Stayed for the delorean.
ok, c++ it is then.
I am soooo happy not being part of this world.
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.
she is so full of hate , chillout
One word for this talk
Generic
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.
1. - "The real reason..." How do you know that? Your fragile ego of a self-claimed C++ guru doesn't automatically makes it "real".
2. Apart of your passion to some nerdish stuff and eltism of all kinds, your whole point makes no sense here (again), hence Go has NEVER been positioned as one to replace C/C++.
That's why:
Go: readability; maintaiability, fast compile/deployment time, simplicity, robustness etc
Vs
C++: relatively hard to read; HARD to maintain; slow to compile and a way harder to deploy(no single-file binary privilege); R E D U N D E N T ; extremely easy to break things etc
* Go has a GC which makes using it for performance-critical parts of an app even more absurdish.
3. Your ignorance multiplied by arrogance is really annoying, not the talk she gave.
4. Go is the reason I'm going to spend more time enjoying my life, instead of sitting in a shape of an S debugging some 30-y-o legacy code 🤣🤣🤣
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
Try importing a file from a subfolder. Oh wait, you can't.