Also, it's true that the Go spec doesn't guarantee tail calls are optimized. If Go were designed to be a functional language, that'd be problematic. However, guaranteeing TCO isn't free in implementation, and in the presence of features like "defer", it becomes non-trivial to understand when it is happening. So, while I like TCO as much as the next guy, I agree with the Go designers decision not to require it. Just like with a pile of other languages, the lack hasn't stopped people from writing good code, and not even stopped them from writing useful recursive code. I think there's some code in the Go standard library (parsing code, mostly) that uses trampolining to simulate it, and that code would be better off if it could just do a tail call, but on the balance that code still works well and isn't convoluted.

Anyway, not a bad blog post; I agree with most of it. But, as someone who has written a fair bit of code in functional languages and a fair bit of Go, I find that the more Go I write the less I care about the language features (or lack thereof) that I was horrified by at first, and the more I see most other languages as overcomplicated. Go isn't a very good language in theory, but it's a great language in practice, and practice is all I care about, so I like it quite a bit.

Otherwise, this comment makes me more interested in Go than I have been before. OCaml has a bazillion features that I never use, and since every OCaml program can look completely different by using those features, the libraries outside the standard lib are all but incompatible with my code.

That was a huge WTF to me. Isn't your job as a language designer to do that work so that I, the language user, don't have to?

Also I'm pretty sure the amount of work in the compiler was only one of the considerations, and while I don't doubt your account of your conversation with rob, I doubt it was the main consideration in this design decision.

There are pros and cons for both models, but they are roughly equivalent and I never missed pattern matching in Go.

And there isn't anything about that complaint that is the slightest bit "academic". If anything, the academics are far more into the idea that they can come up with the One Correct Behavior and write it straight into the underlying specification of the language than the practical languages are. (One of my personal criticisms with Haskell right now is that while this is slowly being fixed, it's being fixed in a haphazard, one-off for each syntax element manner, instead of seeing the underlying problem and addressing it in a unified manner, and I think that this is because, like I said, academics don't really think this way.) In my book, it's simply a mistake.

I think it's a grave mistake to collapse this criticism of Go to "It's not academic enough"; my sense of the problem is actually that it's more on the practical side. There are some clear practical wins that really ought to be well known by anybody doing PL design that seem to have been passed up. Hopefully these are corrected, but it dampens my enthusiasm somewhat that they were missed in the first place. YMWV.

just like C was meant to be a practical language for writing Unix tools. thanks for your comment.

(1) Recursive anonymous functions: This is the first time I've heard this criticism. MLs usually don't have this functionality either. It's not too much trouble to give the function a name.

(2) Tail call optimization: TCO isn't free. It requires all callees to pop their arguments, which slightly penalizes every call in the program. Rust is planned to support full TCO, but the current compiler only does sibling call optimization (a subset of TCO).

(3) Continuations (I assume call/cc is meant here): Again, these are expensive, because they interfere with the stack discipline. You end up having to garbage collect stack frames in the worst case. For this reason both Go and Rust have implemented exceptional control flow using stack unwinding and destructors. (For Go panic/defer/recover play the role of destructors, while for Rust we use a more traditional RAII system.)

(2) Someone has to do cleanup anyhow. Either the caller or callee. (I am no expert in calling conventions) Anyhow, isn't this practically free, because the stack is in the L1 cache?

(3) To implement lightweight threads (ala. Erlang, Go, Stackless) you already can't allocate your activation records on the C-stack. So the main cost for call/cc is already paid for. Besides, Go lacks any form of non-local jumps, so escape continuations alone (setjmp/longjmp) would already be an improvement.

    func main() {
    	bar := func() {
    		fmt.Println("Hello, 世界")
    	}
    	bar()
    }

    func global(some_arg_to_close_over Bar) {
    	func walk_tree(node Node) {
            ...
            walk_tree(left(node))
            walk_tree(right(node))
    	}
    	walk_tree(something)
    }

It's a very new language, and things are being improved + fixed all the time, I would be very surprised indeed if tail-call optimisation + the ever so vital self-recursive lambda issue weren't fixed at a later date. To treat these things as permanently a part of the language is disingenuous at best.

Rob Pike (part of the core team) has said that what puts a lot of PL people off is that it is not theoretically exciting, it's just designed to be very useful [1].

The funny thing about go is that it seems like an uninteresting language when you first begin, but as you write more code you begin to appreciate its simplicity and orthogonality and realise that these are extremely nice qualities.

Language design is as much about saying no to things as it is to saying yes to things.

On a related note, I don't like the implication that there is now a scientific method to language design which obviates the need for practical considerations - that strikes me as class A ivory tower bullshit.

