Live data from Hacker News

Go Is a Shop-Built Jig

robnapier.net

41–50 of 110 posts

Re: Go Is a Shop-Built Jig

#41
Lack of generics seems to always be the argument against Go. I have been coding in Go for over a year now nearly every day and it really became an annoyance only once: CRUD operations in a web-service expecting JSON-objects. That's literally the only time where the code-duplication was a problem for me.

Now, not everything else has been all good (mostly minor issues with community libs), but the one thing that never ceases to amaze me with go is that: You hammer out a few hundred lines of code, compile, fix those few syntax errors, compile again and 9 out of 10 times your code just works. The simplicity of the language is the key. It's a tool that feels right and gets the damn job done.

Re: Go Is a Shop-Built Jig

#42

Notice the author would still rather use Swift when he's doing fun stuff. I get this sentiment and more than once I've wished there were more constraints in the language to mitigate the damage some kid with a chip on their shoulder could do but it says something about the psychology of programmers, "I know personally I'm good enough to do magical, wizardly stuff with all the cool stuff that Swift gives me but you, we…

So you're saying you want programming to be hard because that means you get to work with smarter people? I think what Go is striving for is simplicity, not elegance. And that change makes the code easier to write and maintain for everybody involved. At 10AM I might feel like writing Swift, but at 3AM I'm sure as hell glad I used Go. Or, less anecdotally, I maintain about twelve services in Go, including web services,…

When things get serious, I think you'll discover that Go provides far less reliability, and is far more complex. (What's simpler than "it's already handled for you with OTP and battled tested for 2 decades"? That's a lot more simple than "you can't do it in this language and you'll end up with a poorly implemented half version of OTP in Go."

Of course for toy or small services, go is fine. Erlang certainly could use the "build a binary run it anywhere" distribution model of Go tool.

But reading all these pro-go articles, it strikes me that none of them seem to be written by people who really understand concurrency.

Believe me, I wish Go was written by people who had understood erlang. There's a lot to like about it and it has momentum.

Re: Go Is a Shop-Built Jig

#43
post #14

I would switch from python to Go but - Type system needs to be improved e.g. generic code - Verbosity, duplication of code are painful - Lack of functional features - Tooling - Maturity

- Designers of the language forced their where-braces-go religion on everyone by building it into the language.

For me, that means every time I attempt to write code in Go my nose is rubbed in the "this language was built by assholes who have no respect for you".

Re: Go Is a Shop-Built Jig

#44
post #43
post #14

I would switch from python to Go but - Type system needs to be improved e.g. generic code - Verbosity, duplication of code are painful - Lack of functional features - Tooling - Maturity

- Designers of the language forced their where-braces-go religion on everyone by building it into the language. For me, that means every time I attempt to write code in Go my nose is rubbed in the "this language was built by assholes who have no respect for you".

Oh really? I can see that I suppose, but I always found it kind of nice that they enforce a very specific style. It makes it so that all Go code I see is consistent and clear. Same with the way they do documentation.

I guess it does take some of the aesthetic or artistic quality out of it, but in practice it's never bothered me. On the contrary, not having the option removes quite a bit of mental overhead on what (to me) comes down to a fairly religious but ultimately inconsequential viewpoint.

Re: Go Is a Shop-Built Jig

#45
post #39
post #34

Earlier quoted context omitted.

> OS and Android supports are on their way in case you're not following recent developments. Yes, but it remains to be seen how Go's view on data structures map Objective-C and Java APIs. As for Android support, the Android team doesn't seem to care any little bit about it, given their statements on Google IO. So you have developers of a Google language trying to target a Google platform, where the platform owners ju…

The rough shape the Go Java mapping has already been formed: https://godoc.org/code.google.com/p/go.mobile/cmd/gobind

Thanks for pointing this out.

Even though I don't like some of Go's decisions, it would be nice to see it on Android. After all, I created the ticket request on Android Tools.

But the feedback at Google IO from Android's team in this regard was disappointing.

Re: Go Is a Shop-Built Jig

#46

Notice the author would still rather use Swift when he's doing fun stuff. I get this sentiment and more than once I've wished there were more constraints in the language to mitigate the damage some kid with a chip on their shoulder could do but it says something about the psychology of programmers, "I know personally I'm good enough to do magical, wizardly stuff with all the cool stuff that Swift gives me but you, we…

"I know personally I'm good enough to do magical, wizardly stuff"

In my experience really good developers don't see it like that, they see it more like the Brian Kernighan quote:

"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"

It isn't that they are worried that "lesser" programmers will make a mess using "clever" code, but rather they are worried how long it will take them to debug their own "clever" code, or just decipher such code they produced themselves in the future after they haven't looked at it in 6 months.

Re: Go Is a Shop-Built Jig

#47
post #2

Seriously, in good faith, I attempted to learn and write a simple web application in go. I found it hard coming from a world where IDE support was available in other languages that do autocompletion and things like that and development just moves faster. In go, there is some level of support in sublime text, go for vim etc, but it is not nearly as full featured as say, IntelliJ. Want to learn about the javadoc - Comm…

I've tried Go some too. I disagree with your assessment of the data structures (inheritance isn't always great), but the tool thing I strongly agree with.

I'd note that all the replies at this time argue the point about data structures, but none address the tooling.

I want my autocompletetion, dammit! And I don't want to use Emacs or Vi to get it.

The lack of refactoring support was what ended up making me switch back to Java+Dropwizard. I'm just much quicker at evolving services because of the better tooling.

Re: Go Is a Shop-Built Jig

#49

Notice the author would still rather use Swift when he's doing fun stuff. I get this sentiment and more than once I've wished there were more constraints in the language to mitigate the damage some kid with a chip on their shoulder could do but it says something about the psychology of programmers, "I know personally I'm good enough to do magical, wizardly stuff with all the cool stuff that Swift gives me but you, we…

I have a rule when I make project technology decisions:

If we understand the domain and understand what we are building then we can afford to be innovative on the technology. If we are trying to be innovative in what we are building then we need to choose proven (aka boring) technology.

Re: Go Is a Shop-Built Jig

#50
post #14

I would switch from python to Go but - Type system needs to be improved e.g. generic code - Verbosity, duplication of code are painful - Lack of functional features - Tooling - Maturity

Hang on - you are coming from Python and complaining about the lack of generics?

Why? Go types (without generics) are much stronger than in Python aren't they?

Post reply on HN