EDIT: this is getting downvotes for some reason even though it's just addressed to OP. OP, you could email me at the link on my profile if you didn't want to answer here. I'm not on the Go team or anything, just curious.
---
Thanks for your answers!
So I know you don't want to rehash what's easy to find elsewhere, but your perspective is different because you wrote a Clojure interpreter. It's not the same as what I can find from people who just use languages.
You just list:
>(e.g. no generics, error handling littering my code and obscuring intent, etc).
But could you flesh out this litany of complaints, even if it's common? I just want to know your version of that list, without the 'etc'. It's not going to be the same as other people's - different things will bother you or come to mind for you. I'm trying to understand these from your perspective and background. (which is unusual.)
Secondly, you write "but that's not the same thing as being simple". I don't really understand. Here on HN, people say you can pick up Go in an "afternoon" and become proficient in "a week".
You write that it is not simple but I don't know what you mean in specific, even when you write as a "Go n00b". This reply will be particularly interesting to me, because, since you've literally written an interpreter, compared to an average user, everything is simple for you.
Like, think of a standard designer who has first dabbled in Javascript and for some reason picks up Go. Whatever isn't "simple" for them would ordinarily be super-simple for you. So what's not "simple" for you is like obscure string physics to a person who is barely a programmer at all. I'm really curious what parts you didn't find simple.
I'll let the parent answer you (though I have similar sentiments as someone with language implementation experience, and FWIW, I have professional experience with Go, Ruby, JavaScript, Clojure, C#, and I've used Haskell, F#, and much more in my free time).
I will, however, point out that you're likely using a different definition of simple ("easily understood or done; presenting no difficulty.
") than is often used in technical circles ("composed of a single element; not compound"). Simplicity and ease are distinct, and one does not necessarily imply the other; it's not hard to find convoluted designs that feel easy due to familiarity, while a much smaller, consistent design will feel difficult because the concepts (while fewer in number) are foreign.
And here's something unfamiliar and often considered difficult: lambda calculus.
And yet it's very simple. Here's the entire definition of lambda expressions (lifted from Wikipedia):
---
Lambda expressions are composed of:
* variables v1, v2, ..., vn, ...
* the abstraction symbols lambda '?' and dot '.'
* parentheses ( )
The set of lambda expressions, ?, can be defined inductively:
1. If x is a variable, then x ? ?
2. If x is a variable and M ? ?, then (?x.M) ? ?
3. If M, N ? ?, then (M N) ? ?
Instances of rule 2 are known as abstractions and instances of rule 3 are known as applications.
---
So, while JavaScript programmers might find the lambda calculus unapproachable, it would be difficult to argue that the former has fewer gotchas than the latter, as the former is wildly complicated and the latter is so simple that you could fit its definition on business card. Once you appreciate the difference between simplicity and ease you can better evaluate your options, as it might be worth investing time in learning an intimidating, foreign solution if you believe that it will provide better stability/correctness guarantees/etc. Also, simple things are generally easier to work with compared to complex things assuming a similar degree of experience -- so investing in unfamiliar-yet-simple things will often save you a lot of effort in the long run. Strictly adhering to familiar things is a recipe for being stuck in a local optimum.
To take this full circle, Go being easy doesn't mean that it's simple.
With that said, your comment seems quite technical, about the single point of simplicity. You don't talk much about Go at all, and although the other poster has also answered, I'd be curious in your answer as well (if you've worked with Go):
You've given a definition of simplicity (correcting mine). Did you find Go simple? What other thoughts did you have?
Well, building an interpreter isn't that difficult. Even less so, if you're building one on top of a good dynamic language (which was the case with Dart in my original list). If you're interested in getting started, these are good intros to the basics:
[EDIT: I didn't down-vote you, and I appreciate the question.]
Simplicity is not the same as familiarity. It's not the same as a small feature-set, either. Gratuitous Rich Hickey reference for what I mean by simple[1]. So most languages aren't simple by that definition, but I'd say that Go's inconsistencies prevent it from being what I call simple. Some examples:
Instead of having a general mechanism for describing datatypes, they have several one-off, exceptional syntaxes (such as for how you define tyep type of a map).
Go's dependency management / vendoring (or lack thereof) is complexity-inducing, even though it appears simple at the outset.
Sometimes you do things via method (such as `fmt.Println(message)` and sometimes via function (such as `len(message)`).
And so on. Coming from a language like Clojure that is regular, possibly to a fault, Go seemed to be littered with one-offs and inconsistencies.
I feel a little bad writing up a full list of what I don't like about Go since I haven't used it enough to be as informed as I should be to write such a list. But... since you asked.
No generics, error-handling obscuring flow of logic, dependency-management, the compiler complains about not-used vars and imports (which is great, except when you're prototyping) it should be togglable, it felt like I was producing a lot of code to do something small (I felt the same about C, but not about e.g. Nim), and then, I think the little oddities I mentioned in my comments on simplicity added up to make me feel like I was building an inelegant solution.
That's off the top of my head. There were possibly other gripes, and I am possibly mis-remembering, so take it all with a grain of salt.
Hey, thanks! This is exactly what I was asking from you and the fact that these points remain in your mind despite being distant memories makes your reply particularly interesting.
(What I mean is if if you worked with Go every day you likely would not have the same perspective anymore.)
---
Thanks for your answers!
So I know you don't want to rehash what's easy to find elsewhere, but your perspective is different because you wrote a Clojure interpreter. It's not the same as what I can find from people who just use languages.
You just list:
>(e.g. no generics, error handling littering my code and obscuring intent, etc).
But could you flesh out this litany of complaints, even if it's common? I just want to know your version of that list, without the 'etc'. It's not going to be the same as other people's - different things will bother you or come to mind for you. I'm trying to understand these from your perspective and background. (which is unusual.)
Secondly, you write "but that's not the same thing as being simple". I don't really understand. Here on HN, people say you can pick up Go in an "afternoon" and become proficient in "a week".
You write that it is not simple but I don't know what you mean in specific, even when you write as a "Go n00b". This reply will be particularly interesting to me, because, since you've literally written an interpreter, compared to an average user, everything is simple for you.
Like, think of a standard designer who has first dabbled in Javascript and for some reason picks up Go. Whatever isn't "simple" for them would ordinarily be super-simple for you. So what's not "simple" for you is like obscure string physics to a person who is barely a programmer at all. I'm really curious what parts you didn't find simple.
Thank you.
reply