I tinkered with D a bit (along with Nim, Dart, and C as a comparison) while writing a Clojure interpreter.

D seems to be a nice language, but I found the editor integration wasn't the best. I also found it annoying that the docs used `auto` all the time, so you could never figure out the right type annotations for their APIs (e.g. I want to call the foo API and return its value from my method, but the docs all use `auto` to refer to its return value, so I don't know how to annotate my method.)

I liked Nim better in almost every way but one: the compiler was fickle and would just fail silently sometimes.

>Nim, Dart, and C as a comparison)

Could I ask about your thoughts regarding Go (which has much less syntax and fewer features than all of the above). Have you looked into it?

Yeah. It should have been in that list, actually. I wanted to like Go. It seems simple (which is what I like so much about Clojure), but honestly, I found it to be frustrating for all the standard reasons the Go team is tired of hearing (e.g. no generics, error handling littering my code and obscuring intent, etc).

In fact, I think Go doesn't quite deserve the reputation it has as being a simple language. It's a familiar language, and it's a bare-bones language, but that's not the same thing as being simple.

One last thing that was interesting: I got more null pointer runtime exceptions in Go than I expected (vs none in Nim, for example). Granted, I'm a Go n00b, but I'm also a Nim and Dart n00b, and didn't have nearly as much trouble with those two languages (aside from the aforementioned compiler bugs).

I really wish modern statically typed languages would rid us of null pointer errors once and for all. This is totally possible with Option types, but seems to rarely be done. I wonder why?

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.

Thank you.

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:

- http://www.buildyourownlisp.com/

- https://github.com/kanaka/mal