[Animats]

Go has a rather specific purpose. It's intended for writing server-side web systems that will run fast and scale well. Since that's what Google does to make money, that makes sense. The available libraries reflect this - good support for dealing with many network connections at once, no GUI support.

It's not suitable for writing an OS, hard real time, highly generic libraries, or GUI programs. Within its niche, it's far better than the alternative, which is usually C++. Just the fact that it eliminates buffer overflows without running slow is enough to justify it.

There are lots of problems with Go. The concurrency isn't safe. The lack of generics forces overuse of reflection and "interface{}", Go's all-purpose type. The lack of exceptions forces far too many lines of "if err != nil { return err}", (or worse, a goto) which takes 3 lines of text every time. The "defer" mechanism is clunky. Lots of modern bells and whistles, from functional programming to generators, were omitted. Other than the lack of safe concurrency, those things don't cause operational problems in your data center. They just require more typing by the programmers. That's an acceptable cost. It beats spending time in a debugger.

[ansible]

The lack of exceptions forces far too many lines of "if err != nil { return err}", (or worse, a goto) which takes 3 lines of text every time.

If I could go back in time, and discuss one thing with the designers, it would be to fix this.

I'd rather see some kind of Option type (like in Rust) baked deep into the language. Maybe there would be a scheme where you could use these Option types as regular values. The moment you try to use one of them that is actually an error (trying to pass it as an argument to another function without inspecting it first for example), it causes your current function to return an error.

Or something like that. Maybe that's a language design change that isn't going to be worked out in a social media post.

The "defer" mechanism is clunky.

I like defer. Open a file? Defer close it right afterwards in the code. Bam, done! That's nice, and works even if there was a panic deeper in the call stack somewhere.

The idiomatic way to do that in Go, however, can mask errors, like say if Close() returned an error, you might not see it if you just did a 'defer foobar.Close()' Those errors should go somewhere... somehow.

[rakoo]

> The moment you try to use one of them that is actually an error (trying to pass it as an argument to another function without inspecting it first for example), it causes your current function to return an error.

I've seen another way to do it, that works with current Go, in a redis client [1]:

- Function 1 returns rawarg, error where rawarg can be anything

- You want to transform arg into some type, so you create a function that takes a rawarg and an error and returns your type and an error

- In the implementation of your 2nd function, if err != nil, return it directly

This way, as a library user you can just chain your calls without the tedious if err != nil (it will be taken care of in the library).

This might not scale to huge programs, but there certainly is a way to reuse this idea.

[1] https://github.com/garyburd/redigo/blob/master/redis/reply.g...

[ansible]

I'll have to take a look at that. Thanks for the link.

[ansible]

The idiomatic way to do that in Go, however, can mask errors, like say if Close() returned an error, you might not see it if you just did a 'defer foobar.Close()' Those errors should go somewhere... somehow.

You can, of course fix that, by wrapping your Close() in an anonymous function that logs an error if Close() had a problem. But I don't see that often in other people's code, and it is cumbersome. There ought to be a better and more concise way to do this.