dotGo 2015 - Rob Pike - Simplicity is Complicated
dotconferences7 HN recommenders · recommended in 7 months, 2016-2023
172K views · 10 years ago · talk · evergreen
Rob Pike's dotGo 2015 talk argues that Go only seems simple, and that its simplicity hides real complexity that is part of the design. He explains the thinking behind Go's restraint in features.
HN returns to it to explain why Go deliberately resists syntactic sugar and new features.
0:27Rob Pike about the target group of the Go programming language (golang)
f8C4G86p KbqEFe47
7K views • 6 years ago
12:31OSCON 2010: Rob Pike, "Public Static Void"
O'Reilly
119K views • 16 years ago
56:36GopherCon 2014 Opening Keynote by Rob Pike
Confreaks
38K views • 12 years ago
22:29Gopherfest 2015 | Go Proverbs with Rob Pike
The Go Programming Language
317K views • 10 years ago
1:07:00Sydney Golang Meetup - Rob Pike - Go 2 Draft Specifications
Macquarie Group
57K views • 7 years ago
59:26The Go Programming Language
Google TechTalks
406K views • 17 years ago
23:57GopherCon 2016: The Design of the Go Assembler - Rob Pike
Gopher Academy
116K views • 10 years ago
51:27Google I/O 2012 - Go Concurrency Patterns
Google for Developers
894K views • 14 years ago
51:18Lexical Scanning in Go - Rob Pike
GoogleFOSSSydney
162K views • 15 years ago
1:00:29Google I/O 2012 - Meet the Go Team
Google for Developers
108K views • 14 years ago
48:19GopherCon 2014 Inside the Gophers Studio with Blake Mizerany
Confreaks
8K views • 12 years ago
1:05:56Lang NEXT 2014 Panel Systems Programming in 2014 and Beyond
25msr
3K views • 8 years ago
38:19Origins of Go Concurrency style by Rob Pike
jasonofthel33t
28K views • 14 years ago
51:12Google I/O 2011: Writing Web Apps in Go
Google for Developers
135K views • 15 years ago
1:01:39"Simple Made Easy" - Rich Hickey (2011)
Strange Loop Conference
219K views • 5 years ago
1:29:49Going Native 2012 Keynote Stroustrup
savage309
33K views • 14 years ago
31:23Concurrency is not Parallelism by Rob Pike
gnbitcom
191K views • 11 years ago
1:01:39"Simple Made Easy" - Rich Hickey (2011)
ClojureTV
434K views • 5 years ago
36:53Rails Conf 2012 Keynote: Simplicity Matters by Rich Hickey
Confreaks
220K views • 14 years ago
1:00:40Dmitry Vyukov — Go scheduler: Implementing language with lightweight concurrency
Hydra
47K views • 7 years ago
14 comments from Hacker News
Rob Pike was right: "features were being added by taking them from one language and adding it to another" "...and I realised all of these languages are turning into the same language." "we don't want one tool, we want a set of tools, each best at one task" ▶ this video
It's not a mystery, Pike talks about it constantly. The mistake was designing around "simplicity" - a nebulous, unattainable goal. It's sort of like designing around "happiness" - who is to say what happiness is? Is happiness satisfaction? Ecstasy? Fulfillment? Does it require some sadness? How nebulous it is is really well demonstrated in Pike's talk[0] where he somehow believes that a for loop is "simpler" than methods like "filter" and "map", and makes the very strange and incorrect claim that it's going to be faster as well. A lot of Go's design philosophy is, very bluntly, directed to bad programmers . For example, Pike talks about how a developer using a language with many features might spend 30 minutes just iterating on a few lines of code, because there are so many features available to use within that code. That is a very junior level problem - junior level programmers aren't very good at understanding that there's low return on investment for that sort of work so they coo over fancy code that works exactly as well as boring code. Similarly, junior developers have a hard time learning features, so they have a hard time reading code that uses them and Go puts readability above all else. A senior developer should surely hear "filter and map are complicated?" and scoff but a junior developer would go "I have no idea what those are". And there are significant constraints because of that lack of features - years of not having generics because it's too complex, for exampl
▶ this video “Go is software for the parts that we work on which is mostly infrastructure.” Generics is a good thing and I look forward to seeing the details in how Go will support it.
the key is simplicity, you're complaining about language features that allow you to write "fun" code, but remember that we spend around 80% of the time reading or debugging code, the main focus of Go is about writing code that's easy to read which will allow you to scale a project or source code with more people, also remember that easy doesn't mean simple, I think these 2 talks will make you understand my idea a little bit better: ▶ this video link
> Ignoring 20-30 years of programming languge theory advancements. Yet everyone laps it up. I’d argue Go didn’t ignore those things, it just made a different set of trade-offs than most people are used to or expect from a modern programming language. The rationale for this is is well explained in ▶ this video .
> Go just hides the complexity from initial inspection. If you (parent, other readers) haven't seen it, Rob Pike's "Simplicity is complicated" is a good discussion of just this point. video: ▶ this video slides: link
Recently the Go team decided not to add the try-keyword to the language. I'm not a Go programmer and was a bit stumped by the decision until I saw a talk of Rob Pike regarding the fundamental principle of Go to stick to simplicity first. [1] One of the takeaways is, that most languages and their features converge to a point, where each language contains all the features of the other languages. C++, Java and C# are primary examples. At the same time complexity increases. Go is different, because of the simplicity first rule. It easens the burden on the programmer and on the maintainer. I think python would definitely profit from such a mindset. [1] ▶ this video
> Unfortunately, the community that has sprung up around Go is more or less opposed to new language features on principle. I think this comes straight from the original go team. Rob Pike had a talk[1] that is partly about why go doesn't keep adding features and why it doesn't have certain features that other languages have. I think people who like go have bought into the idea that the go team has made good trade-offs to make go code easier to read and maintain at the expense of expressibility. [1]: ▶ this video
The creators of Go are Rob Pike and Google. I think they would know if a different GC were better and use it. I used to sometimes doubt Rob Pike too and think Go had made some mistakes. After using Go and listening to his talks (like [0]) I realized how wrong I was. There's a reason he has helped build two wildly successful programming languages.. How many have you built? Are you smarter than Google? In the end, embracing Rob Pike's brilliant decisions and taste has made my programming life so much simpler and better. I switched to Acme [1], turned off syntax highlighting on Gitub PR reviews with a userscript[2], and my life is infinitely simpler. Rob Pike has been right on so many things and has made Go successful. I'm sure if a generational GC were better for Go, he would have built and used it, so you're obviously wrong. [0]: ▶ this video [1]: link [2]: link
To me it feels like apples to oranges comparison. I watched this talk on strangeloop a long time ago, and a version of this talk given on RailsConf recently (watched recently, not given). Here's what I see on the page: > Complex constructs: State, Object, Methods, Syntax, Inheritance, Switch/matching, Vars, Imperative loops, Actors, ORM, Conditionals. > Simple constructs: Values, Functions, Namespaces, Data, Polymorphism, Managed refs, Set functions, Queues, Declarative data manipulation, Rules, Consistency. And to dig deeper, it makes sense to search for "why state is bad", "why inheritance is harmful", "avoid conditionals", etc., and read whatever you find interesting. Go has particularly simple syntax. Here's a talk by Rob Pike about simplicity, syntax, and language feature you might find interesting ▶ this video
> It feels like the sort of line that sounds pithy as long as you don't worry about accuracy. Exactly! And unrelated: I always think of Rob Pike when I hear the word pithy [0] :D [0] ▶ this video
I've been thinking a lot lately about why Go, a quite minimalist language by modern standards, has been so incredibly successful in such a short time. It's about a decade old, and is already among the top 5 languages for people starting new OSS projects (at least in my area, which is systems management). Green field development is being done in Go at a rate unprecedented for such a new language, I think. Node/JS might be precedent if we say that Node is a whole new thing, even though it uses JS as its syntax, using it as a server language is pretty new (ignoring Netscape's failed attempts at it in the 90s). I'm tempted to compare it to PHP, which exploded in popularity despite (unarguably, IMHO) better languages existing all around it at the time. Go doesn't seem like a bad language in the way that PHP was a bad language for its first 4~5 major versions, but it does find itself surrounded by many more powerful/expressive languages, and is seemingly getting much faster adoption. I've been learning Go myself, and while I miss some of the features of my normal primary languages (Perl, lately, but also Ruby and Python), I like that I can read other people's Go code without having to look anything up, even though Go is very new to me and I have years experience reading/writing Perl/Ruby/Python. Of course, Perl/Python/Ruby aren't a major paradigm shift away from Go as Haskell is...but, it's still a question of whether it's better to write ten simplistic LOC or two maybe opaque LOC.
It's an active choice of the language to not allow many syntactic sugars that make the code have a much higher learning curve. ▶ this video is a good overview.
I hadn't been particularly enthusiastic about Go but in the end Rob Pike won me over - "Simplicity is Complicated": ▶ this video A powerful talk on Silicon Valley history by Kelsey Gilmore-Innis - "What Tech Workers Can Learn From Harry Bridges": link