> "I just don’t understand the point of Go. If I wanted a systems language, I’d use C/D/Rust, if I wanted a language built around concurrency I’d use Erlang or Haskell."
Agreed. C and Rust are systems langauges, Go is not particlarly great in that category. That is okay.
I will say, I hope you have fun getting an average CS graduate to properly write and maintain a Haskell or Erlang program with concurrency. Go is stupid easy to pick up for anyone who has worked with C/C++/C#/Java/Python/Ruby, which, by no exaggeration, probably encompasses every programmer alive.
Meanwhile, Haskell and Erlang look like gibberish to most programmers. And I'll admit, that's a lacking argument. Functional languages cannot be said to be bad just because most people don't understand the functional paradigm.
But the fact remains, an average programmer can sit down today with no knowledge of Go, and by the end of the day create a concurrent program using Go. And given the lack of flair in go, it's the langauge that lends itself to being maintainable. You won't see anything like in python or perl where you're almost expected to abuse the langauge internals (see this awesome example in python [0]). That's completely by design. [1][2] (scroll up to see the quote by Rob Pike)
If you have a team of a dozen guys working on a project with thousands of lines, your priority is not just performance (Go is quick enough [3]). It's probably not elegance either.
It's software that documents itself.
I used to work as a systems administrator for my schools engineering department. We would deal with fixing perl scripts dating back to the 90's. As students came and went, the result was hack jobs on top of hack jobs by students who are now in their 30's. I hated it. I would commonly have to rewrite scripts because over the years the basic flow of the program became completely asinine.
That's exactly where go does well. Go is a langauge for people who don't want to have to deal with abuses of the language that their coworkers put in place. Go is a language that understands that for programmers, maintaining code means fixing bugs and fixing bugs tends to boil down to hacky solutions. Go ensures that those quick fixes aren't hacks.
> "The only place I can see Go shining is for stuff like portable command line utilities where you want to ship a static binary that Just Works(tm). For interactive tasks I think it would be fine, I just don’t think it is particularly well suited to long-running servery things."
I really don't understand why he feels that way. I don't see the distinction.
> "It also probably looks attractive to Ruby/Python/Java developers, which is where I think a lot of Go programmers come from. Speaking of Java, I wouldn’t be surprised to see Go end up as the ‘new Java’ given the easier deploy story and the similar sort of vibe I get from the language. If you’re just looking for a ‘better’ Ruby/Python/Java, Go might be for you, but I would encourage you to look further afield."
This reminds me of The Story of Mel [4].
If you're someone who enjoys programming and are writing the code for fun, I agree. Find the most unique language and do it in the most elegant way. Programming is almost an art, and if you're trying to be artistic, unique langauges are great for it.
But not all software is artistic.
> "Good languages help evolve your approach to programming; LISP shows you the idea of code as data, C teaches you about working with the machine at a lower level, Ruby teaches you about message passing & lambdas, Erlang teaches you about concurrency and fault tolerance, Haskell teaches you about real type systems and purity, Rust presumably teaches you about sharing memory in a concurrent environment. I just don’t think I got much from learning Go."
I don't think that all langauges need to be learning experiences. Sometimes you just need to get shit done.
> But the fact remains, an average programmer can sit down today with no knowledge of Go, and by the end of the day create a concurrent program using Go.
If there's any benchmark more pointless than the alioth benchmarks game, it's the 'what can a novice programmer do with the language in the course of 8 hours' benchmark.
There are zero businesses that operate by giving novice programmers 8-hour tasks in unfamiliar languages.
The first company I was at prided itself on the "sink or swim" method of hiring. You'd be surprised how many developers out there judge new hires by how quickly they show they can start shipping code.
> You won't see anything like in python or perl where you're almost expected to abuse the langauge internals (see this awesome example in python [0]).
You linked to someone intentionally trying to obfuscate Python as much as they can. Programmers are certainly not "almost expected to abuse the language internals". All dynamic languages provide various means for code obfuscation... it doesn't mean the language encourages obfuscated code. With the notable exception of Perl.
Depends on what you consider obfuscation. Consider the following python code:
a.b = c
In isolation, there is really no way to tell what that line of code will do. Maybe it will simply assign c to a.b. But because Python has property setters, it might also update some rows in a database[1], write a file, or make an HTTP request.
One might call that abstraction, but I think it qualifies as obfuscation. A single line can invoke arbitrary behaviour.
[1] This is how SQLAlchemy's models work. As I write this, the library is nearing it's 10,000th commit. A serious piece of software!
Agreed. C and Rust are systems langauges, Go is not particlarly great in that category. That is okay.
I will say, I hope you have fun getting an average CS graduate to properly write and maintain a Haskell or Erlang program with concurrency. Go is stupid easy to pick up for anyone who has worked with C/C++/C#/Java/Python/Ruby, which, by no exaggeration, probably encompasses every programmer alive.
Meanwhile, Haskell and Erlang look like gibberish to most programmers. And I'll admit, that's a lacking argument. Functional languages cannot be said to be bad just because most people don't understand the functional paradigm.
But the fact remains, an average programmer can sit down today with no knowledge of Go, and by the end of the day create a concurrent program using Go. And given the lack of flair in go, it's the langauge that lends itself to being maintainable. You won't see anything like in python or perl where you're almost expected to abuse the langauge internals (see this awesome example in python [0]). That's completely by design. [1][2] (scroll up to see the quote by Rob Pike)
If you have a team of a dozen guys working on a project with thousands of lines, your priority is not just performance (Go is quick enough [3]). It's probably not elegance either.
It's software that documents itself.
I used to work as a systems administrator for my schools engineering department. We would deal with fixing perl scripts dating back to the 90's. As students came and went, the result was hack jobs on top of hack jobs by students who are now in their 30's. I hated it. I would commonly have to rewrite scripts because over the years the basic flow of the program became completely asinine.
That's exactly where go does well. Go is a langauge for people who don't want to have to deal with abuses of the language that their coworkers put in place. Go is a language that understands that for programmers, maintaining code means fixing bugs and fixing bugs tends to boil down to hacky solutions. Go ensures that those quick fixes aren't hacks.
> "The only place I can see Go shining is for stuff like portable command line utilities where you want to ship a static binary that Just Works(tm). For interactive tasks I think it would be fine, I just don’t think it is particularly well suited to long-running servery things."
I really don't understand why he feels that way. I don't see the distinction.
> "It also probably looks attractive to Ruby/Python/Java developers, which is where I think a lot of Go programmers come from. Speaking of Java, I wouldn’t be surprised to see Go end up as the ‘new Java’ given the easier deploy story and the similar sort of vibe I get from the language. If you’re just looking for a ‘better’ Ruby/Python/Java, Go might be for you, but I would encourage you to look further afield."
This reminds me of The Story of Mel [4].
If you're someone who enjoys programming and are writing the code for fun, I agree. Find the most unique language and do it in the most elegant way. Programming is almost an art, and if you're trying to be artistic, unique langauges are great for it.
But not all software is artistic.
> "Good languages help evolve your approach to programming; LISP shows you the idea of code as data, C teaches you about working with the machine at a lower level, Ruby teaches you about message passing & lambdas, Erlang teaches you about concurrency and fault tolerance, Haskell teaches you about real type systems and purity, Rust presumably teaches you about sharing memory in a concurrent environment. I just don’t think I got much from learning Go."
I don't think that all langauges need to be learning experiences. Sometimes you just need to get shit done.
[0]: https://benkurtovic.com/2014/06/01/obfuscating-hello-world.h...
[1]: https://talks.golang.org/2012/splash.article
[2]: http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-in...
[3]: https://benchmarksgame.alioth.debian.org/u64q/go.html
[4]: http://www.catb.org/jargon/html/story-of-mel.html