[eli_gottlieb]

>I also happen like the language on its merits. I also believe that most of those who disagree don't share the design goals of the language designers and wanted mostly just another derivative functional language or some fads-of-the-day-in-academia thing like Scala.

Oh, goody, jumping for joy, another Industry Versus Academia holy war!

Look here. I think Go has some very, very nice ideas in it. I also think it's fundamentally broken by a couple of stupid decisions the designers made: no exceptions, no parametric polymorphism. I also think it's fundamentally pointed at the wrong problem domain: systems languages don't have runtime libraries, don't have garbage collection and don't require operating systems beneath them so that they can write free-standing systems code.

Go is a brilliant, but also broken, competitor against C++, Python, Java, and Erlang (especially Erlang) for the applications-language space, especially highly-concurrent applications (as sometimes handled by Erlang, which I will be happy to see Go murder and replace). Go is not remotely a replacement for C.

And the exact reason for these things is that Go ignored parametric polymorphism (aka generics) and left out exceptions (which are messed-up in Java by quite widely useful in real programming!).

Now, as to "derivative functional languages", there mostly aren't that many. Most derivative work in functional languages gets fed back into Haskell, and nobody expects you to use Haskell for doing Real Work. Haskell does, after all, have the motto, "Avoid success at all costs."

And as to "fads-of-the-day-in-academia", Scala is the single best language I've ever used. And I don't even use all of it. I just use the subset of Scala that is Everything Java Should Have Been.

It has lambdas and closures. It has just enough type inference. It has mutability control for slots. It has object orientation and case-classes/pattern-matching and type-classes via implicit parameters. Scala lets me figure out what language paradigm I need to Get Stuff Done. It's the Python of statically-typed languages, and it interoperates with a vast outside ecosystem to boot.

I can't say as much for every fad-of-the-decade-in-industry thing like Java or Go.

[luriel]

> no exceptions

This is one of my favorite features of Go. Exceptions are a horrible mess in every language I have seen that has them. They make following control flow basically impossible. They are equivalent to COME FROM.

Go's multiple returns and defer/panic/recover are a much cleaner way to handle errors, not perfect, but way superior to exceptions.

> Go ignored parametric polymorphism (aka generics)

Go didn't ignore parametric polymorphism, Go already has features (interfaces and slices/maps) that provide most of what people use generics for. Go might even get generics some day if a good design for them is found. But the people using Go every day don't miss generics, and that is because the language itself already provides what people needs.

Also note that C lacks both exceptions and generics, and many people still consider it the best language around to build many kinds of systems.

[ootachi]

Go has exceptions. They are called panic/recover.

This has been explained to you time and time again. You keep posting this exact same comment, complete with the "COME FROM" analogy. Then it gets explained to you that panic/recover are an exception system. Then you ignore it. It's really tiresome.

Additionally, people get around the lack of generics in C with macros. Go doesn't have those.

[luriel]

If panic/recover is the same as exceptions, why does everyone whine about the lack of exceptions?

The fact is that while in theory panic/recover are mostly equivalent to exceptions, in practice they are very, very different. Panic is only used in truly extreme situations (like running out of memory) or programmer errors, and you can pretty much write code ignoring it.

Most programs at most will need to call recover() once. Compare this with how exceptions are used in most languages where they are a fundamental aspect of a library's API.

Also the way defer() reliably and cleanly handles cleanup is much more pleasant than exception and 'finally'.

As for C macros, good C programmers have known for a long time that they are best avoided as much as possible.

[ootachi]

