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?

Have you looked at Rust? It uses Option types, has generics, also uses return values for error handling but has a lot more syntactic sugar to make it cleaner than in Go.

I have tried Rust in the past, though not on this particular hobby project (my Clojure interpreter). I found it hard to get into, and I've gotten into a lot of languages in my time-- some of which are considered challenging (e.g. Haskell). With Rust, I always felt I spent too much time wrestling with it, and not enough time being productive. I imagine that you hit a threshold at some point and that begins to change. But for my side projects, that bar wasn't worth jumping.

Rust's major goals this year are around learnability and productivity; maybe come check it out again someday :)

Could you point to any materials (e.g. blog post, roadmap document...) that deal with this? Thanks.

https://blog.rust-lang.org/2017/07/05/Rust-Roadmap-Update.ht... is our "the year is half over" update, and has a link to the overall goals right at the top.

Awesome, thanks!

Inferred lifetimes? A man can hope :).

Inferring lifetimes from the implementation of a function won't happen for the same reason that inferring types won't happen: it is really nice for the signature of a function to not automatically be changed if the body is changed, instead programmers should be told when they might be breaking their users.

However, the compiler could (and did, I believe) run inference and suggest a fix that the programmer can explicitly include.

If it were always possible to infer all lifetimes, we'd do it. Unfortunately that's not the case.

There are a number of RFCs in the pipeline to help with lifetimes, including more elision. In no particular order:

https://github.com/rust-lang/rfcs/pull/2115

https://github.com/rust-lang/rfcs/pull/2094

https://github.com/rust-lang/rfcs/pull/2093

Rust's documentation is very well written. The authors have put in great effort to make things clear.

Granted Rust has some paradigms and constructs which are not easy to learn, I found it rather exciting. I think it has future scope.

Wonder whats happening with Redox. I hope Rust adds more libraries, especially network related, since the networked world is increasingly looking like a distributed OS of sort. Browsers are looking like an OS or a shell inside the OS. Browsers are getting more complex with more functionalities added every few months. Not sure I expressed my thoughts correctly, but I guess one can understand what I mean.

Rust should move away from C standard library, if possible.

> Wonder whats happening with Redox.

They've been involved in Google Summer of Code, and so have had lots of status update posts lately, here's the latest: https://redox-os.org/news/gsoc-self-hosting-final/

> Rust should move away from C standard library, if possible.

It's not always possible, but on systems where it is, there's some ability to do so, see https://github.com/japaric/steed

Thanks Steve.

>It's not always possible, but on systems where it is, there's some ability to do so, see https://github.com/japaric/steed

Doesn't linking to it make a Rust program "unsafe", in the Rust sense? Or my understanding is probably not correct.

Using unsafe inside of safe is totally fine. See https://doc.rust-lang.org/nomicon/safe-unsafe-meaning.html for more.

Cheers, thanks.

I sometimes feel Go went to far, as in the classic quote "Make it as simple as possible, but no simpler".

I understand what you mean by your quote. I will give you a toy example, then show the single example I have from Go, and ask if you know of any more.

Toy example, a language that is simpler than possible:

- If a language does not have functions, you must copy and paste the code every time you call it. Such a language would be "simpler than possible".

The only example I know from Go:

- Many people feel that the lack of generic functions can be solved similarly - such as copying and pasting code or doing search/replace - but makes the language "simpler than possible". (in the exact sense you mean.)

(A generic function is one that works on different types without knowing what they are when it is written, or similar behavior.)

So I've given you a single real example. But it's the only one I can think of.

Other than this example, can you list the ways in which you feel it's "simpler than possible" or went "too far"? I would really appreciate if you could be specific.

I'll repeat my usual comment about what I found annoying in Go:

It seems like strings are basically the only data type of unlimited size that is supported as map keys (or at least that seemed to be the case a few years ago).

I think that only types for which equality is defined in the language could be used as keys. Those types where numbers, characters and all other "small" fixed-size types, structs all of those members had equality defined, arrays of a type with equality, and strings. The size of an array is part of the type, so in that list of types with equality the only source of unlimited sizedness are strings.

I guess that cover most cases where you want a type of unknown size as a key, but I found it pretty annoying. If you want to use, say, polynomials with integer coefficients as keys in a map, you'd have to either choose a fixed maximum size (degree, for example, or number of monomials) for the polynomials or convert back and forth between strings.

It's not the only language that forces you to convert things to strings and back for use as map keys (AWK and Lua come to mind), but I wish it didn't have that limitation.

You can actually dynamically generate struct types at runtime with the `reflect` package.[1] That might work for you. Not that I'm saying this is an ideal solution, I'm just giving you another option to evaluate. :-) (I suspect I'd sooner choose "serialize to a string" if I were in your shoes.)

[1] - https://golang.org/pkg/reflect/#StructOf

thanks!

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.

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.)

so thank you, perfect reply.

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

[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.

[1] https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

What is "vendoring"?

Vendoring is when you include a copy of your dependencies inside of your project.

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.

Rich Hickey (creator of Clojure) gave a great talk on easy vs simple: https://www.youtube.com/watch?v=rI8tNMsozo0

Here's something familiar to most professional web developers: JavaScript.

But it's also complicated: https://www.destroyallsoftware.com/talks/wat

Here's the spec: https://www.ecma-international.org/ecma-262/8.0/index.html

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.

This is a better answer than the one I gave. And is also a good explanation of why leaving Clojure for anything else always feels so icky. :)

Thank you, this was excellent and very informative.

You weren't kidding about the lambda calculus definition!

https://en.wikipedia.org/wiki/Lambda_calculus#Formal_definit...

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?