As someone who writes both Lisp and Go (and enjoys both), I find it odd that this article uses Lisp and Haskell as points of comparison.
> programming in Go isn’t “fun” in the same way that Python, Haskell, or Lisp is.
Yes, writing Lisp is much more "fun" than writing Go for me. But writing Go is much more productive and maintainable (both for solo projects and for larger groups).
> The idea is that there’s simply no way that any group of designers could imagine how people will want to use their language so making it easy to extend solves the problem wonderfully.
On the other hand, there's no way of making a language so easily extensible while also maintaining relatively uniform idiomatic, design, and style conventions across a language community. Go very heavily favors the latter.
> In Lisp, CLOS (Common Lisp Object System) was originally a library. It was a user defined abstraction that was so popular it was ported into the standard.
CLOS is actually very similar in some ways to Go's structs. Both emphasize encapsulating data inside an "entity" (object/struct), and separating the notion of behavior from that entity. To quote one of the language authors from GopherCon[0]: "Interfaces separate data from behavior. Classes conflate them."
Lisp was "designed" (if you can call it that) around the principle that extending a language should be as easy as writing a program in that language. Go was designed around the principle that there should be only one dialect of the programming language, for the sake of cohesiveness. It's a stronger assertion of the Pythonic motto, "There should be one, and preferably only one, obvious way to do it".
> Yes, writing Lisp is much more "fun" than writing Go for me. But writing Go is much more productive and maintainable (both for solo projects and for larger groups).
I heard ASP.Net WebForms get this defense, that no other platform could handle the "enterprise" needs for maintainability and every other platform was just building a pile of cowboy spaghetti code.
Well, an anecdotal counter-evidence is that we have some WebForms apps maintained by another team in our company and the developers from that team seem very happy and are productive enough to meet reasonable deadlines. I despise WebForms but that doesn't mean anything from a product managers perspective.
Yes, my point is that Go intentionally makes it hard for users to extend the language, while simultaneously learning from the successes and failures of other languages, and Yes, my point is that Go intentionally makes it hard for users to extend the language, while simultaneously learning from the successes and failures of other languages, and incorporating the results of that into Go.
The fact that users are able to create core language features has its drawbacks when it comes to cohesion in the language community. Lisp itself is a perfect example of this - codebases are immensely fragmented in terms of which libraries they end up using (Quicklisp is, in part, an effort to solve this).
Lisp was "designed" (if you can call it that) around the principle that extending a language should be as easy as writing a program in that language. Go was designed around the principle that there should be only one dialect of the programming language, for the sake of cohesiveness.
Both are legitimate philosophies for different use cases, but that's why it's kind of silly (IMHO) to compare Go to Lisp - the goals are not only different, but diametrically opposed in most ways.
I think the problem with Lisp is that it grew organically from a large community across multiple languages and 50 years of life. Not that the language was excessively expressive.
Go, on the other hand, was designed and implemented from a single vendor in a handful of years. That makes it far easier to provide a single, coherent platform. Once you provide a coherent, complete platform you don't need your users to solve every edge-case by implementing their own language features.
Any language that doesn't provide some kind of code-that-writes-code workflow will eventually leave its developers dealing with frustrating boilerplate.
> Yes, writing Lisp is much more "fun" than writing Go for me. But writing Go is much more productive and maintainable (both for solo projects and for larger groups).
Not sure about this statement. As the OP said in order to trick the anti-features of go you need to come up with super verbose syntax. Which is easy that's true but when the project tends to be quite big the mission becomes hard.
Also the "go get" thing is neat for small projects but for larger project IMHO is just broken. Godeps or few sh scripts can alleviate this but definitely is something needed to be addressed.
Yes, Go is boring, but it's interesting that the people who hate on Go for being boring are not the same people who hate on Java for being boring (though Java 8 is much improved).
I don't really get what all you guys mean by "boring". I'd appreciate some clarification (especially about Go).
What does it mean for language to be "fun"? I have some intuition of "fun", but it doesn't play well with what are you saying. I'd say being "fun" means ability to solve your problems easily, concentrating on problems themselves, not on language pitfalls. Isn't it? That's pretty much synonymous (maybe a little broader though) to "productive". So I can't comprehend how language can be "less fun, but more productive and maintainable".
> I don't really get what all you guys mean by "boring". I'd appreciate some clarification (especially about Go).
Go offers very little that's interesting or innovative and doesn't go out of its way to empower you in any particular way. It's fairly straightforward and tries to avoid gotchas, which is both good and bad. This means writing code is easy and you're unlikely to make a mess, but there are relatively few opportunities for making your code read better or to structure it better.
In a nutshell: Writing code is more of a drudge than an art.
For example, I was recently writing a processor for some data that came in an XML file format. I figured maybe throw it at Go since it was a lot of data and Go has pretty good XML support. In Go, this was a lot of looping and copying and basically nothing all that confusing but it just felt like busywork. For fun, I decided to write it in Clojure as well. The Clojure version was much more pleasant to read, with all the loops disappearing into simple compositions of map, reduce and filter. It felt nice to be able to easily express things in such an elegant way instead of on a more machine-like level.
(To be clear, I am not a great Go programmer and wouldn't want to speak for the Go community, though this is something the language creators seem to agree with. I'm just trying to explain what how I understand this stuff.)
> Go offers very little that's interesting or innovative and doesn't go out of its way to empower you in any particular way.
That's true of the features looked at individually. I think its particular combination of design choices is interesting and novel ("innovative" requires a value judgement that I am not quite ready to make in Go's case; though I think the momentum its gained in certain areas is quite likely because it does offer something that is innovative in its utility even if its not immediately apparent why the particular combination of features it provides should be.)
My feeling is that it's mainly the CSP features and the relatively good speed that make Go stand out despite being "boring." Having such strong concurrency primitives baked into a generally performant language is really cool and makes it the obvious choice for doing large tasks quickly.
People hate Java because it's unremarkable but successful. There's nothing particularly innovative or wild about it, but equally, nothing particularly awful (plenty of mediocre, of course). Whether despite or because of that, it somehow became the most widely-used language in places you get paid to sit and write code. It always feels cool to hate popular things, and it always feels cool to hate boring things. Hence, Java became the Nickelback of programming languages.
I like some Nickelback songs. Also, I don't hate on Java, I've even gotten seriously into it for about two years (for a university project and later got a job based on that), and it just made me unhappy (which is a big deal for me, for unrelated reasons). However, I never felt unhappy coding in Ruby (love it!), C (even though it was/is frustrating sometimes), C++ (ok, I am relatively new to it), Python, JavaScript... I tried other languages like Haskell, Erlang and similar, that didn't stick (Erlang syntax will plague me with confusion forever, probably), but nine of them made me unhappy when I worked in them.
> programming in Go isn’t “fun” in the same way that Python, Haskell, or Lisp is.
Yes, writing Lisp is much more "fun" than writing Go for me. But writing Go is much more productive and maintainable (both for solo projects and for larger groups).
In fact, this is almost an intentional "feature" of Go: http://aerokode.com/blog/go-is-boring
> The idea is that there’s simply no way that any group of designers could imagine how people will want to use their language so making it easy to extend solves the problem wonderfully.
On the other hand, there's no way of making a language so easily extensible while also maintaining relatively uniform idiomatic, design, and style conventions across a language community. Go very heavily favors the latter.
> In Lisp, CLOS (Common Lisp Object System) was originally a library. It was a user defined abstraction that was so popular it was ported into the standard.
CLOS is actually very similar in some ways to Go's structs. Both emphasize encapsulating data inside an "entity" (object/struct), and separating the notion of behavior from that entity. To quote one of the language authors from GopherCon[0]: "Interfaces separate data from behavior. Classes conflate them."
Lisp was "designed" (if you can call it that) around the principle that extending a language should be as easy as writing a program in that language. Go was designed around the principle that there should be only one dialect of the programming language, for the sake of cohesiveness. It's a stronger assertion of the Pythonic motto, "There should be one, and preferably only one, obvious way to do it".
[0] https://twitter.com/chimeracoder/status/459827405386162176