[deleted]
Problems with Go's design
11–20 of 88 posts
Re: Problems with Go's design
#12I guess I'm a "a pussy, 9-year old boy or afraid of little bit “strong” writing.", because as soon as I saw that sentence I lost all interest in finishing the post (though it was pretty linkbaitey in the bit I did read so I had marginal interest in the first place).
Shit like that is why we have gender problems in the industry.
Re: Problems with Go's design
#13Earlier quoted context omitted.
Point 4 makes sense though , it would really help with polymorphism in Go ,without generics. This is the kind of subtle behavior that is upsetting at times and I really think this is where the language could improve, definitely.
For every "quirk" mentioned in this article there are very good reasons for it, which the author lacks the imagination or patience to try and reason through. Point 4 is perhaps the best example. So given an interface Foo and a struct FooImpl which implements Foo, why can't we pass a slice of []FooImpls to []Foo? It's because the creators of Go are lazy and arrogant and incompetent and don't care right? No. Consider t…
Sorry to bring up this yet-another-generics-ranty-thing, but actually point 4 is a typical issue that can be nicely solved with generics, by defining a function that works on every type that implements Foo. In this way you can directly pass a slice of Foo to the function and achieve type safety at the same time. As stated by the author, there's a demand for manually constructing an interface-slice in Go, and this shows a good example why generics can be useful.
Re: Problems with Go's design
#14We replaced the baity title with something more neutral, in keeping with the HN guidelines:
Re: Problems with Go's design
#15Earlier quoted context omitted.
For every "quirk" mentioned in this article there are very good reasons for it, which the author lacks the imagination or patience to try and reason through. Point 4 is perhaps the best example. So given an interface Foo and a struct FooImpl which implements Foo, why can't we pass a slice of []FooImpls to []Foo? It's because the creators of Go are lazy and arrogant and incompetent and don't care right? No. Consider t…
Sorry to bring up this yet-another-generics-ranty-thing, but actually point 4 is a typical issue that can be nicely solved with generics, by defining a function that works on every type that implements Foo. In this way you can directly pass a slice of Foo to the function and achieve type safety at the same time. As stated by the author, there's a demand for manually constructing an interface-slice in Go, and this sho…
That's a different criticism. That's the "Go Needs Generics" issue.
I don't disagree with it, but I also agree that there hasn't been any good solutions proposed for generics that meet the requirements that are at the core of Go: namely, performance of the compiled program, performance of the compiler, and performance of the developer.
Re: Problems with Go's design
#16Go is inspired by the C++ subset that Google choose to use (Just look for the Google's C++ style guide to look for things that Google banned). So in many ways, it's chosen to work as C++ in lots of corner cases. In fact, that enabled automatic tool to convert Go compiler written in Google's C++ to Go.
> In fact, that enabled automatic tool to convert Go compiler written in Google's C++ to Go. Hmm, I thought go was written in C at first place and not C++. It seems to me that Go creators were never big fan of C++ so I don't think it takes any inspiration from C++ . All I see in some kind of C + garbage collection + interfaces and some concurrency percs. I fail to see how it was influenced by C++ in any ways.
That's correct, the Go toolchain was originally written in C, and translated from C to Go:
https://golang.org/doc/go1.5#c
And of course Go's designers include some of the designers of C (well, its predecessor B) and Limbo, and Go seems influenced more by that tradition than by C++.
Re: Problems with Go's design
#17"I still wonder why we can omit commas on import/var/const blocks and just can’t on lists and maps. Anyway, Rob Pike knows better than me! Viva la Readability!"
import/var/const blocks rely on semicolon insertion rules, list and map literals have a list of Elements separated by ',' [0]. I guess on the surface level I see how this is sort of inconsistent. It would be interesting to think about applying semicolon insertion to comma insertion.
Re: Problems with Go's design
#18I would add "non-pointer method receivers allow you to modify the receiver object, but silently drop those modifications when the method exits (because they happen on a copy)".
This is similar to the variable shadowing example in the article, in the behavior is the same in C and so kind of makes sense for that reason. However in both cases, Go's syntax makes it very difficult to spot the error (already-declared variables allowed to the left of :=, method calls implicitly taking a pointer to the receiver), where in C it would be more obvious.
Re: Problems with Go's design
#19I actually had a subtle bug caused by variable shadowing. The current behaviour of := is error prone and IMO should be revisited. The situations where it cleans things up are offset by situations where it doesn't work (including in compound statements where it often ends up being I'd like to declare and check err but I also want to be able to use the other variable if err==nil).
Another thing not mentioned is type switches, that feels like something that was duct taped onto the language. I think it would have been better to be able to use .(type) anywhere (e.g. in an if statement) and not have some sort of special switch statement. So make types more of a first class thing. It's obviously more work though but there is probably some middle-ground there that would make it seem less like a hack.
I think the behaviour of slices is reasonable given that they are not as high level as they are in some other languages. They're basically a slightly nicer facade over pointer arithmetic and they are designed for efficiency and performance. I think overall they're fine. The "..." is a little awkward (appends could be a little nicer).
Just use goimports to and you won't see unused import errors any more. Works for me and makes things cleaner.
All in all I think there are some rough corners that could use a little polish but that can still happen, it's a new language after all. It's good enough to be really useful.
Re: Problems with Go's design
#20I'm surprised to see the author mention not being able to compile when there are unused imports. Editor plugins that call goimports have solved this problem for a long time now. For example, I use vim-go (https://github.com/fatih/vim-go), and if I remove the only line of code that references the "fmt" package, the "fmt" import line at the top of the file will automatically be removed.
Edit: Here is the reasoning on the FAQ behind code with unused imports not compiling: https://golang.org/doc/faq#unused_variables_and_imports