I'm not sure if generics have been left out to appeal to C developers. At least, in the FAQ they explicitly say that they want to keep the language and the runtime simple golang.org/doc/faq#generics
Regarding error checking, I think that having algebraic data types and pattern matching would have been cleaner and safer. Code can still be super fast with them (have a look at Rust).
I haven't had a chance to use the package manager much so I don't have a clear opinion. If I remember correctly, I read that some of the design decision were rooted in Google using a monorepo, which is a different scenario than what you would normally be in.
I think some work is being done on the package management system so this will likely improve in the future
I'm not sure if generics have been left out to appeal to C developers. At least, in the FAQ they explicitly say that they want to keep the language and the runtime simple golang.org/doc/faq#generics
Regarding error checking, I think that having algebraic data types and pattern matching would have been cleaner and safer. Code can still be super fast with them (have a look at Rust).
I haven't had a chance to use the package manager much so I don't have a clear opinion. If I remember correctly, I read that some of the design decision were rooted in Google using a monorepo, which is a different scenario than what you would normally be in.
I think some work is being done on the package management system so this will likely improve in the future
Thanks Mario, I almost forgot about pattern matching for error handling. That would be very nice indeed.
I've read this article and it makes very interesting points: yager.io/programming/go.html