02:42 Don't communicate by sharing memory, share memory by communicating. 03:42 Concurrency is not parallelism. 04:20 Channels orchestrate; mutexes serialize. 05:18 The bigger the interface, the weaker the abstraction. 06:25 Make the zero value useful. 07:36 interface{} says nothing. 08:43 Gofmt's style is no one's favorite, yet gofmt is everyone's favorite. 09:28 A little copying is better than a little dependency. 11:10 Syscall must always be guarded with build tags. 11:52 Cgo must always be guarded with build tags. 12:37 Cgo is not Go. 13:50 With the unsafe package there are no guarantees. 14:34 Clear is better than clever. 15:23 Reflection is never clear. 16:13 Errors are values. 17:27 Don't just check errors, handle them gracefully. 18:10 Design the architecture, name the components, document the details. 19:08 Documentation is for users.
That's the reason I ended up watching this video after following links on criticism of code reusability. I guess people just need to understand what they are coding and why, what are the pros and cons etc and not follow 'best practices' blindly...
If I understood the reasoning behind "Design architecture, name the components, document the details" properly, I think a more 'poetic' proverb would be "A rose by any other name would not be thought a rose." If I said 'stop to smell the flowers' instead of 'stop to smell the roses,' someone may imagine tulips or pansies. It's only when the names are clear can the reader better understand us. Did I get the meaning behind that one right??
Nope. Me too. Something is broken but we can only report "misconduct" not actual technical issues. I believe TH-cam has fucked up the video because I have watched it before and it wasn't like this.
Is anybody else seeing the video image of a completely different dude, while listening to Rob Pike? Is that something weird in TH-cam, in this video, ... ?
I like Go, but I do have one issue with it. What do you have against src/ folder? I just don't like having go files in the root of the project and I don't want to use outdated build systems like make.
I love this presentation, Its so true what he says. And I am not a go developer, instead I wrote most of my programms using java and c#. I love how he rants about other languages :-)
Don't communicate by sharing memory, share memory by communicating. Concurrency is not parallelism. Channels orchestrate; mutexes serialize. The bigger the interface, the weaker the abstraction. Make the zero value useful. interface{} says nothing. Gofmt's style is no one's favorite, yet gofmt is everyone's favorite. A little copying is better than a little dependency. Syscall must always be guarded with build tags. Cgo must always be guarded with build tags. Cgo is not Go. With the unsafe package there are no guarantees. Clear is better than clever. Reflection is never clear. Errors are values. Don't just check errors, handle them gracefully. Design the architecture, name the components, document the details. Documentation is for users. Don't panic.
Minimal interfaces are a behavioural thing a cultural thing. It's not really a java thing to be honest. Best practices followed by most OO programmers is to build specific interfaces. Be it in java or some other language.
The more you say "who cares" based on your personal taste rather than rational thinking, the more you attract cult following rather than general users, which partly tells the distance of impact between Plan 9 and Unix, golang and C, even considering all have their gene deeply rooted from Bell Labs.
he extols the virtues of smaller interfaces, even touting the empty interface and then later says "it's not for you". pretty contradictory but he also says that's okay. half the reason i see to use empty interfaces (and then later reflection) is because the language won't accept less-stringent type checking.
“The rules of chess as they are known today emerged in Europe at the end of the 15th century, with standardization and universal acceptance by the end of the 19th century.” You can’t google?
12:03 "I know we think of C as a portable language in the old world, but it's really not" - so, so overwhelmingly WRONG. The fact that Mr Pike doesn't know his C standard and thus cannot write portable C code without making unportable assumptions about sizeof(int) is not the language's fault. It's perfectly possible to write portable C if one knows the language sufficiently well.
Árpád Goretity just take any library written for Unix or osx and try to compile it on Windows. or even better take a library for x86 and compile it for arm. most of the time it won't work. while in theory C is portable, in reality it's not.
You are conflating developers' unability to write portable C with C being non-portable. I have written several libraries that compile and behave identically on Unices and Windows, on ARM and on x86. It's all about whether you know your language. Non-portable code is not the fault of the language: it's the fault of those who make unjustified assumptions. Unfortunately, due to who knows what (maybe partly due to the way C and C++ are taught in university these days), most "C programmers" have no idea about the abstract model described by the C standard, can't related the C execution model to the platform and hardware they are targeting, and seem to think that once it works on their machine, it's declared victory. If you have a look at some code written by experienced C programmers, who program against the C Standard, not against random tutorials and cargo-cult-driven assumptions, you will find that much of their code is highly flexible and parametrized by e.g. the use of constants in limits.h, aware of possible differences in size and conversion rank between implementation-defined types such as int and unsigned char, etc., etc. All in all, the majority of "C programmers" writting crappy code doesn't mean that C isn't portable. It perfectly is portable, you just have to respect and use its true specification rather than self-proclaimed assumptions.
But it is not. ANSI C might be, but why e.g. do I have to use WinMain on windows and main on *nix systems? I know there are frameworks like Gtk and Qt that do that for me, but why do I need them? If C would be portable I wouldn't need those frameworks. What are preprocessor flags and defines often used for? To write different code based on different platforms my code will be compiled for, or even for different compilers that are not fully compatible to each other. In C data types can have way different sizes because they are just not defined in the standard. An int is "at least 16 bits" is not a good definition for a basic data type. And finally YOU might be able to write code that runs on all platforms, but the industry is not. The open source community often isn't as well. The transition from 32-bit to 64-bit has taken years even for programs that actually benefit from the architecture. Why? Because a lot of old code just wasn't programmed in a portable way and had to be completely rewritten or replaced.
The C Standard specifies that the entry point of a program is main. If something has an entry point called WinMain, that's not C by definition. However, that's not "on Windows". Don't confuse compiling on Windows by compiling with MSVC. By the way, you don't *have to* use WinMain even with MSVC, it's just the (stupid) default. By passing the "/subsystem:windows /ENTRY:mainCRTStartup" flags to the linker (possibly through a pragma comment in the source), it will behave as a standard toolchain in this regard. In addition, its C compiler conforms to C90. There are also other compilers that run on Windows (e.g. GCC does run there using MinGW or Cygwin). Furthermore, Windows is not the only other OS. If you write conforming C, it will run correctly on many Unix-like and non-Unix-like platforms (including some quite exotic ones, e.g. microcontrollers). "If C would be portable I wouldn't need those frameworks." - false, you need those frameworks *primarily* in order to do graphics. That is because the C Standard doesn't specify graphical capabilities for the C Standard Library. If you need anything that the C Standard Library doesn't do, you will either have to write it yourself or use a 3rd-party library. That's entirely orthogonal to portability. Of course, many libraries provide platform-independent abstractions over platform-specific libraries, but that is not related to the language. For example, macOS uses AppKit and Quartz, while Windows uses WinAPI, *regardless* of what language you are calling them from. If you are trying to do graphics on Windows and macOS without a cross-platform library, you will end up writing conditional code anyway, in every language, not just in C. Preprocessor-based configuration, in my experience, is also limited to "if Windows… else…". Yeah, Windows is a deviant and stupid environment, hostile to developers. But it's only one platform out of the who knows how many that C runs on. "In C data types can have way different sizes because they are just not defined in the standard." - I'm perfectly aware of that, yes. However, the designers of C were careful enough to include information about these facts in the standard library, as this design decision was deliberate, not accidental. It's a shame people don't use limits.h, float.h, and stddef.h. Those headers (among others) allow one to write truly portable code without making unsound assumptions about the underlying hardware. "And finally YOU might be able to write code that runs on all platforms, but the industry is not." - which is sad, but again, don't blame it on the language. Blame it on the careless/inexperienced/lazy/stupid/etc. programmers who write shitty code. You can write non-portable code in any language. You can write non-portable code in Go, or in Java, or in Haskell, or in Rust, you name it. E.g. if your coding style is replacing shell scripts with ${LANG} by just calling out to the shell and invoking system tools, then boom, your code just became non-portable. And this is only a trivial example. There are many more aspects to portability (filename separators, case sensitivity throughout the OS, whatever) that won't (because they can't) be covered by, or related to, the language. This doesn't "make the language non-portable".
It's not wrong. "Portable C" isn't a special kind of C marked as such in the source code in some fashion. It's not trivial to determine if a given program written in C is portable or not. In Go, it's *relatively* trivial: if the code imports Syscall or Cgo (or imports something which uses them), it's not portable; otherwise it should be portable.
02:42 Don't communicate by sharing memory, share memory by communicating.
03:42 Concurrency is not parallelism.
04:20 Channels orchestrate; mutexes serialize.
05:18 The bigger the interface, the weaker the abstraction.
06:25 Make the zero value useful.
07:36 interface{} says nothing.
08:43 Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.
09:28 A little copying is better than a little dependency.
11:10 Syscall must always be guarded with build tags.
11:52 Cgo must always be guarded with build tags.
12:37 Cgo is not Go.
13:50 With the unsafe package there are no guarantees.
14:34 Clear is better than clever.
15:23 Reflection is never clear.
16:13 Errors are values.
17:27 Don't just check errors, handle them gracefully.
18:10 Design the architecture, name the components, document the details.
19:08 Documentation is for users.
thanks
This should be in the description
Rob is a true Mozart of Go, and listening to this talk was a music to my ears.
"when you doubt your powers, you give power to your doubts" -- The Sphinx
great talk, rob is a real programming master.
"Give descriptive names" is in stark contradiction to giving the receivers with one letter names
That jacket is mesmerizing....Excelllent go style.
10:00 standing ovation; I always thought it and now I have a reference for it :D
That's the reason I ended up watching this video after following links on criticism of code reusability. I guess people just need to understand what they are coding and why, what are the pros and cons etc and not follow 'best practices' blindly...
Around 8:30 : I've seen `...interface{}` a handful of times as a function parameter, and it feels like optional arguments.
Love the fact that he doesn't laugh at his own jokes :D
@Corliss Sanluis "joined 1 week ago"
If I understood the reasoning behind "Design architecture, name the components, document the details" properly, I think a more 'poetic' proverb would be "A rose by any other name would not be thought a rose."
If I said 'stop to smell the flowers' instead of 'stop to smell the roses,' someone may imagine tulips or pansies. It's only when the names are clear can the reader better understand us. Did I get the meaning behind that one right??
nice jacket
Am I the only one seeing a different video the the audio isn't matching?
Nope. Me too. Something is broken but we can only report "misconduct" not actual technical issues. I believe TH-cam has fucked up the video because I have watched it before and it wasn't like this.
@@JohnLeidegren yeah. it works fine on mobile, but fucks up on PC
Is anybody else seeing the video image of a completely different dude, while listening to Rob Pike?
Is that something weird in TH-cam, in this video, ... ?
I like Go, but I do have one issue with it. What do you have against src/ folder? I just don't like having go files in the root of the project and I don't want to use outdated build systems like make.
Can I get these proverbs in asynchronous text format please? And linked from the proverbs website?
Little and composable interfaces is an Golang idea? Ad-hoc polymorphism is not a new thing though.
import "this"
The Zen of Go
package this is not in GOROOT 😭
In the github page for this I see a last proverb, `don't panic`, but it's not covered here. Does anybody know what does that mean?
It means "don't use panic() as a try-catch flow control for expected things like I/O errors, etc. Instead, return error values"
This man is a legend.
At 8:50 I came to realize that Rob Pike is my spirit animal
Q: Rob, what about generics?
A: 8:56
so funny and insightful! also, i love that damn jacket :D
(hmm... i must be in the minority, i actually like gofmt format)
+Matt Siegel I think Rob's point was more that most gophers have at least one thing that they'd like gofmt to do a little differently.
In go, like in go, continued play in an interface removes aji(good or bad)
The world needs more Rob's talks.
So, if I learn Go well enough, I get to wear this jacket at work as well?
总结得非常经典，受教了。
great talk!
Video and the sound doesnt match
Very insightful!
I love this presentation, Its so true what he says.
And I am not a go developer, instead I wrote most of my programms using java and c#. I love how he rants about other languages :-)
19:14 19:15
Don't communicate by sharing memory, share memory by communicating.
Concurrency is not parallelism.
Channels orchestrate; mutexes serialize.
The bigger the interface, the weaker the abstraction.
Make the zero value useful.
interface{} says nothing.
Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.
A little copying is better than a little dependency.
Syscall must always be guarded with build tags.
Cgo must always be guarded with build tags.
Cgo is not Go.
With the unsafe package there are no guarantees.
Clear is better than clever.
Reflection is never clear.
Errors are values.
Don't just check errors, handle them gracefully.
Design the architecture, name the components, document the details.
Documentation is for users.
Don't panic.
import zen
so inspiring!
Minimal interfaces are a behavioural thing a cultural thing. It's not really a java thing to be honest. Best practices followed by most OO programmers is to build specific interfaces. Be it in java or some other language.
Wearing batik jacket, one of the heritage from Indonesia
OMG, Rob has such a sense of humor. ROFL on the joke about python.
7:58 The joke about Python.
8:47 Another joke. But not about Python.
16:55 Another joke.
Gofmt style’s no one’s favorite, yet Gofmt is everyone’s favorite- Rob Pike
Interacting with a program that better handles error is similar or close to interacting with a human !!
0:47 Since when is chess a Western game? :-)
@5.24 😆
The more you say "who cares" based on your personal taste rather than rational thinking, the more you attract cult following rather than general users, which partly tells the distance of impact between Plan 9 and Unix, golang and C, even considering all have their gene deeply rooted from Bell Labs.
If you come from java, everything is bigger 😏
Go User doing some abstraction and goes wrong; Go Author: u are idiot, you are beginner who overused things you shouldn't.
Worst Mother's Day gift idea... EVAH.
+Isaac Andrade you rang?
"Think really hard when using empty interfaces if there isn't really something that you could put into..." - A generic type, perhaps?
he extols the virtues of smaller interfaces, even touting the empty interface and then later says "it's not for you". pretty contradictory but he also says that's okay. half the reason i see to use empty interfaces (and then later reflection) is because the language won't accept less-stringent type checking.
Chess isn't a western game...
Chess is not a original western Game, it came from eastern countries to Europe and America. Rob is wrong.
en.wikipedia.org/wiki/Chess#History
The modern chess, that everyone plays today, is a western game. It's certainly built upon the eastern variants from Persia, India, etc. though.
this feels like the gofmt rule should apply here. Nobody cares if the history given is accurate, more that it's device helped the story.
Since when chess is a western game? [ for the record I respect Rob Pike a lot, but still ]
+Ali Moeeny When western get something, it's became thinks that it's own.
+Ali Moeeny To be fair, while the origins of Chess lie in India, the Chess we know today was first played in Europe.
Wikipedia links to this, nice overview: history.chess.free.fr/papers/Calvo%201998.pdf
@@enneff
It evolved, that's true. But it does not make it a western game!
Since when chess is a western game? 🤣
I was about to comment that xD
because it is. chaturanga isn’t chess
@@verbosed well juggernaut isn't Jagannath, I get the frustration.
“The rules of chess as they are known today emerged in Europe at the end of the 15th century, with standardization and universal acceptance by the end of the 19th century.”
You can’t google?
12:03 "I know we think of C as a portable language in the old world, but it's really not" - so, so overwhelmingly WRONG. The fact that Mr Pike doesn't know his C standard and thus cannot write portable C code without making unportable assumptions about sizeof(int) is not the language's fault. It's perfectly possible to write portable C if one knows the language sufficiently well.
Árpád Goretity just take any library written for Unix or osx and try to compile it on Windows. or even better take a library for x86 and compile it for arm. most of the time it won't work. while in theory C is portable, in reality it's not.
You are conflating developers' unability to write portable C with C being non-portable. I have written several libraries that compile and behave identically on Unices and Windows, on ARM and on x86. It's all about whether you know your language. Non-portable code is not the fault of the language: it's the fault of those who make unjustified assumptions. Unfortunately, due to who knows what (maybe partly due to the way C and C++ are taught in university these days), most "C programmers" have no idea about the abstract model described by the C standard, can't related the C execution model to the platform and hardware they are targeting, and seem to think that once it works on their machine, it's declared victory. If you have a look at some code written by experienced C programmers, who program against the C Standard, not against random tutorials and cargo-cult-driven assumptions, you will find that much of their code is highly flexible and parametrized by e.g. the use of constants in limits.h, aware of possible differences in size and conversion rank between implementation-defined types such as int and unsigned char, etc., etc. All in all, the majority of "C programmers" writting crappy code doesn't mean that C isn't portable. It perfectly is portable, you just have to respect and use its true specification rather than self-proclaimed assumptions.
But it is not. ANSI C might be, but why e.g. do I have to use WinMain on windows and main on *nix systems? I know there are frameworks like Gtk and Qt that do that for me, but why do I need them? If C would be portable I wouldn't need those frameworks.
What are preprocessor flags and defines often used for? To write different code based on different platforms my code will be compiled for, or even for different compilers that are not fully compatible to each other.
In C data types can have way different sizes because they are just not defined in the standard. An int is "at least 16 bits" is not a good definition for a basic data type.
And finally YOU might be able to write code that runs on all platforms, but the industry is not. The open source community often isn't as well. The transition from 32-bit to 64-bit has taken years even for programs that actually benefit from the architecture. Why? Because a lot of old code just wasn't programmed in a portable way and had to be completely rewritten or replaced.
The C Standard specifies that the entry point of a program is main. If something has an entry point called WinMain, that's not C by definition. However, that's not "on Windows". Don't confuse compiling on Windows by compiling with MSVC. By the way, you don't *have to* use WinMain even with MSVC, it's just the (stupid) default. By passing the "/subsystem:windows /ENTRY:mainCRTStartup" flags to the linker (possibly through a pragma comment in the source), it will behave as a standard toolchain in this regard. In addition, its C compiler conforms to C90. There are also other compilers that run on Windows (e.g. GCC does run there using MinGW or Cygwin). Furthermore, Windows is not the only other OS. If you write conforming C, it will run correctly on many Unix-like and non-Unix-like platforms (including some quite exotic ones, e.g. microcontrollers).
"If C would be portable I wouldn't need those frameworks." - false, you need those frameworks *primarily* in order to do graphics. That is because the C Standard doesn't specify graphical capabilities for the C Standard Library. If you need anything that the C Standard Library doesn't do, you will either have to write it yourself or use a 3rd-party library. That's entirely orthogonal to portability. Of course, many libraries provide platform-independent abstractions over platform-specific libraries, but that is not related to the language. For example, macOS uses AppKit and Quartz, while Windows uses WinAPI, *regardless* of what language you are calling them from. If you are trying to do graphics on Windows and macOS without a cross-platform library, you will end up writing conditional code anyway, in every language, not just in C.
Preprocessor-based configuration, in my experience, is also limited to "if Windows… else…". Yeah, Windows is a deviant and stupid environment, hostile to developers. But it's only one platform out of the who knows how many that C runs on.
"In C data types can have way different sizes because they are just not defined in the standard." - I'm perfectly aware of that, yes. However, the designers of C were careful enough to include information about these facts in the standard library, as this design decision was deliberate, not accidental. It's a shame people don't use limits.h, float.h, and stddef.h. Those headers (among others) allow one to write truly portable code without making unsound assumptions about the underlying hardware.
"And finally YOU might be able to write code that runs on all platforms, but the industry is not." - which is sad, but again, don't blame it on the language. Blame it on the careless/inexperienced/lazy/stupid/etc. programmers who write shitty code. You can write non-portable code in any language. You can write non-portable code in Go, or in Java, or in Haskell, or in Rust, you name it. E.g. if your coding style is replacing shell scripts with ${LANG} by just calling out to the shell and invoking system tools, then boom, your code just became non-portable. And this is only a trivial example. There are many more aspects to portability (filename separators, case sensitivity throughout the OS, whatever) that won't (because they can't) be covered by, or related to, the language. This doesn't "make the language non-portable".
It's not wrong. "Portable C" isn't a special kind of C marked as such in the source code in some fashion. It's not trivial to determine if a given program written in C is portable or not. In Go, it's *relatively* trivial: if the code imports Syscall or Cgo (or imports something which uses them), it's not portable; otherwise it should be portable.
'Chess' a western game??