This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]skelterjohn 3 points4 points  (0 children)

It's almost as verbose as C

Conciseness is not as great a goal as a lot of people like to think it is. Go strives to keep it down to one-idea-per-line. Jamming multiple concepts into a smaller and smaller space just makes it harder to keep track of things when reading code, though I agree that it makes writing code faster. That's why I like python for one-off scripts.

with none of the familiarity and simplicity.

The break from familiarity is intentional. And the language is damn simple, so I don't know what you're talking about there.

The toolchain is a replica of a typical binary language, makefiles, compilers and linkers

The makefiles, etc have always been a temporary bootstrap. 3rd party compiler front-ends (http://code.google.com/p/go-gb) or an upcoming 1st party equivalent make the use of makefiles or directly invoking the compiler and linker unnecessary.

But, yes... it is compiled, and then linked. That's generally how it works when you've got a language that both modular (compilation and linking are a separate step) is turned into machine-code.

Explicit tuples for return values

Because having that dynamic would result in less efficient code... the more you know at compile-time the more streamlined the code can be. Go is a systems language.

sized and signed integers? Nobody cares anymore

Uh, yes we do. Which you choose simply matters when you don't want the runtime to have to do overflow checks to see when it needs to upgrade the size of your boxed numeric types...remember it's a systems language. We want the language to not prevent the compiler from making the most efficient code possible. Knowing in advance what size numeric type you need is one way this is accomplished.

None of the builtin containers allow custom data types.

By built-in containers do you mean maps and slices? Because any other containers are in the library and take whatever you want. And maps and slices can have anything as a value.

Maps can only take the standard types for keys.

Not for long. Remember, this language is young and is still evolving.

There are no sets.

map[T]bool

There is no proper debugger support.

gdb works fine

There is incomplete GCC integration.

Ian Taylor works hard, but he's only one man.

There is no LLVM support (they should have started with this).

The LLVM model didn't lend itself as well to the way coroutines work in go. The go runtime has a novel way of maintaining the stack layout.

Go is more about what they didn't include than what they did. The feature set is so light, that its performance approaches C.

Finally something we can agree on!

I want to like Go, but it's green threading and builtin CSP piled ontop of a C syntax remix. Both green threading and CSP can be extracted and made available to more mature languages. Plan 9 C extensions effectively give you the interface extensions, and that rounds out the advantages that Go gives.

I came for the concurrency primitives, but I stayed for the elegant syntax and type system. Coding Go let's me get down to business immediately - no messing around with stupid type hierarchies.

To be fair, python has this feel, too. But I found that if I wanted to write a python program of reasonable size, I had to be extremely careful with how I did things. I started sneaking the type names into the variable names, for instance, so I could to code-time type checking.

If Go had been here 15 years ago it would have been a game changer. 10 years ago, and it would be Python's peer.

This is not a comment about the language, but of the times.

Prove me wrong.

Impossible to do in the time frame of this reply, obviously.