231–240 of 330 posts
this: > Go won’t let you abstract yourself in the foot. aside from being amusing -- I like this, but can anyone confirm its true in practice with Go?
Is there any "best practice" Go, especially in terms of architecturing apps? I come from a long php background, and spent the past 3 weeks learning and prototyping a Go project. Looking at my code, I definitely have "open source stage fright". Any links/advice/books appreciated.
The best Go code uses built-in types and small interfaces in its APIs. Use interface{} as a last resort, and then only if your function can really take anything. Don't overuse channels. Sometimes a mutex is more appropriate, and that's ok. Rarely use reflect. Don't panic except during package init. Never ignore errors. Don't try to make your Go code conform to the way other languages work. Magic is bad, don't try to make your code magical.
The go community is quite nice in general (there are bad apples in any group). Show off your code, it's the only way to learn, and chances are you'll get some good review comments at least.
Earlier quoted context omitted.
I think people who use Go in the first place are not those who think much about "can this be done in a better way?". It's quite similar to the notion of "I'm a PHP developer and I don't understand why everyone says it is terribly designed! I learned to work with it and never tried anything else, so it can't be that bad!!!". Not every developer cares about software development. There are plenty of people who chose thi…
Your argument seems to rely on go being the first language someone has learned. Very few people learn go as a first language. Most people I know in the Go community have 10+ years of professional development experience in a variety of the popular imperative languages and have used go for a couple years. I'm sure there are probably some people learning go as a first language by now, but I doubt it's a significant numb…
(For many jobs one year of experience is perfectly fine!)
I think people who can think critically and evaluate various options rarely join personality cults, which kind of explains Go's current community.
Earlier quoted context omitted.
The way I read it, he meant that Go is not a great language. Go is "boring" as a language. However, it actually is a great programming tool. Great as defined by how long it takes to write module X, how well module X performs, how many bugs are in X, and how easy it is for a different programmer to come along and work on X later. In a real sense, the very design that makes Go boring is responsible for the good things.
This is an awesome point. I feel like programmers using Go care less about the language and more about the process of creating and maintaining a product .
I don't think either is true. What I do think is true is that every language makes trade offs and golang makes me less productive with it's choices & restrictions. I'm reserving judgement about how it impacts my teams aggregate productivity.
Earlier quoted context omitted.
Why do exceptions interact badly with RAII?
You have to think carefully about how to clean up your object if something throws during its constructor, and throwing an exception in a destructor can lead to your program aborting if that destructor was called as a result of another exception being thrown. Note that I don't think banning exceptions is really the answer; in particular, the destructor issue is just a specific case of "handling errors during finalizat…
Go certainly doesn't succeed because of smug/boring articles like this one. The potshot at Erlang early on (also cf. slurs on Rust and Haskell in some of these comments) betrays the same old "we like it here in our cave" bias of Go boosters whenever confronted with its glaring warts.
Go is a great choice for certain workloads, is reasonably fun to code in, and has great doc support on the web. I suspect however it's popular also because it isn't FP and doesn't favor immutability. It plays well with the haters who refuse to understand how good GC/list fusion/stronger types/better abstraction can make code easier to understand and way faster.
But the bottom line is no Google, no Go. Just like no Sun, no Java. It's simply unbeatable to have a mega tech corp paying folks to write docs libs and patches. But it doesn't save it from being yet another turing tarpit.
Go succeeds because Google's behind it. Go certainly doesn't succeed because of smug/boring articles like this one. The potshot at Erlang early on (also cf. slurs on Rust and Haskell in some of these comments) betrays the same old "we like it here in our cave" bias of Go boosters whenever confronted with its glaring warts. Go is a great choice for certain workloads, is reasonably fun to code in, and has great doc sup…
Earlier quoted context omitted.
I find it incredibly primitive, well past the point of "stupid code is impossible to misunderstand" and into "stupid code because the language demands it." Since the parent mentioned C and Java. What are you missing in Go compared to Java besides generics? What are you missing in Go compared to C besides manual memory management? To me, Go seems to have about the same amount of expressiveness as C and Java. The diffe…
> Since the parent mentioned C and Java. What are you missing in Go compared to Java besides generics? That's a clever way to attempt to constrain the conversation away from the elephant in the room. "Other than the bullet in your stomach, how are you feeling?" Not having at least Java-style "dumb" generics, in 2015, is unacceptable; the existence of `go generate` should mortify everybody involved with Go. Not having…