Looks like Go is succeeding more in the space where scripting languages like Python and Ruby are dominant and less in it's original intended space (systems programming). Rob Pike has written about it too. I wonder if they see this as an opportunity missed or unexpected boon.
We definitely made a mistake at launch using the term "systems programming", because people automatically think of operating systems. What we meant were the kind of systems we build at google. Some of the examples in the blog post are "systems programming" in the same sense. So we are pleased to see Go being used for the job it was designed for, but we are also happy to see that Go has a broader appeal.
Four years of Go
31–40 of 202 posts
Re: Four years of Go
#32I'm betting on Go at the moment, using it to build some little libraries and writing some dummy apps to test the waters. Hopefully in 4 years when Golang developers are in demand, I have 4 years of experience under my belt. :)
Programming is now multi-language and multi-paradigm. It matters more what you can do and not what you can do it in. Being able to compose libraries and systems from parts is way more important than knowing a specific language.
These skills will transfer very well into other programming languages.
Re: Four years of Go
#33Earlier quoted context omitted.
Could you go into detail on your experiences for Go compared to JS or Ruby?
Takes me about 10-20% longer to do trivial things in go than ruby, but the results are much faster and bigger refactorings are also much faster to complete (nice type system). The ability to really max your perf out in short amount of time is also delightful
Re: Four years of Go
#34Earlier quoted context omitted.
We definitely made a mistake at launch using the term "systems programming", because people automatically think of operating systems. What we meant were the kind of systems we build at google. Some of the examples in the blog post are "systems programming" in the same sense. So we are pleased to see Go being used for the job it was designed for, but we are also happy to see that Go has a broader appeal.
You don't build operating systems at Google?
Most of the software we build at Google are server processes that talk to other server processes. Go was designed primarily for this role, but it is obviously useful for a lot more.
Re: Four years of Go
#35Earlier quoted context omitted.
Programming is now multi-language and multi-paradigm. It matters more what you can do and not what you can do it in. Being able to compose libraries and systems from parts is way more important than knowing a specific language.
Indeed, for example getting your brain wrapped around concurrency patterns in Go is very straightforward (especially since there is a plethora of documentation and examples). These skills will transfer very well into other programming languages.
Re: Four years of Go
#36Earlier quoted context omitted.
Yes it does, the point is "Go's ecosystem has developed really fast" but maybe a (hypothetical) better language developed in this day & age would've reached the same point in 2 years?
"A better language might do better" is not a very interesting point to make.
Re: Four years of Go
#37Looks like Go is succeeding more in the space where scripting languages like Python and Ruby are dominant and less in it's original intended space (systems programming). Rob Pike has written about it too. I wonder if they see this as an opportunity missed or unexpected boon.
We definitely made a mistake at launch using the term "systems programming", because people automatically think of operating systems. What we meant were the kind of systems we build at google. Some of the examples in the blog post are "systems programming" in the same sense. So we are pleased to see Go being used for the job it was designed for, but we are also happy to see that Go has a broader appeal.
Re: Four years of Go
#38Re: Four years of Go
#39Earlier quoted context omitted.
Spectacular con job ? Are you joking ? There was and continues to remain NOTHING that compares to the Java platform.
I assume you mean in terms of hype? Java can do stuff and people use it which is fine. The con was that it was inherently portable and secure and can be used for client software. None of that is true. Today if someone told me that our new client interface was going to be java that person would be reassigned to a role where their awful judgement would not resurface. Java today is basically the slower edition of C++ wh…
Re: Four years of Go
#40Earlier quoted context omitted.
We definitely made a mistake at launch using the term "systems programming", because people automatically think of operating systems. What we meant were the kind of systems we build at google. Some of the examples in the blog post are "systems programming" in the same sense. So we are pleased to see Go being used for the job it was designed for, but we are also happy to see that Go has a broader appeal.
Well, I would argue that there's a level between "db replication infrastructure" type projects and OS kernels. That is the space occupied by things like database engines (everything from BigTable and descendants to Oracle), distributed storage engines (GFS and descendants) etc. I don't think I've seen a project in Go that aims to deal with that level of "system-ness" yet. And I suspect I know the reasons (why, say, I…