|
|
|
|
|
by aingisni_del
1734 days ago
|
|
This is great. I too enjoy working with Go coming from a Swift, Obj-C, Java and C# background. The problem that the latter 4 languages have is keyword bloat. For example, Swift has 23 keywords just for declarations (Source: https://docs.swift.org/swift-book/ReferenceManual/LexicalStr...) The entire Go language has 25 keywords. That's it. That includes declarations, control, errors and multithreading. Language design of the latter 4 along with this keyword bloat make for unfettered methods of writing code. Want a simple HTTP request to process JSON? You can open a Go file from the last 5+ years and expect that to look exactly the same. Try doing that in the other languages, and you will find every possible combination of the same thing. Generics has so much indirection and emphasis placed on re-usability, that readability for debugging and understanding become exponentially difficult. In fact, almost every use of generics ultimately ends in type erasure or forced casting. And let's be honest: every generic has to conform to a super generic or protocol, so it's not really as generic as you thought it was going to be. Highly opinionated, reverse compatibility and the lack of generics make Go extremely powerful for it's purpose. Type safety make for easy refactoring, and when refactoring needs to take place, your code is forced to follow the conventions laid out in idiomatic Go: https://golang.org/doc/effective_go |
|
I don't understand. What do you mean?
> almost every use of generics ultimately ends in type erasure or forced casting
Again, not understanding. Would you mind giving an example of this?