[kajecounterhack]

  It's certainly better than C and most dynamic languages, 
  but that's not setting the bar very high.

I'm not sure I agree with that sentiment; C and dynamic languages are used in important applications and being better than them for the same tasks does seem to be a design goal of go. I personally feel that it accomplishes this in a number of areas.

  It is easy to pick up, understand, and use.

This is true and I think it's a huge benefit.

  But it is also very error prone, because its type system 
  is poorly suited for proper error handling, nulls and 
  generic code

That's your opinion. It's less safe than rust, more safe than python. I think it has a rather large niche. I personally like interfaces and that idiomatic golang testing uses language primitives.

It's weird to me that people compare Go and Rust, they're languages with very different motivations.

[glennsl]

> C and dynamic languages are used in important applications and being better than them for the same tasks does seem to be a design goal of go

C is essentially popular because it's popular. And it therefore has a huge ecosystem, can run on pretty much anything and has tons of code already written. That's a huge benefit, and one that Go does not have because it hasn't existed as the dominant language for 45 years yet.

Popular dynamic languages have the benefit of being toys with the bare minimum of features needed to scale beyond toy programs. You can build a house with legos too. It won't be a good house, and it won't be very cost-effective, but it's certainly possible.

> That's your opinion.

No, it's not just my opinion. A well-designed type system eliminates the possibility of you making certain types of very common errors. It will refuse to allow you, and it will sometimes even help you understand why, and what you should have done instead.

The complexity of Rust comes mostly from how the type system has been designed to handle manual memory management. If you take that part out and replace it with garbage collection, you'll get a language that is both safe and easy to learn and understand. Not quite as safe as Rust, and not quite as simple as Go, but very close in both regards. Languages like this do exist. See Kotlin and Swift, for example.

> It's weird to me that people compare Go and Rust, they're languages with very different motivations.

In this we agree. And I'm not arguing for Rust as a substitute for Go. But I am arguing for ignoring a language that ignores much of what the rest of us have learnt about type systems and programming languages during the past half a century (in real years, not tech years).

[smitherfield]

Swift isn't garbage collected. (Allocation and deallocation code is handled by the compiler).

[steveklabnik]

Depending on who you talk to, reference counting is garbage collection. Industry tends to mean "tracing GC" when they say GC, academia tends to mean "all runtime automatic memory management schemes".

[smitherfield]

I might be totally off-base, since unlike you I have no background in compilers, language runtimes etc, but I was under the impression that Swift's ARC is compile-time, which would make it not GC'ed by either of your definitions, whereas runtime ARC, like PHP's implementation, would fit the second.

[steveklabnik]

It's all good! This is a very subtle difference.

So, imagine an interface to a reference counted thing. You have two methods:

  rc.add()
  rc.subtract()

Add bumps the count, subtract drops the count down. When the count hits zero, the thing is deallocated.

What Swift's _automatic_ reference counting is insert the calls to add/subtract _for you_, so that you don't need to do it. But fundamentally, they're still there. So the decision of "when does this get deallocated" is still a runtime thing, even though those calls are compiler inserted.

Does that make sense? Here's another reference: http://stackoverflow.com/questions/6385212/how-does-the-new-...

[smitherfield]

Thanks for the info, and for the very clear explanation!

Obviously, even in C the memory management is a high-level runtime abstraction of sorts (neither the programmer nor the compiler is choosing the actual addresses in memory to alloc/dealloc), so at what point on the continuum of C++-style RAII, Obj-C RC, Swift ARC and so on would you say "garbage collection" comes into play? Is it just one of those "I know it when I see it" type things?