| > 1. It is possible to have both dynamic-like syntax and static safety
IHMO: This convenience causes more harm than good in the long term.
Note:
My experience is that this is a minefield of bugs and defeats the point of type safety. Also, because Go lacks generics, there's a lot of boiler plate and interface being used as function argument (just check large open source repos on github and you will notice). > 2. It’s better to compose than inherit
IHMO: It's better to have both tools available.
Note:
Inheritance, like static types, offer a more rigid structure and helps on large project that will exist in the long term. In a language that does not offer something like traits, "composition of behavior" ends up being a hack. Of course, we also have the tendency of blaming the language for the fault of the programmers. I would think the example of the Vehicle is not the best to explain the paradigm of behavior composition. > 3. Channels and goroutines are powerful way to solve problems involving concurrency
IHMO: Powerful, yes. But I would use actors instead.
Note:
Same problem: as your business problem gets complex, goroutines start to become a pain and the code will become unreadable and littered with hacks. > 4. Don’t communicate by sharing memory, share memory by communicating.
I read other comments here that express what I think better than I can articulate
Note: You still have to "synchronize" if you are working with shared resources. There's no magic solution. > 5. There is nothing exceptional in exceptions
Oh, Boy! This causes more wars than "space vs tab".
IMHO: Good in theory. Too rigid in practice.
Note:
While works for small stuff, the the lack of exceptions becomes a problem in large projects, causing people to just ignore "for now" (and usually, forever). In conclusion:
The "cool features" of Go might teach some people about programming, but take a toll on more complex projects. I would use Go for small system utilities and tools but would never touch business logic with it. |
> 1. On a daily basis I work in a 200k LOC Ruby project and to me from that perspective lack of static typing is a minefield ;)
> 2. Since I have finally learned how to do proper composition (~a year ago) I haven't use the inheritance even once. Of course, you may say that my project is special, but I can't help feeling that inheritance is often overused.
> 3. Yes, I've also come across opinions that Go's channels are too low level to be used in a large commercial project. But still, as a concept I find them interesting.
> 4. True. But, you can have one goroutine that'll just "guard" that resource and communicate with it from many places using one shared channel.
> 5. TBH I've seen more flame wars about the "space vs tab" thing ;) As I mentioned in the article I don't think that's the best error handling pattern ever invented, but I just like the concept of treating errors as regular return values. IMO it's good to have it at the back of your head, regardless of the language you use.