71–80 of 85 posts
Earlier quoted context omitted.
That's a glib answer. You end up with a bunch of duplicated code when you do this.
How often do you implement generic data structures in your code? The last time you wrote one was probably in your data structures class.
Earlier quoted context omitted.
> To complain about it so late into a project really speaks poorly to the author. There's really no need for such a personal attack here - why do you feel a need to lash out at this author? It is entirely reasonable to start a project knowing of limitations, and finish that project with a better understanding of how those limitations affect your productivity in the real world. That's what we call experience , and lea…
> There's really no need for such a personal attack here - why do you feel a need to lash out at this author? the whole blog post is lashing out at something. You reap what you sow. There's no "these are the tradeoffs, and this is why I disagree with those tradeoffs"; every argument goes like this: - I have an expectation - that expectation is informed by my priors, not by Go - Go didn't meet my expectations - even t…
Go is a language, attacking Go is not justification for you to attack the author. Replace Go with a rant about Ford trucks and you'll see how silly you are being.
1. Strict Enforcement of the Google Code Guidelines People who are undisciplined typically don't like discipline when they first encounter it. This doesn't restrict "Coding style" like the author suggests. Coding style and code format shouldn't be conflated. 2. Broken Package Management It's not broken; it's intentionally limited. A "vendor" directory is natively supported by Go to account for this; use Glide or simi…
I disagree with the authors feelings on code formatting. Gofmt is one of the best features of Go, especially when reading others code.
I can agree with gofmt being great, but I can't agree that a simple newline before a brace should be treated as a syntax error. You're forced to use Google's coding style, whether you like it or not. Preferred coding style is subjective, and Go ignores the fact that not everyone works for Google.
1. Strict Enforcement of the Google Code Guidelines People who are undisciplined typically don't like discipline when they first encounter it. This doesn't restrict "Coding style" like the author suggests. Coding style and code format shouldn't be conflated. 2. Broken Package Management It's not broken; it's intentionally limited. A "vendor" directory is natively supported by Go to account for this; use Glide or simi…
Except go does have inheritance... basically: https://play.golang.org/p/yDejKzS4EQ
According to my opinion, a programming language should let a developer use his or her style. gofmt is the best part of Go. Everybody's code looks the same. Broken Package Management This is a solved problem with dep. Switch your Go projects to dep today. In the documentation there is no mentioning of those missing things, you expect from a modern HTTP library. Go's philosophy is "less is more." This is the journey of…
This is a solved problem with dep. Switch your Go projects to dep today. This never works correctly for me and I have no idea why. I haven't written enough Go lately to get this sorted – but it's definitely not quite so obvious. This is the journey of every Go programmer:* There are steps after that though: Oh, I guess I have to copy that code from before. No big deal. Oh, right. I have to copy it again, with some ch…
Earlier quoted context omitted.
Except go does have inheritance... basically: https://play.golang.org/p/yDejKzS4EQ
Thinking of that as inheritance is a Bad Idea. That's embedding. It looks like inheritance but really it's sugar for calling B.A.fn()
Actually writing it felt like a true dose of reality after such built-up expectations. It's... ok, I'd say I like it better or at least as much as any other static language, but damn it feels clunky at times. Specially the error handling; the `if err != nil {...}` everywhere is basically built-in verbosity and isn't very expressive.
Earlier quoted context omitted.
The fact that Go is small, has a large community (outside googlers), and has a completely open spec makes it one of the least likely languages to just fade into obscurity. The Go language accomplishes some amazing things so far, and it a pretty decent choice in the systems-programming space. Even if google dropped it, there would almost definitely be another company or group willing to be it's benevolent dictator(s).
Isn't it somewhat problematic to consider Go as being in the systems programming space? A garbage collector seems like a pretty good disqualifying factor for that.