[1]:http://www.youtube.com/watch?v=-i0hat7pdpk&feature=playe...

Most PL academic research goes into Haskell/ML , and we know how useful they really are. (Monads/Type inferencing , anyone?)

I tend to write erlang or c++ mostly for my day job. I do really wish the designers had a bit more erlang experience. Just a touch. Just enough so that I had a way to propagate the death of a goroutine through a bunch of other goroutines without building all of that manually.

For example, code I wrote today:

http://pastebin.com/Zp6eqqTa

That infinite loop is really infinite. If the goroutine feeding the channel dies (e.g. if the connection is dropped), this thing will keep reading on the channel. In erlango, I'd do something like "go_link client.Feed(ch)" and the right thing would happen. Here, I really need to spin up a second channel to send out the death spurt, select across the channels in my loop and send my death message with defer.

defer is awesome, and I wish every language had it (C++ has something that looks like it if you write enough code and squint hard enough). Still, I've got a lot of code like the above and I imagine it's not an uncommon thing.

Every language has something that just feels unjustifiably wrong with it, though. go certainly isn't one I'd be pained to use if I had to every day.

(Edit: couldn't figure out code formatting, tossed it over to pastebin)

http://pastebin.com/FMSLvFCn

Throwing in a "defer close(ch)" and that range thing did exactly the right thing. I'm not sure my API is right, but I know how to get it right now. Thanks a lot.

I feel the same way. I had this hope that this would be what I would learn instead of Erlang. You know it has goroutines and channels -- kind of like processes and casts. Well except that it is not the same. Erlang's processes that have explicit pids and messages are cast to those processes by referring to their pid, make a lot more sense to me than a bunch of channels. Maybe it is just me, but I really just prefer the Erlang way. (Is the the "actor" vs "CSP" paradigms?).

Then it is what you mentioned, exit signals. Anyone who wants to promote concurrency as first order feature in the language and expects it to be useful in the real world, would have to have something like supervision trees & OTP. In other words when you have lots of little goroutines doing stuff concurrently, it is expected some will just crash and then you'd want to do something reasonable, which is not always to just crash the whole application (OS process).

http://confreaks.net/videos/115-elcamp2010-go

"It turns out that, in Go, you can't write a self-recursive anonymous function - there's no way to make it refer to itself. Well, you can do a dirty hack that's the "official work-around" (I'll let you google for the bug report)."

To summarize this argument: 1. It is impossible to have a self-recursive anonymous function in Go. 2. Oh wait.. It is completely possible, but far too ugly to soil this blog post.

I looked up the temporary solution (http://code.google.com/p/go/issues/detail?id=226). It is this:

    var recurse func()
    recurse = func() {
      recurse()
    }

(tl;dr The author just doesn't like the fairly-simple work-around proposed while the language is still developing)

Edit: There definitely are far more important things in Go I dislike, and would change, however this blog post is essentially fluff.

Pascal's nested functions really just scoped the name of the function differently, but they were equivalent to a function definition on the outer-most level.

That said, I'm keeping an eye on it. If it takes off I'll learn it but it doesn't make sense to make it a priority yet, IMO.

Can anyone who shares my opinion chime in on what things they think cause the syntax to suffer aesthetically?

Try it for two days and you'll change your mind.

Also, see: http://blog.golang.org/2010/07/gos-declaration-syntax.html

While I know there are programmers who act just like you described, my complaint is with Go's syntax specifically.

I (unlike the majority) like Erlang's completely strange and radical syntax. When I see, it tells me that "there is something completely new happening here, don't expect this to be C++ plus processes" or something like that.

Go is the only language I've ever tried for a while and been really put off by the syntax. I can't quite articulate why either. It's not...pretty. I write quite a lot of C++ and Python, so theoretically I should be a pretty good fit for Go. But it doesn't click with me.

I'm not a language expert, so if anyone can correct me on the theory I would appreciate it.

Dynamic languages have much more bare function/object definitions.

Haskell does make Types look sexy on the other hand. So yes there could have been some borrowing from there.

Anyway, it's designed to allow easy parallelism. It's a system's language for parallel work.

The only thing that I don't like about it is that the built-in types get special treatment (if you want to write a map yourself, you can't use the same syntax). This indeed feels like a design smell.

GO is still very useful this way, but I do hope that it gets generics/templates sometime in the future.

Way to miss the boat.

What about Haskell? Is Prelude library or language? Every Haskell file has it preloaded, so you can't code without it (without effort, anyway); but it can certainly be implemented in Haskell itself. Is Haskell the language just typed lambda calculus with type classes and some basic syntax sugar? Is IO Haskell language or library?

What about C's varargs? Is it language or library? It seems like library, since you include a header file to use it. But it's also impossible to do variable-lenght argument lists in C without it. What about longjmp? What about sbrk? It seems like library, since different OSs do it differently, and thus it has multiple implementations, in C. But without it, you can't do heap allocated memory, which is something you can't do without it.

Separation between language and standard library? What language does do it?

varargs, setjmp/longjmp and sbrk are 100% library. You can do varargs without stdarg.h; if you know the calling convention, you can just walk through the memory occupied by the arguments. setjmp is trickier but if you know the rules you could write it using assembly language, just like the library writers did. As for sbrk, I'm not terribly familiar with that I do admit, but judging by the man page it is not part of the C standard library, kind of proving my point. But you can definitely have a heap, and allocate out of it, and (where plausible) grab more address space, without having it.

> You can write pretty much the entire standard library in C, ... varargs, setjmp/longjmp and sbrk are 100% library.

If you're saying "These four functions can be written in C" then you are mistaken. If you are saying "These four functions can be written in assembly" then you are not saying anything interesting about C, because it is true of any language that it is possible to write its library in assembly if it's possible to write it at all.

In more detail.

Whether you can write va_arg in C depends on the platform's calling convention. On most platforms you can (because the default calling convention has to support varargs, and the easiest way to do that is to push the arguments on the stack) but on x86-64 you can't.

setjmp and longjmp cannot be written in C on any platform I'm familiar with, unless you're writing them on top of something like setcontext, which has a slight superset of their functionality. They are, however, very simple to write in assembly.

You can write sbrk in one line of C, and the glibc implementation is only ten: http://koala.cs.pub.ro/lxr/glibc/misc/sbrk.c#L29 But sbrk is simply a convenience wrapper around brk, which is necessarily a system call. And C doesn't have a "system call" statement.

(Actually, you can write brk in C too if you just want to allocate out of some fixed blob of address space, which is a reasonable choice on, say, a microcontroller.)

There is a pretty sizable disconnect between what's going on in academic computer science today and what professional software engineers are looking for. Go explicitly sets out to solve practical problems, not provide an implementation of this year's trendiest compiler porn.

I tried Googling, but why are Scala and Haskell automatically classified as "academic"? Is there value in learning them purely for that reason? I walked through some Haskell tutorials after reading this, but I'm rather stare at the sun than read Scala.

Scala gives me the impression it wants to be Java's C++. C++ is largely an extension of C. Sure you can use it entirely differently than C, but that C-ish core is still there. And Scala gives me that same feeling in relation to Java.

On the other hand, Haskell suffers from being a "pure" language. I mean "pure" in a wider sense than "functional". I mean "pure" as in being built entirely around a concept. For Haskell that concept is "functional programming". For Lisp, it's the "cons cell". And for Forth, it's the "stack machine". The benefit to being a "pure" language is there are all sorts of synergies you can take advantage of. The down side is when something doesn't quite line up, it gets ugly fast.

I also think the name "purity" is misleading. In the context of Haskell it means:

* Referential Transparency: references to things are indistinguishable from those things. This helps a lot with equational reasoning about code, optimizations and all sorts of mechanical refactorings. I don't think there are significant disadvantages here.

* Typed effects: Haskell types its effects and requires explicit composition of effects and not just of values. This, in turn, turns "side effects" simply into "effects" because they are so explicit. This has some disadvantages, mainly regarding learning curve. If you get a pure function type, you are guaranteed many of useful things about its behavior. The flip side of this, is that if you want to change a pure function to have effects and break these guarantees, you will have to change its type and somewhat restructure it.

Haskell doesn't "get ugly fast" in any circumstance I've seen. It accomodates an extremely wide array of paradigms as pretty encodings on top of its own functional paradigm.

See https://github.com/DanielWaterworth/Musings/blob/master/why_... and https://github.com/DanielWaterworth/Musings/blob/master/comp...

It's what people say when asked about languages they don't use or understand.

I.e., damning with faint praise.

Because they are inspired by 20th century mathematics rather than 18th century mathematics. This quote from wikipedia explains it:

These developments of the last quarter of the 19th century and the first quarter of 20th century were systematically exposed in Bartel van der Waerden's Moderne algebra, the two-volume monograph published in 1930–1931 that forever changed for the mathematical world the meaning of the word algebra from the theory of equations to the theory of algebraic structures. -- http://en.wikipedia.org/wiki/Abstract_algebra

The academic languages are the ones aware of that change in the meaning of the word algebra. Everyone learns Euler in high school. Nobody learns Mac Lane.