This is pleasantly self-consistent: Russ extensively and with examples communicates the importance of communicating the issue importance with extensive examples.
They actually want to remove things but can't because of the 1.x promise :) Don't worry about bloat, worry about big companies that demand to keep a few mistakes in Go 2 because it's too expensive to adapt their code base.
One of the many talks in the past they mention that some code has to stay in no matter what because of the 1.x promise, thats why allot of proposals get rejected and even very good ones like a specific physics calculation optimisation, forgot the name, that was well thought of and completely ready to merge into the Go runtime source code so scientists could use it. Once its in it has to stay forever even if Rob Pike asks to remove it :) Personally i hate this kind of leaving things in mentality just for backward compatibility sake
It's keep coming to my mind that, why there are 700+ programming languages on earth, and different developer invest their precious time for developing/maintaing this languages. Why can't we have very few languages and keep them as efficient as possible together. In one term many people say , we are an open source community. But I keep thinking that even many open source languages so why people trying to solve a same problems on different platform or language at the same time.
wait. is go named after the ramones song "Blitzkrieg Bop"? did you see that message? Blitzkrieg Bob Hey! Ho! Let's go! They're all revved up and ready to go! if Larry Wall can claim later that Perl means the "Pathologicaly Eclectic Rubish Lister" then there's no reason why gophers can't adopt the Ramones...
Or just make reflect code more readable, I mean c'mon just the reflect naming conventions alone makes you drive insane. Reflect should been thrown in the garbage can and start over from scratch. Reflect clearly was a design mistake and was just put in because nobody had time to make something better.
What a stupid reply. If we could solve the generics issue without generics then we wouldn't need generics!?! Well duh! And writing "specific types to solve specific problems" IS boilerplate in most situations. Why should I have to reimplement a Binary Heap for every type I'm dealing with in every program? Why should I have to implement it at all? This should be a library solution but one which simply can't be written unless you use non type-safe code i.e. just look at the new sync.Map added in Go v1.9 it's a joke. The problem here is that these are all solved problems but the Go team refuses to learn from past improvements to compilers and languages. No one wants to complicate the language unnecessarily but jeez, generics would simplify most code ever written in Go even the standard library.
@@kalekold How does binary heap work with generics? Do you need to provide a comparrison function for the struct/class you are putting in a heap or something like that?
I love Rust but unfortunately they don't have a http2 server or client that is as complete as Go. Its still too low level to replace Go but once they have a bigger community then Go may be in trouble. Same for Swift and others they lack the dedicated production ready backend solutions Go offers currently.
The language you code in does not solve your ability to write code or communicate effectively. However when you say "just switch to Rust" you're dismissing all the pros of Go and implying there are no situations in which Go is a far better choice; which is not only objectively inaccurate, but naive and disingenuous too.
![Go + Microservices = Go Kit [I] - Peter Bourgon, Go Kit](http://i.ytimg.com/vi/NX0sHF8ZZgw/mqdefault.jpg)
This is pleasantly self-consistent: Russ extensively and with examples communicates the importance of communicating the issue importance with extensive examples.
He is a very clear speaker. Great job!
This was a really great talk! Wonderful presentation and great examples. Well done!
great guide on the design process and proposals in go
Please don't add much to the language. I just hate bloated languages like Java, C++, ... since I started using Go.
They actually want to remove things but can't because of the 1.x promise :) Don't worry about bloat, worry about big companies that demand to keep a few mistakes in Go 2 because it's too expensive to adapt their code base.
Interesting. Where do you got this from? I would like to know what they intended to remove.
One of the many talks in the past they mention that some code has to stay in no matter what because of the 1.x promise, thats why allot of proposals get rejected and even very good ones like a specific physics calculation optimisation, forgot the name, that was well thought of and completely ready to merge into the Go runtime source code so scientists could use it. Once its in it has to stay forever even if Rob Pike asks to remove it :) Personally i hate this kind of leaving things in mentality just for backward compatibility sake
I agree with you
That feels like the mantra of the talk to me. Idk.
Rigorous, for real problem and real solution, is worthy.
It's keep coming to my mind that, why there are 700+ programming languages on earth, and different developer invest their precious time for developing/maintaing this languages. Why can't we have very few languages and keep them as efficient as possible together. In one term many people say , we are an open source community. But I keep thinking that even many open source languages so why people trying to solve a same problems on different platform or language at the same time.
kim karry?
Non-nullable types please!
Is that Jim Carreys another joke?
same here
wait. is go named after the ramones song "Blitzkrieg Bop"?
did you see that message?
Blitzkrieg Bob
Hey! Ho! Let's go!
They're all revved up and ready to go!
if Larry Wall can claim later that Perl means the "Pathologicaly Eclectic Rubish Lister" then there's no reason why gophers can't adopt the Ramones...
0:20
Goto.... bad name
Generics!
or rather something that solves the same goals as generics would.
Or just make reflect code more readable, I mean c'mon just the reflect naming conventions alone makes you drive insane. Reflect should been thrown in the garbage can and start over from scratch. Reflect clearly was a design mistake and was just put in because nobody had time to make something better.
Sure... what?
What a stupid reply. If we could solve the generics issue without generics then we wouldn't need generics!?! Well duh! And writing "specific types to solve specific problems" IS boilerplate in most situations. Why should I have to reimplement a Binary Heap for every type I'm dealing with in every program? Why should I have to implement it at all? This should be a library solution but one which simply can't be written unless you use non type-safe code i.e. just look at the new sync.Map added in Go v1.9 it's a joke.
The problem here is that these are all solved problems but the Go team refuses to learn from past improvements to compilers and languages. No one wants to complicate the language unnecessarily but jeez, generics would simplify most code ever written in Go even the standard library.
@@kalekold How does binary heap work with generics? Do you need to provide a comparrison function for the struct/class you are putting in a heap or something like that?
I know how to solve all troubles - just switch to Rust ;) True modern language.
I love Rust but unfortunately they don't have a http2 server or client that is as complete as Go. Its still too low level to replace Go but once they have a bigger community then Go may be in trouble. Same for Swift and others they lack the dedicated production ready backend solutions Go offers currently.
Not http2 and still a long way from production ready code including https etc, it's not even close compared to Go http package
The language you code in does not solve your ability to write code or communicate effectively.
However when you say "just switch to Rust" you're dismissing all the pros of Go and implying there are no situations in which Go is a far better choice; which is not only objectively inaccurate, but naive and disingenuous too.
Switch to Rust to consolidate all problems into one big problem
Switch to rust, and continue deploying Go programs while your rust programs are compiling....