Because panic/recover are bad exceptions (recover can't specify the types of the exceptions it wants to recover from), and the libraries don't use them. Having to check errors is annoying since most of the time you want to bubble the error up to your caller. This is exactly what exceptions (or the error monad) do for you. In Go you have to do it manually.

Anyway, Go does have exceptions. It just doesn't make much use of them. Seems a shame to not use a useful feature, but oh well.

defer is not reliable if you forget to call it. RAII is much more foolproof than defer in this way. You can forget to call defer, but you can't easily forget to call the destructor.

[batista]

>* Having to check errors is annoying since most of the time you want to bubble the error up to your caller.*

No, most of the time I don't.

[ootachi]

What do you do then?

If the answer is "panic", note that exceptions are superior here, since exceptions let you "panic" without having to litter your code with those calls.

If the answer is some form of "log an error message", exceptions are superior, since you can group multiple related calls into one try-catch block and avoid having to check at the site of each and every call.

If the answer is some form of "return a different error code to your caller", exceptions are superior, because you can catch many different types of exceptions in one try-catch block and re-throw a different exception.

[batista]

>Go has exceptions. They are called panic/recover. This has been explained to you time and time again. You keep posting this exact same comment, complete with the "COME FROM" analogy. Then it gets explained to you that panic/recover are an exception system. Then you ignore it. It's really tiresome.

He might ignore the similarity of panic/recover with Exceptions, but you also ignore:

panic/recover is not used for 99% of exception control in Go. We just check the out-of-band error code and act accordingly.

Panic/Recover is only used for TRULY EXCEPTIONAL situations.

Wish we could say the same for, say, Java's exceptions.

[ootachi]

Odd that you say that, because the language that's most similar to Go here is Java, with its checked exceptions. The same reasoning that led to Go's error codes (that you should always handle your errors) led to checked exceptions. The fact that people generally think checked exceptions are a bad idea is a point against Go, not in favor of it.

Checked exceptions are superior to Go's error return codes anyway, since they make it easier to bubble your errors up to your caller.

[cageface]

Go is not remotely a replacement for C.

This is exactly what crossed it off my list. I am interested in a better language than C++ for writing really fast, low-level code but I already have tons of good options for higher-level code.

[batista]

>I also think it's fundamentally broken by a couple of stupid decisions the designers made: no exceptions, no parametric polymorphism.

Is C "fundamentally broken" too? It doesn't have exceptions or parametric polymorphism either, but people seem to get a lot of work done. Fuck, people even get work done with Javascript, that's it's a bona fide example of a language with broken semantics (Harmony fixes some of those).

The thing is, "fundamentally broken" to me sounds like "it's totally unusable", and that is far from the truth. You might call it "not as convenient as it could be", but not "fundamentally broken". Broken implies "it doesn't work". Well, Go works fine.

Parametric polymorphism would be nice -- at least they are already thinking of adding generics in some v2.0 edition. But it's not a showstopper either, as in "fundamentally broken".

>I also think it's fundamentally pointed at the wrong problem domain: systems languages don't have runtime libraries, don't have garbage collection and don't require operating systems beneath them so that they can write free-standing systems code.

Well, by the "systems" moniker, they don't mean OSs and drivers, they mean what other people call large scale application systems. What you'd might use Erlang for, for example. Server stuff with high concurrency and big memory/cpu etc needs, but without all the C pain. From stuff like, say, Solr, to Hadoop, to Cassandra, etc, ...

>I can't say as much for every fad-of-the-decade-in-industry thing like Java or Go.

I wouldn't call Go "fad of the decade". For one it's not a fad, as it's not even popular.

>*And as to "fads-of-the-day-in-academia", Scala is the single best language I've ever used. And I don't even use all of it. I just use the subset of Scala that is Everything Java Should Have Been.

Well, I like Scala too. But it lacks some things that Go has, and help me in a few cases: no static binaries. No control over memory alignment. No dead easy FFI to C. No dead simple syntax I can understand in a weekend.

So, see, everything is a compromise.

[eli_gottlieb]

>Is C "fundamentally broken" too?

C was designed and released in, IIRC, 1972. If someone designed and released C in the year 2012 as a new, state-of-the-art systems programming language, I would tear their guts out for releasing something so fundamentally broken, unsafe, obsolete and simplistic!

>people seem to get a lot of work done.

Quite to the contrary, the entire shift to virtual machines and scripting languages happened because people didn't like using C and C++ for application domains where their advantages don't count.