Hi Mario, nice analysis, it's a very interesting language indeed!
Could it be that the reason why they decided to part with generics is, other than simplicity, the fact they had to appeal to the large audience of C developers? In its current form it seems like it can be picked up in an afternoon by an experienced C developer, maybe a little more from someone used to dynamic higher level languages.
One thing I do not like about Go (I have very, very, little experience to be honest) is the way they do error checking, all those if err != nil at some point look like a design flaw, even if they make the code super fast. What do you think?
Also the package manager seems very primitive if you compare it to things like pip, yarn or bundler.
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
Hi Mario, nice analysis, it's a very interesting language indeed!
Could it be that the reason why they decided to part with generics is, other than simplicity, the fact they had to appeal to the large audience of C developers? In its current form it seems like it can be picked up in an afternoon by an experienced C developer, maybe a little more from someone used to dynamic higher level languages.
One thing I do not like about Go (I have very, very, little experience to be honest) is the way they do error checking, all those
if err != nilat some point look like a design flaw, even if they make the code super fast. What do you think?Also the package manager seems very primitive if you compare it to things like pip, yarn or bundler.
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