The company I work for, had one of its most important components for its server architecture written in Go. It went virtually untouched for 4 years when the individual who wrote it quit. I picked up the mantle with no prior experience in Go.. upgrading to the most recent version of Go had 0 breaking changes or gotchas. Now i understand why, from watching this video on the philosophy of Go.
This is a cool talk. Of the many things it does, it clearly demonstrates that what some people call "simple" and what others call "simple" are very different. He keeps saying this code is simple, but I find the syntax of Python FAR simpler. Like, Python just says what the thing is -- which is why I think it makes so much sense to so many people who don't identify as programmers or don't wish to be systems programmers. There's this translation step, (a degree of separation), that virtually all programming languages use -- Go included -- that's a big part of why I've never been able to fall in love with other languages besides Python. Take print, for example. Print in Python is simply: print("whatever you want"). That's it. The action and name of the action are one and the same. Print in Go is three different functions: fmt.Print(), fmt.Println() and fmt.Printf(). This from a language that supposed to be *simpler*? Before you can print anything you have to pick which print function you want and decide how it will be formatted. To my brain, this is FAR more complicated that just...print() -- and that's it. And every time you see that print function in Go (whichever one you decide to choose), you say to yourself, "Oh, this prints something here...", but you *see* is fmt.Println() (or whichever one you chose). This is the translation step I was talking about. You see one thing and then have to interpret/translate that thing into what it *means*. Python is the only language I've found that this "translation step" is virtually nonexistent: It just tells you what the thing is (and I love it!). print("apple") means "print apple". (On a side note, I particularly hate the "system.out.println()" of Java. Sheesh. Just...wow, that's awful.) Of course, this readability and "lack of a translation step" continues to all aspects of the language in Python, not just the print function (lol). It's part of what makes it so astoundingly clear (and fun!) to both read and write. Anyway, just my take. Different strokes for different folks. I'm looking into learning Go, saw this and then all of the following came to mind. Just sharing. Much love and cheers! :)
You are confusing the language with the standard library. It doesn't matter if there are 10 print functions in the standard library. In fact, the more functions you have to do things a desired way, the simpler the developer experience is. Also, this print argument is incredibly weak anyway. print is never hard for a beginner in any decent modern language. It's literally the first thing anyone learns. Try comparing multithreading or writing performant code. Need performant code in your Python application? Okay, better write it in C then.
With python the translation step is a bit later in the process. When your application becomes hellishly slow, and/or you try to introduce concurrency then you get such issues. Compare python's multiple inheritance of classes to golang's structs and interfaces. class Dog(Pet, Animal): def __init__(self, name): super(Pet).__init__(name) .... vs type Pet struct{ Pet Animal } Python is the king of 'looking simple', but being incredibly difficult to get right. Writing a webserver in python is very little effort, but getting it production ready (= multithreaded in 2024) is a hellscape. Go has channels which work well, python hides it all in libraries, etc. It has the global interpreter lock, another weird concept which you have to get your head around. With python, the magic is there, until it's gone, and then you're suddenly in a hellscape. Go gives you a simple world full of simple concepts. It's harder to get into the world, because there's much less magic going on. However, in exchange it doesn't rugpull and put you in a situation where your production application is bizarrely slow and you have no idea why. Also, I hate runtime errors, and any language that doesn't defend me against them to the best of it's ability is just shit.
JavaScript is ripe with the rewriting problem. Hundreds of libraries I wrote a year or so ago are completely useless now really, no one would write them the same way now haha. Such a huge pain in the ass.
+Tj Holowaychuk "Hundreds of libraries I wrote a year or so ago are completely useless now" - don't be so hard on yourself, I think that maybe someone is using one or two of them ;)
javascript has been re-solving all the "solved problems" since the 1970's, and still getting them wrong. it's an embarrassment of language design. if that's the bar to compare to then go-lang, I guess, is a success. But that's a remarkably low bar.
Benjamin Scherrey i think it fundamentally has to do with the web dev culture. They’re very prone to pragmatic solutions that are very shortsighted and don’t really have a deep computer science pedigree. It’s not an accident that both PHP and JS are smashing successes in the web world and are (or for many years were) incredibly poorly designed. Most web devs are more interested in the next killer app than stack vs heap.
I think it's funny that Pike's famously complained about Niklaus Wirth's strict separation of behavior and data, and then he ended up creating a language where you have interfaces that can only contain methods and structs that can only contain data. I think it ends up being a beautiful synthesis of both the ideas, especially the wonderful idea of implicitly satisfied interfaces.
Just came from a video of normie him in 2010, kind of curious how this wardrobe timeline developed-incedentally I'm noticing a correlation with the basic gopher drawing on that shirt too lol th-cam.com/video/5kj5ApnhPAE/w-d-xo.html
Many come to Go worn out by the complexity of other popular languages and then after a moment having forgotten why they left the previous languages behind they start asking why Go can't be more like the languages that wore them out. Go isn't the only language nowadays for which any proposed changes must go through a rigorous process of peer review but it having started it earlier in its history than most there's less of poorly thought through features added that don't fit in with the rest. The slow rate of progress might feel frustrating to many but if that's a problem they can always turn to Rust or a minimalist subset of C++.
I’m learning Go and quite happy so far. But around 5:00 I wish I heard a descriptive explanation of what criteria were used to choose what features to add and which ones to remove rather than it was just via unanimous decisions.
Love this talk! An ideal language is something that has simple primitives to get started with clear and comprehensive standard libraries. Lots of other languages failed to do so as they expose too many “features” to users of the language (hard for these languages because of legacy or some other reasons). The balance between capability (expressiveness as mentioned) and simplicity is hard to find but at the end of the day language creation is not for the language but for the people using it.
only one loop for which can be customised is only a genius can think of. Being productive in 1-2 weeks for the newbies. deployment is very simple. no unused variables these kind of things makes Go a unique language.
If PHP hadn't included loads of features from other languages, I don't think there'd be any PHP left.... which, speaking as a PHP developer, wouldn't be that bad a thing. ;)
The success of JavaScript and the Node stack is due to the very good npm package manager. If go modules are going to make dependency versioning as easy as npm modules do, Go is going to overcome Node definitively.
The success of JavaScript is due to it being forced since it's what the browser understands, and some people find it handy to use the same language server side, not the package manager and the repos filled with left-pad and isodd anyway
I am very annoyed that I cannot see the slides. You should have added these to the video, like in a corner... Especially when he talks about code, why should I see him talking instead of seeing the code?!
Well 7 years later, Go now added support for generics and planning to add standard error handling, which "sort of" inspired from other languages. The very thing Rob frowned upon here talking about other languages maturing. Go is great but I guess too much emphasis on "simplicity" is also making it limited. While it has great Concurrency model and simple coding style it's limiting with features such as "implicit interfaces", lack of strict immutability, somewhat confusing pointers usage etc;. This limits dev flexibility while forcing engineers to find alternate ways of writing code. I like Go. I love C#. One's not better over the other. If anything, C# 10 & 11 versions show how the language has matured to be "simpler" to use.
Generics is a bad fit for go, don’t think everyone is overjoyed that they are adding this implementation to the language, far far from it. Rob Pike had a great vision that brought the language to great heights, now let’s watch the downfall as they are forcing in every feature of every language into it. It’s going to be brutal.
Go is not planning to add new ways to handle errors. All the discussion around that is centered around Go2, which we are nowhere near. Also strict immutability, etc. really don’t actually add anything to the language, nor are the pointer semantics confusing in the slightest
What about features like promises or async/await in JS? These new features are designed precisely to improve reasoning in programming and therefore readability. This isn't the same as just tagging on new features adhoc because other languages have them. They achieve some of the goals attributed to Go here.
Go uses channels to let coroutuines communicate with each other. And because Go doesn't support generics, there is no easy way to implement Promises / Futures.
6:18: "Features hurt readability" Based on my experience, I disagree. E.g. the with-statement in Python - which was added in 2005 - more than 10 years after the inception of the language - greatly improves readability. It tells not only the interpreter, but also the human reader, "I have a resource here that will be released after use", and the life-time of that resource is the indented block beneath "with". I can make a similar case for templates in C++. By contrast, Golang's notorious if err != nil { return err } clutters source files, the way exceptions don't. Sure, exceptions have their own issues, but with-statements, finally clauses and C++'s RAII idiom nicely pair with exceptions getting rid of repetitive checking for error codes. No, I'm not arguing that Python or C++ were better than Go, or that there were no useless features in many languages that make code unnecessarily complicated, but I am firmly of the opinion that the statement "features hurt readability" is not generally applicable.
I agree. Some features(abstractions) can improve readability. I also agree with Rob's point about feature orthogonality, though. You can solve a problem by adding a new feature to address that specific problem, or by choosing your initial set of features such that they can be combined to solve any problem. The with statement is something I love in Python, but consider how a language like Haskell does it: wiki.haskell.org/Bracket_pattern. Basically, functions are all that you need. The only thing the with statement actually added that was missing, is the block syntax to delimit the code block that runs between the enter and exit. In Haskell, that role is given to lambdas: with (open "/tmp/test") close \file -> putStrLn (read file) So instead of adding a new feature to solve the specific problem of "context managers", you use existing features, like multiline anonymous functions, which is already used to implement other features. For example, here's how one might "implement" a "for each" loop like Python's without needing special syntax: forM (range 10) \i -> print i In both those examples, the're are about 4 fundamental features in there: * named functions * anonymous multiline functions * datatypes(e.g. whatever the range function returns is a concrete data type, like a list) * typeclasses(i.e. interface/protocol, here for the iteration and the side effect) I'm not saying Haskell is a simpler language, or that functional programming is a better solution. But by choosing the feature set wisely, you can avoid having to add new features to address specific problems and instead rely on existing features to address multiple problems.
@@user-ov5nd1fb7s Would you say the same about other popular languages? C++? Java? Sure, people appreciate the simplicity of Go, and it works well for some use cases. But it's popularity doesn't prove anything other than that. Eventually, missing features that make programmer's life simpler, and that programmers are used to having in other languages, might end up limiting it's usefulness and popularity.
@@schok51 I can show you companies that died because unmaintainable codebases. That doesn't happen with Go. Of course, nothing is perfect. But the community is working hard to improve Go and crucial features will be added.
@@user-ov5nd1fb7s well Go is still young and doesn't have legacy projects to be migrated to. Plus not having "complex" features doesn't make refactoring easy. It just makes it simple. Simple ain't easy.
"If you make everything too expansive and explain everything in detail, you get a very verbose language. I won't name any but you know the ones Im thinking of." Bet it's Java.
Java feels verbose because it has relatively few features, like Go. People praises C# and Kotlin because they are concise, not because they are simple.
@@林陵依 Pretty sure it's both. You affirm this by saying "Java is a verbose language [to write]". As a tangent, this can be a severe drawback for a tool as it raises development cost tremendously. Both for completing a development cycle of a feature and maintenance. This kills big products even in large corporations.
Ive written Java a long time and its becoming less verbose and more expressive as of Java 8. Go looks a promising language but I never hear the warts associated with the language.
The Vivaldi web browser allows users to tile selected tabs (vertical split screen). That is not orthogonal, because the ability to see two things in a split screen mode was always handled by a window manager of your desktop environment. There are two users. User A wants a feature X and user B wants a feature Y. You are a maintainer of that project and you decide to not implement these features directly. Instead, you allow users to implement these things themselves (through plugins usually). You only define an interface for the plugin and that's it. That is orthogonal. There are two ways to download a file in Linux terminal. The tool A (wget) retrieves the server response and saves it into a file. The tool B (curl) retrieves the server response and echoes it to the terminal (STDOUT). The Linux terminal typically allows redirecting the command output to a file and that makes using tool A (wget) not orthogonal. The tool A (wget) doesn't have to implement saving to a file when the terminal can do that for any command output.
hmmm, but does a simpler featureless programming language really make code more readable? In some ways I guess, but I feel like the quality of the person programming is always the main factor. Good programmers think about people reading your code. I'm not sure fixing Go in stone for all times, like you got it right the first time, will ever fix this "human" problem.
Go may not make the problem of rouge developers worse -- only I'm disinclined to believe (gut feeling) it makes it measurably better. Does limiting syntax, limiting tools or limited coding style make a bad programmer even fractionally better a developer or team-player? That person in my experience often writes in a language called "spagetty" - and Go has no anti-spagetty AI built into it yet. I just suspect that the flexibility to wreak havoc offered by any "general purpose" language is going to be overbearing - and small systematic restrictions within the language tenuous. Off course, that being said, Go has features that do really help us a lot.
Hello from the future, How i see it is that in a lot of settings where go would be used, the barrier to maintainability is the complexity of the language grows with time. The amount of knowledge required to understand what is going on increases. The whole point is that if you constrain knowledge requirements to understand previous code (not just the language, but the complexity of the ecosystem that you can assume will be used) you make more maintainable code. Think how in java you have to relearn how to solve the same problem depending on what java version it was written in. or how python2 to python3 was.
Great talk. Though I must say that Go contradicts itself on some points. Like being concise and short but I have to write a for-loop for everything collection related! It doesnt have to be a functional language but please give me filter and a map function on slices. Sure, everyone coming from school knows a for-loop, but when reading the code I always have to understand the whole loop just to know what it is doing (or extract every looping into its own function which also clutters the code)...in most cases it is some kind of "filter that element" and "do something with that element". Maybe a loop is faster, but usually it doesnt matter and in case I need it to be a couple of cycles faster I can fall back to the loop. Also all this c-style abbrevations...iota anyone. Last but not least the server example given at the end. This has nothing to do with the language. It is just an API. I could write a one line server call in any higher language. So I am going to learn more about Go, especially as a replacement for Bash, but I think I will not love it
Pardon my ignorance, as I'm also new to golang. But what language does Rob keep referring to, especially when he was talking about features that aren't orthogonal? Thanks!
I strongly dislike the phrase 'simplicity hiding complexity'. What is hiding the complexity is abstraction *NOT* simplicity. The best explanation of this I'm aware of is Rich Hicky's talk 'Simple made easy and I'm not going to try to duplicate that here. Common language conflates the terms ''simple' and 'easy' and this usage is not simple. Abstraction creates an illusion of simplicity but often fails in subtle ways, the law of leaky abstractions.
The Hickey video is very interesting and thank you for the reference, but I don't think the law of leaky abstractions applies here. Just because something can (and will) break destroying your beautiful abstraction, does not mean that your abstractions cannot provide simplicity to your users. From Hickey, simple means "unentangled", not interleaved and not braided.I totally agree. I would temporally coupled to that list. I would throw pike's usage of orthogonal right into Hickey's talk about simplicity. I think there's a lot of agreement here, although Hickey has obviously thought quite a lot about this topic.
Abstraction hides the implementation details, not complexity. Bad abstraction can easily create complex interface. Good abstraction is one of the ways to achieve simplicity, but not he only way. One of the other way is conscious feature omission, the philosophy of not having things, or having just enough things. One example is the 1 or no button of the iphone design, that deliberate omission of buttons is a deliberate choice, that achieved simplicity, but doing it right, is complicated, and there is a huge load of complexity hidden behind that one seemingly simple button.
so many people hate the lack of generics... but I love every points here, generics is good, but not big deal for objective C developers, not big deal for javascript developers.
Golang does not have user defined generics. I believe the reason why they did that is to keep the language simple and fast for now, in order to attract more programmers. Eventually they will be added.
Funny, now I learnt rust, feel generics is not the worst problem of golang, the interface escape is the biggest problem, more interface you use, more it will be like java minus the rich type system java offers, if using interface causes objects to escape to heap, it is not necessarily fast. Another thought on generics, it is ok to write verbose code, but it is painful to provide a library without tons of empty interface, empty interface is really bad to use and really bad to perform.
I really don't think most of these points are valid. A real type system - that is, one with sum types and generics - is not just "more fun to play with". It allows you to verify the runtime behaviour of a program at compile time. In other words, if your program compiles, it is very unlikely to break at runtime. Furthermore, Rust has demonstrated that it is very much possible to have a lot of very high-level abstractions with no cost at runtime.
But I think that Leo argues about the benefits of generics. The point is that generics do offer something more than just "fun to play with". Rob oversimplifies in his talk what some features have to offer. Prioritizing simplicity is one thing (and quite valid) but putting generics in the "fun to play with" bucket is another.
I think the talk explains exactly why generics is not included in the language, it is a conscious decision, to keep the language simple. I agree generics is a powerful tool, but if you followed any of the several serious discussion of adding generics to go you will realize how much complication each way of implementation would bring to the language usage. If you think the go team dismiss any language feature just because they think they are only "more fun to play with", you are very wrong. And if you feel go is not providing the features you need, there is always rust/java/python/js/erlang... no one is forcing you to use it.
Comparing Go to Rust doesn't really make sense since their problem domains are different. More to the point, while Rust has high-level abstractions that come at very little runtime cost, they come at an extremely high "write time" cost. The average programmer can learn Go in about a week, because the abstractions it uses are simple. You will not be learning Rust in a week.
1. In his slide he says : "Go is a clean procedural language designed for scalable cloud software." I'am reading "the go programming language" book and in the preface section, it says "it is truly a general-purpose language and finds use in domains as diverse as graphics, mobile applic ations, and machine learning". How a system programming language can be use to developpe applications ? 2. Go is expressive. If we compare it to the functionnal languages, it is not expressive at all. Haskall, scala, ocaml are more expressive then Go. Why he says it is expressive ?
In C and C++ there are many ways to skin a cat... in Go there are no cats only Gophers but the same ideas can be expressed. It comes down to efficacy, as languages become more complex they may seem initially more expressive as their vast amount of concepts overlap more with concepts we already understand, however the complexity makes them less effective.... a simple language that can still express the needed concepts will inherently be more effective. What use is expressiveness without efficacy?
I don't really share his thoughts. "Languages are getting more and more complex because they are adding modules and libraries to deal with multiple fields", so what? if you are in the field of machine learning and are not interested in the field of network traffic automation, just focus on the libraries relevant to your job and leave the other ones alone. You see? complex became suddenly simple.
he's talking about the complexity of a given language, not the libraries involved. C++ is a very complicated language, given how templates work for example. Go is a MUCH simpler language.
Sounds great on paper but I hate to say Golang is actually VERY hard to read(10x harder than python, 5x harder than c/c++/javascript/etc) and is not really that expressive.
"If a language has too many features, or even more than you might need, you spend time programming thinking about which features to use. If there's really a lot of features, you may look at a line of code, write it one way, 'Ooh I could use something different, I could use this feature, I could use that feature...'. You might even spend half an hour playing with a few lines of code to find all the right ways you could use different features to make the code work a certain way. And it's kind of a waste of time to do that. But worse, when you come back to the program later, you have to recreate that thought process. You not only have to understand this complicated programming language doing whatever it's doing, you have to understand why the programmer, who might be you, decided that this was the way to approach the problem from the feature set available. And that is just, I think, bad engineering. The summarization of this is 'The code is harder to understand simply because it is using a more complex language.' You want to have just one way, or at least fewer, simpler, easy to understand ways."
"Go helps improve diversity by not trying to be like other languages." "In Go we intentionally limit programmers to only ever do things one way, with a few tools, so that things are not diverse." Hmm....
What you're referring here are two separate things. What he is trying to say is that it is good to have different languages e.g. English, French, Chinese(diversity is useful) but it is not good when two people speaking Franch, for instance, have a problem understanding each other. It's creating a completely different kind of language barrier when everyone using the same language needs to know every variation of it in order to communicate properly(diversity isn't useful).
Haskell is unique, it does add features that are inline with Haskell's design, Python is simple and occasionally add features to continue to evolve. Golang is "unique" and "simple" compared to C#, javascript and swift, what a low bar.
wow lissing on the 4:46 ,my question is Ken the God ,can i be your friend ,anaticha raposa and fox pad ,love google,blees all us .build the future with love.Muito obrigada.Forca
16:04 says "three strokes", shows two fingers. Same as the "simplicity" in Go. I can understand he wanted it to be simple and readabe, but made it pretty much the opposite. For loop instead of map/filter and at the same time talking about the readability of Go?! Come on 🙂 Two words that explain his thinking and Go itself: wanna be.
Well, as someone who actually works in go, I have to say that you're wrong. I love working in Go, and find it the most readable language I've ever used, which includes assembly, basic, python, C, C++, C#, Forth and others I've forgotten by now. What language do you think is more readable than Go?
+Siddhesh Rane Yeah rust verbosity is better ! Like a fucking loop keyword and this shit like // impl What is this shit to write { x: &'a i32, } impl { fn x(&self) -> &'a i32 { self.x } } fn main() { let y = &5; // this is the same as `let _y = 5; let y = &_y;` let f = Foo { x: y }; println!("x is: {}", f.x()); }
The company I work for, had one of its most important components for its server architecture written in Go. It went virtually untouched for 4 years when the individual who wrote it quit. I picked up the mantle with no prior experience in Go.. upgrading to the most recent version of Go had 0 breaking changes or gotchas. Now i understand why, from watching this video on the philosophy of Go.
Not sure how many times I've watched it now but great talk as always
This is a cool talk. Of the many things it does, it clearly demonstrates that what some people call "simple" and what others call "simple" are very different. He keeps saying this code is simple, but I find the syntax of Python FAR simpler. Like, Python just says what the thing is -- which is why I think it makes so much sense to so many people who don't identify as programmers or don't wish to be systems programmers.
There's this translation step, (a degree of separation), that virtually all programming languages use -- Go included -- that's a big part of why I've never been able to fall in love with other languages besides Python. Take print, for example. Print in Python is simply: print("whatever you want"). That's it. The action and name of the action are one and the same. Print in Go is three different functions: fmt.Print(), fmt.Println() and fmt.Printf(). This from a language that supposed to be *simpler*? Before you can print anything you have to pick which print function you want and decide how it will be formatted. To my brain, this is FAR more complicated that just...print() -- and that's it.
And every time you see that print function in Go (whichever one you decide to choose), you say to yourself, "Oh, this prints something here...", but you *see* is fmt.Println() (or whichever one you chose). This is the translation step I was talking about. You see one thing and then have to interpret/translate that thing into what it *means*. Python is the only language I've found that this "translation step" is virtually nonexistent: It just tells you what the thing is (and I love it!). print("apple") means "print apple". (On a side note, I particularly hate the "system.out.println()" of Java. Sheesh. Just...wow, that's awful.)
Of course, this readability and "lack of a translation step" continues to all aspects of the language in Python, not just the print function (lol). It's part of what makes it so astoundingly clear (and fun!) to both read and write.
Anyway, just my take. Different strokes for different folks. I'm looking into learning Go, saw this and then all of the following came to mind. Just sharing. Much love and cheers! :)
You are confusing the language with the standard library. It doesn't matter if there are 10 print functions in the standard library. In fact, the more functions you have to do things a desired way, the simpler the developer experience is.
Also, this print argument is incredibly weak anyway. print is never hard for a beginner in any decent modern language. It's literally the first thing anyone learns. Try comparing multithreading or writing performant code. Need performant code in your Python application? Okay, better write it in C then.
With python the translation step is a bit later in the process. When your application becomes hellishly slow, and/or you try to introduce concurrency then you get such issues.
Compare python's multiple inheritance of classes to golang's structs and interfaces.
class Dog(Pet, Animal):
def __init__(self, name):
super(Pet).__init__(name)
....
vs
type Pet struct{
Pet
Animal
}
Python is the king of 'looking simple', but being incredibly difficult to get right. Writing a webserver in python is very little effort, but getting it production ready (= multithreaded in 2024) is a hellscape. Go has channels which work well, python hides it all in libraries, etc.
It has the global interpreter lock, another weird concept which you have to get your head around. With python, the magic is there, until it's gone, and then you're suddenly in a hellscape. Go gives you a simple world full of simple concepts. It's harder to get into the world, because there's much less magic going on. However, in exchange it doesn't rugpull and put you in a situation where your production application is bizarrely slow and you have no idea why.
Also, I hate runtime errors, and any language that doesn't defend me against them to the best of it's ability is just shit.
Python is in a different league. Yes, it is slow, but it is much more enjoyable to write in.
JavaScript is ripe with the rewriting problem. Hundreds of libraries I wrote a year or so ago are completely useless now really, no one would write them the same way now haha. Such a huge pain in the ass.
+Tj Holowaychuk "Hundreds of libraries I wrote a year or so ago are completely useless now" - don't be so hard on yourself, I think that maybe someone is using one or two of them ;)
express is being used in production daily on our end and project itself is going strong since you left. I won't call that hard work useless TJ
javascript has been re-solving all the "solved problems" since the 1970's, and still getting them wrong. it's an embarrassment of language design. if that's the bar to compare to then go-lang, I guess, is a success. But that's a remarkably low bar.
Benjamin Scherrey i think it fundamentally has to do with the web dev culture. They’re very prone to pragmatic solutions that are very shortsighted and don’t really have a deep computer science pedigree. It’s not an accident that both PHP and JS are smashing successes in the web world and are (or for many years were) incredibly poorly designed.
Most web devs are more interested in the next killer app than stack vs heap.
@@gareginasatryan6761 there isn't much pragmatic about web development.
I think it's funny that Pike's famously complained about Niklaus Wirth's strict separation of behavior and data, and then he ended up creating a language where you have interfaces that can only contain methods and structs that can only contain data. I think it ends up being a beautiful synthesis of both the ideas, especially the wonderful idea of implicitly satisfied interfaces.
...but the data (structs) can include function (type) members/fields, which you can assign to and therefore have a way to specify/override behaviour
Opening song is Elephantitis by Profesor Kliq
Please keep Go simple
Please make Go simpler, by making it more expressive. It only took then 10 years to understand Generics and non-verbose error handling are required...
with the continuous rise of python I think there’s no ending to it. golang for me perfectly fits in where python is lacking things
I WANT THIS JACKET. It will make me a better GO programmer, I hope.
The jacket is concurrent.
Just implement the interface and you're good
Just came from a video of normie him in 2010, kind of curious how this wardrobe timeline developed-incedentally I'm noticing a correlation with the basic gopher drawing on that shirt too lol
th-cam.com/video/5kj5ApnhPAE/w-d-xo.html
I love these Rob Pike Go conferences
Simplicity is the art of hiding complexity.
Watching in nearly the end of 2019, I'm lucky to use Go in our generation.
lol
Many come to Go worn out by the complexity of other popular languages and then after a moment having forgotten why they left the previous languages behind they start asking why Go can't be more like the languages that wore them out. Go isn't the only language nowadays for which any proposed changes must go through a rigorous process of peer review but it having started it earlier in its history than most there's less of poorly thought through features added that don't fit in with the rest. The slow rate of progress might feel frustrating to many but if that's a problem they can always turn to Rust or a minimalist subset of C++.
very true
- " Its hard to be Simple"
fantastic Rob... thanks alot of sharing thigns like that. im feed up with those non necessary increasing features list
I’m learning Go and quite happy so far.
But around 5:00 I wish I heard a descriptive explanation of what criteria were used to choose what features to add and which ones to remove rather than it was just via unanimous decisions.
Love this talk! An ideal language is something that has simple primitives to get started with clear and comprehensive standard libraries. Lots of other languages failed to do so as they expose too many “features” to users of the language (hard for these languages because of legacy or some other reasons). The balance between capability (expressiveness as mentioned) and simplicity is hard to find but at the end of the day language creation is not for the language but for the people using it.
The linear algebra analogy blew my mind
Yeah, very clever analogy.
only one loop for which can be customised is only a genius can think of. Being productive in 1-2 weeks for the newbies. deployment is very simple. no unused variables these kind of things makes Go a unique language.
If PHP hadn't included loads of features from other languages, I don't think there'd be any PHP left.... which, speaking as a PHP developer, wouldn't be that bad a thing. ;)
The success of JavaScript and the Node stack is due to the very good npm package manager. If go modules are going to make dependency versioning as easy as npm modules do, Go is going to overcome Node definitively.
The success of JavaScript is due to it being forced since it's what the browser understands, and some people find it handy to use the same language server side, not the package manager and the repos filled with left-pad and isodd anyway
I am very annoyed that I cannot see the slides. You should have added these to the video, like in a corner... Especially when he talks about code, why should I see him talking instead of seeing the code?!
Well 7 years later, Go now added support for generics and planning to add standard error handling, which "sort of" inspired from other languages. The very thing Rob frowned upon here talking about other languages maturing.
Go is great but I guess too much emphasis on "simplicity" is also making it limited. While it has great Concurrency model and simple coding style it's limiting with features such as "implicit interfaces", lack of strict immutability, somewhat confusing pointers usage etc;. This limits dev flexibility while forcing engineers to find alternate ways of writing code.
I like Go. I love C#. One's not better over the other.
If anything, C# 10 & 11 versions show how the language has matured to be "simpler" to use.
Generics is a bad fit for go, don’t think everyone is overjoyed that they are adding this implementation to the language, far far from it. Rob Pike had a great vision that brought the language to great heights, now let’s watch the downfall as they are forcing in every feature of every language into it. It’s going to be brutal.
Go is not planning to add new ways to handle errors. All the discussion around that is centered around Go2, which we are nowhere near.
Also strict immutability, etc. really don’t actually add anything to the language, nor are the pointer semantics confusing in the slightest
Thank you Emperor Pike.
0:23 "why are you clapping?" LMAO
to raise the HYPE to raise the ENERGY i mean come on Rob lets fuckin GOOOOO (no pun intended)
What about features like promises or async/await in JS? These new features are designed precisely to improve reasoning in programming and therefore readability. This isn't the same as just tagging on new features adhoc because other languages have them. They achieve some of the goals attributed to Go here.
Go uses channels to let coroutuines communicate with each other. And because Go doesn't support generics, there is no easy way to implement Promises / Futures.
6:18: "Features hurt readability"
Based on my experience, I disagree.
E.g. the with-statement in Python - which was added in 2005 - more than 10 years after the inception of the language - greatly improves readability.
It tells not only the interpreter, but also the human reader, "I have a resource here that will be released after use", and the life-time of that resource is the indented block beneath "with".
I can make a similar case for templates in C++.
By contrast, Golang's notorious
if err != nil {
return err
}
clutters source files, the way exceptions don't. Sure, exceptions have their own issues, but with-statements, finally clauses and C++'s RAII idiom nicely pair with exceptions getting rid of repetitive checking for error codes.
No, I'm not arguing that Python or C++ were better than Go, or that there were no useless features in many languages that make code unnecessarily complicated, but I am firmly of the opinion that the statement "features hurt readability" is not generally applicable.
I agree. Some features(abstractions) can improve readability. I also agree with Rob's point about feature orthogonality, though. You can solve a problem by adding a new feature to address that specific problem, or by choosing your initial set of features such that they can be combined to solve any problem.
The with statement is something I love in Python, but consider how a language like Haskell does it: wiki.haskell.org/Bracket_pattern. Basically, functions are all that you need. The only thing the with statement actually added that was missing, is the block syntax to delimit the code block that runs between the enter and exit. In Haskell, that role is given to lambdas:
with (open "/tmp/test") close \file ->
putStrLn (read file)
So instead of adding a new feature to solve the specific problem of "context managers", you use existing features, like multiline anonymous functions, which is already used to implement other features. For example, here's how one might "implement" a "for each" loop like Python's without needing special syntax:
forM (range 10) \i ->
print i
In both those examples, the're are about 4 fundamental features in there:
* named functions
* anonymous multiline functions
* datatypes(e.g. whatever the range function returns is a concrete data type, like a list)
* typeclasses(i.e. interface/protocol, here for the iteration and the side effect)
I'm not saying Haskell is a simpler language, or that functional programming is a better solution. But by choosing the feature set wisely, you can avoid having to add new features to address specific problems and instead rely on existing features to address multiple problems.
The success of Go is proof that their decisions were correct.
@@user-ov5nd1fb7s Would you say the same about other popular languages? C++? Java?
Sure, people appreciate the simplicity of Go, and it works well for some use cases. But it's popularity doesn't prove anything other than that. Eventually, missing features that make programmer's life simpler, and that programmers are used to having in other languages, might end up limiting it's usefulness and popularity.
@@schok51 I can show you companies that died because unmaintainable codebases. That doesn't happen with Go. Of course, nothing is perfect. But the community is working hard to improve Go and crucial features will be added.
@@user-ov5nd1fb7s well Go is still young and doesn't have legacy projects to be migrated to. Plus not having "complex" features doesn't make refactoring easy. It just makes it simple. Simple ain't easy.
Chinese have similar saying - " True wisdom looks stupid"
source?
@@cunningham.s_law 大智若愚
Wise people don't look stupid. Only people who "think" they are wise looks stupid.
Awesome video, thanks for sharing.
awesome talk
That was a great talk!
Simplicity is so complex that we still see developers creating monsters that suck their lives in day-to-day work. 2019!
Damn I want to try Go so bad only because of that chipmunk/whatever plush now...
Superficial reasons for excitement often lead to disappointment in the long run...
@@Hexanitrobenzene Well, its promised performance do itch my interest either, but yea, most probably this is why I didn't touch it yet :D
I really like the analogy at 12:04 ^^
"If you make everything too expansive and explain everything in detail, you get a very verbose language. I won't name any but you know the ones Im thinking of."
Bet it's Java.
Unlikely. I believe he's talking about Cpp. Java is a verbose language to write, but is very simple to understand and read.
Java feels verbose because it has relatively few features, like Go. People praises C# and Kotlin because they are concise, not because they are simple.
@@林陵依 Pretty sure it's both. You affirm this by saying "Java is a verbose language [to write]". As a tangent, this can be a severe drawback for a tool as it raises development cost tremendously. Both for completing a development cycle of a feature and maintenance. This kills big products even in large corporations.
-Java
Ive written Java a long time and its becoming less verbose and more expressive as of Java 8. Go looks a promising language but I never hear the warts associated with the language.
Rob is the Craig Sager of the programming world.
What is "orthogonal features"? Any examples?
The Vivaldi web browser allows users to tile selected tabs (vertical split screen). That is not orthogonal, because the ability to see two things in a split screen mode was always handled by a window manager of your desktop environment.
There are two users. User A wants a feature X and user B wants a feature Y. You are a maintainer of that project and you decide to not implement these features directly. Instead, you allow users to implement these things themselves (through plugins usually). You only define an interface for the plugin and that's it. That is orthogonal.
There are two ways to download a file in Linux terminal. The tool A (wget) retrieves the server response and saves it into a file. The tool B (curl) retrieves the server response and echoes it to the terminal (STDOUT). The Linux terminal typically allows redirecting the command output to a file and that makes using tool A (wget) not orthogonal. The tool A (wget) doesn't have to implement saving to a file when the terminal can do that for any command output.
hmmm, but does a simpler featureless programming language really make code more readable? In some ways I guess, but I feel like the quality of the person programming is always the main factor. Good programmers think about people reading your code. I'm not sure fixing Go in stone for all times, like you got it right the first time, will ever fix this "human" problem.
orthogonal and basis vectors :) I guess that is a good analogy to redundant features.
Go may not make the problem of rouge developers worse -- only I'm disinclined to believe (gut feeling) it makes it measurably better. Does limiting syntax, limiting tools or limited coding style make a bad programmer even fractionally better a developer or team-player? That person in my experience often writes in a language called "spagetty" - and Go has no anti-spagetty AI built into it yet. I just suspect that the flexibility to wreak havoc offered by any "general purpose" language is going to be overbearing - and small systematic restrictions within the language tenuous.
Off course, that being said, Go has features that do really help us a lot.
Hello from the future,
How i see it is that in a lot of settings where go would be used, the barrier to maintainability is the complexity of the language grows with time. The amount of knowledge required to understand what is going on increases. The whole point is that if you constrain knowledge requirements to understand previous code (not just the language, but the complexity of the ecosystem that you can assume will be used) you make more maintainable code. Think how in java you have to relearn how to solve the same problem depending on what java version it was written in. or how python2 to python3 was.
I’m new to Go but isn’t map already in Go?
There is a map type in Go, but he's talking about the map() function that google came up with (as part of map/reduce).
he is a premature optimizer
dot Go !
gotta love it.
+steveoc64 Baby please dot go, baby please dot go down to new orleans. --Van Morrison
Great speech, great principles
Great talk. Though I must say that Go contradicts itself on some points. Like being concise and short but I have to write a for-loop for everything collection related! It doesnt have to be a functional language but please give me filter and a map function on slices. Sure, everyone coming from school knows a for-loop, but when reading the code I always have to understand the whole loop just to know what it is doing (or extract every looping into its own function which also clutters the code)...in most cases it is some kind of "filter that element" and "do something with that element". Maybe a loop is faster, but usually it doesnt matter and in case I need it to be a couple of cycles faster I can fall back to the loop.
Also all this c-style abbrevations...iota anyone.
Last but not least the server example given at the end. This has nothing to do with the language. It is just an API. I could write a one line server call in any higher language.
So I am going to learn more about Go, especially as a replacement for Bash, but I think I will not love it
Write it to my quote notes.
Pardon my ignorance, as I'm also new to golang. But what language does Rob keep referring to, especially when he was talking about features that aren't orthogonal? Thanks!
+Charles Le Java
+Kyle Kelley Lol I read that as "Le Java" at first
+Charles Le -- C++, I think.
("an octopus made by nailing extra legs onto a dog" )
scala, I guess.
@Peter Lund lol, I love the octopus analogy
I strongly dislike the phrase 'simplicity hiding complexity'. What is hiding the complexity is abstraction *NOT* simplicity. The best explanation of this I'm aware of is Rich Hicky's talk 'Simple made easy and I'm not going to try to duplicate that here. Common language conflates the terms ''simple' and 'easy' and this usage is not simple. Abstraction creates an illusion of simplicity but often fails in subtle ways, the law of leaky abstractions.
The Hickey video is very interesting and thank you for the reference, but I don't think the law of leaky abstractions applies here. Just because something can (and will) break destroying your beautiful abstraction, does not mean that your abstractions cannot provide simplicity to your users. From Hickey, simple means "unentangled", not interleaved and not braided.I totally agree. I would temporally coupled to that list. I would throw pike's usage of orthogonal right into Hickey's talk about simplicity. I think there's a lot of agreement here, although Hickey has obviously thought quite a lot about this topic.
Abstraction hides the implementation details, not complexity. Bad abstraction can easily create complex interface. Good abstraction is one of the ways to achieve simplicity, but not he only way. One of the other way is conscious feature omission, the philosophy of not having things, or having just enough things. One example is the 1 or no button of the iphone design, that deliberate omission of buttons is a deliberate choice, that achieved simplicity, but doing it right, is complicated, and there is a huge load of complexity hidden behind that one seemingly simple button.
At 10:35 was he thinking of C++?
Basis vectors are not necessarily orthogonal.
BOOM! Generics!
so many people hate the lack of generics... but I love every points here, generics is good, but not big deal for objective C developers, not big deal for javascript developers.
Not a big deal for JavaScript developers cause they have TypeScript, duh!
Golang does not have user defined generics. I believe the reason why they did that is to keep the language simple and fast for now, in order to attract more programmers. Eventually they will be added.
Funny, now I learnt rust, feel generics is not the worst problem of golang, the interface escape is the biggest problem, more interface you use, more it will be like java minus the rich type system java offers, if using interface causes objects to escape to heap, it is not necessarily fast. Another thought on generics, it is ok to write verbose code, but it is painful to provide a library without tons of empty interface, empty interface is really bad to use and really bad to perform.
I really don't think most of these points are valid. A real type system - that is, one with sum types and generics - is not just "more fun to play with". It allows you to verify the runtime behaviour of a program at compile time. In other words, if your program compiles, it is very unlikely to break at runtime.
Furthermore, Rust has demonstrated that it is very much possible to have a lot of very high-level abstractions with no cost at runtime.
If you want Rust then use Rust.
That was not the point of the comment though. Rob here oversimplifies.
But I think that Leo argues about the benefits of generics. The point is that generics do offer something more than just "fun to play with". Rob oversimplifies in his talk what some features have to offer. Prioritizing simplicity is one thing (and quite valid) but putting generics in the "fun to play with" bucket is another.
I think the talk explains exactly why generics is not included in the language, it is a conscious decision, to keep the language simple. I agree generics is a powerful tool, but if you followed any of the several serious discussion of adding generics to go you will realize how much complication each way of implementation would bring to the language usage. If you think the go team dismiss any language feature just because they think they are only "more fun to play with", you are very wrong. And if you feel go is not providing the features you need, there is always rust/java/python/js/erlang... no one is forcing you to use it.
Comparing Go to Rust doesn't really make sense since their problem domains are different. More to the point, while Rust has high-level abstractions that come at very little runtime cost, they come at an extremely high "write time" cost. The average programmer can learn Go in about a week, because the abstractions it uses are simple. You will not be learning Rust in a week.
1. In his slide he says : "Go is a clean procedural language designed for scalable cloud software." I'am reading "the go programming language" book and in the preface section, it says "it is truly a general-purpose language and finds use in domains as diverse as graphics, mobile applic ations, and machine learning". How a system programming language can be use to developpe applications ?
2. Go is expressive. If we compare it to the functionnal languages, it is not expressive at all. Haskall, scala, ocaml are more expressive then Go. Why he says it is expressive ?
In C and C++ there are many ways to skin a cat... in Go there are no cats only Gophers but the same ideas can be expressed. It comes down to efficacy, as languages become more complex they may seem initially more expressive as their vast amount of concepts overlap more with concepts we already understand, however the complexity makes them less effective.... a simple language that can still express the needed concepts will inherently be more effective. What use is expressiveness without efficacy?
I love Rob pike and Go
😍🤞🏾
Go is the most well-balanced language ever created.
I don't really share his thoughts. "Languages are getting more and more complex because they are adding modules and libraries to deal with multiple fields", so what? if you are in the field of machine learning and are not interested in the field of network traffic automation, just focus on the libraries relevant to your job and leave the other ones alone. You see? complex became suddenly simple.
he's talking about the complexity of a given language, not the libraries involved. C++ is a very complicated language, given how templates work for example. Go is a MUCH simpler language.
Sounds great on paper but I hate to say Golang is actually VERY hard to read(10x harder than python, 5x harder than c/c++/javascript/etc) and is not really that expressive.
怎么没有中文字幕啊！！！！！！
+box game 我也听不懂英语。而且我发现go的好多东西在英文里更好搜。比如论坛。哎，英语硬伤的劣势逐渐显现出来了。
字幕有自动翻译的功能
学最先进的机械就一定要学德语。
想学最先进的计算机软件就一定要学英语。
"If a language has too many features, or even more than you might need, you spend time programming thinking about which features to use. If there's really a lot of features, you may look at a line of code, write it one way, 'Ooh I could use something different, I could use this feature, I could use that feature...'. You might even spend half an hour playing with a few lines of code to find all the right ways you could use different features to make the code work a certain way. And it's kind of a waste of time to do that. But worse, when you come back to the program later, you have to recreate that thought process. You not only have to understand this complicated programming language doing whatever it's doing, you have to understand why the programmer, who might be you, decided that this was the way to approach the problem from the feature set available. And that is just, I think, bad engineering.
The summarization of this is 'The code is harder to understand simply because it is using a more complex language.' You want to have just one way, or at least fewer, simpler, easy to understand ways."
this is happening in C# nowadays. the features they put in is too much, too much information to take in for someone studying C#.
at 14 good
"Go helps improve diversity by not trying to be like other languages."
"In Go we intentionally limit programmers to only ever do things one way, with a few tools, so that things are not diverse."
Hmm....
What you're referring here are two separate things. What he is trying to say is that it is good to have different languages e.g. English, French, Chinese(diversity is useful) but it is not good when two people speaking Franch, for instance, have a problem understanding each other. It's creating a completely different kind of language barrier when everyone using the same language needs to know every variation of it in order to communicate properly(diversity isn't useful).
@@mladenarsovic7185 I agree. Speaking Franch is very hard.
he says they got package management right :D
Haskell is unique, it does add features that are inline with Haskell's design, Python is simple and occasionally add features to continue to evolve. Golang is "unique" and "simple" compared to C#, javascript and swift, what a low bar.
"Go is not like other languages" Sure Rob...
wow lissing on the 4:46 ,my question is Ken the God ,can i be your friend ,anaticha raposa and fox pad ,love google,blees all us .build the future with love.Muito obrigada.Forca
An uninspiring language by an uninspiring team.
+astatine85
Golang used for Docker, Hashicorp and Kubernetes and Google et cetera ! But yeah golang is uninspriring
I think that's your own personal sour outlook. I love Go and find it quite inspiring, as I do the principals involved like Rob here.
16:04 says "three strokes", shows two fingers.
Same as the "simplicity" in Go.
I can understand he wanted it to be simple and readabe, but made it pretty much the opposite.
For loop instead of map/filter and at the same time talking about the readability of Go?! Come on 🙂
Two words that explain his thinking and Go itself: wanna be.
Well, as someone who actually works in go, I have to say that you're wrong. I love working in Go, and find it the most readable language I've ever used, which includes assembly, basic, python, C, C++, C#, Forth and others I've forgotten by now.
What language do you think is more readable than Go?
I came here after hearing about Rob Pikes arrogance and eliticism being the reason Go is stuck in the 90s. I wasn't disappointed
+Siddhesh Rane
Yeah rust verbosity is better ! Like a fucking loop keyword and this shit like
// impl What is this shit to write {
x: &'a i32,
}
impl {
fn x(&self) -> &'a i32 { self.x }
}
fn main() {
let y = &5; // this is the same as `let _y = 5; let y = &_y;`
let f = Foo { x: y };
println!("x is: {}", f.x());
}
Arrogance and eliticism? Did you watch the same video? He made excellent points and supported them. What do you have to support you, internet rando?