> Is it just me or did anyone else feel he was talking about Go?

That's really just you:

* Go does not ship with a set collection, no literal or convenient syntax

* Go only ships with with doubly linked lists and no literal or convenient syntax

* Go's literal syntax for the Array and Map builtins is significantly less convenient than that of most other languages (including but not limited to statically typed ones)

* Go is not homoiconic

* Go does not have an extensible syntax

* Go does not have math-oriented numeric types (quite the opposite), neither does it have precision errors (I am not even sure it can meaningfully interact with IEEE-754 error flags)

* Go does not have units (as far as I can tell)

* Go does not have pattern-matching, let alone unification (could have made error reporting good, can't have that)

* Go does not have aspects

* Go does not (as far as I can tell) have any special support for writing parsers

* Go has very little support for immutability

* Go does not have an explicit model of time

* I don't think I've seen any built-in structure serializer and deserializer (equivalent to Lisp readers and writers) in Go

> (No seriously, he described Go)

Only if you're completely delusional, skipped about 60% of his list and gave Go huge leeway on the rest.

Clojure, for instance, is a far better match on this.

Have a look at the "gob" package for serializer and deserializer support for Go types.

As for the syntax-related points, Go offers quite a bit. There's the goyacc tool, the scanner package, the template package (think quasiquote), and a bunch of packages for processing Go code: go/ast, go/scanner, go/parser, go/printer, go/build, go/doc, etc.

For math-oriented numbers, there's the "big" package. Many languages make such numerics much more convenient but you can get pretty far with little effort using just the "big" package.

This doesn't sound like Go to me, but I've never used it:

Homoiconic

Code can be manipulated as data.

Extensible syntax

I find I don't use macros much anymore. I do more with data-oriented programming. But it is nice to have when you need it.

A lot of this list sounds very much like Postscript: * Code is stored in an array with the execute flag turned on. Therefore functions can be easily edited (or assembled) as data. First class functions all the way. * The environment is a dictionary (associative array), which can be swapped with another dictionary at any time (not just at function entry points). * Garbage collection is standard

I was thinking that it may be an interesting project to write a general purpose Postscript (non-graphics oriented) interpreter, with a decent library, full continuation passing support, a different way of handling the "current dictionary" stack (to allow for static in addition to dynamic variable support), and a swappable parser to allow for additional program definition styles (infix or prefix in addition to the default postfix notation). Just something kicking around in the back of my head for a while.

Maybe Factor http://factorcode.org/ is what you want ?

Also, the rather new Red language (Rebol-like) http://www.red-lang.org/ seems interesting.

I also had the same weird feeling (see my post elsewhere in the thread).

I think Go's just still too immature for most people to invest deeply in. Production code can have a lifespan measured in years or even decades, so you want to use a language that's stable and mature, and you want to know that it's going to be around at least as long as your application. Things will change once the 1.0 Stable release rolls around, and people will really start dipping their feet in (and those people who have been dipping their feet might take a dive).

Yeah. And of course Go doesn't satisfy everything on that list either. But it does satisfy most of it with just the standard library.

Go 1 should solve most of the big problems, currently libraries need to keep up with weekly releases and packages are still being moved around.

He also took a good shot at describing Algol-68.

I am a big fan of Go, but he was certainly not describing this language. A lot the items on the wishlist were math and sciences items (arbitrary precision int, float, rational number; vectors, matrices; units). These are not in the language, and, while they can be in libraries (see big.Int and big.Rat), without operator overloading, I don't think Go is a good fit for these types of applications.

Absolutely, that was the first impression I also got when reading the post.

Actually, its Go's standard packages which matches most of these expectations.

This list lacks a feature that Go has and without which I wouldn't even have considered it : native and complete UTF-8 support.

I think a lot of languages could be described by most of the items on the wishlist. I thought Clojure was an extremely close fit, but then I program a lot in Clojure :)

I don't think Go matches all his criteria, though. For instance, Go is not homoiconic.

Clojure is close. From what I know of it, Go is close, too.