Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go: Ten years and climbing

commandcenter.blogspot.com

Post reply on HN
Print view View original

71–80 of 193 posts

Re: Go: Ten years and climbing

#71

Post by trgv »

Karrot_Kream wrote: post #29

Having dealt with enough spaghetti code over the years (just a few of industry experience, and some more years of academia), I understand what Go's strengths are. It's an opinionated language that stops users from being too clever or writing code that's too complex. That said, I've always hated the trends that have brought Golang into popularity. The engineers I've felt who could benefit from Golang the most could al…

> I'm a much bigger proponent of languages such as Rust or Haskell which give the developer the _tools_ to ensure their own data integrity, but I guess that says something about me as a developer and why I don't like Golang.

This is a little smarmy, don't you think?

You seem to come ever-so-close to hinting something like "Go isn't fit for writing real applications." Without getting into what exactly a "real application" is, I'll just say I think this suggestion is wrong, unhelpful, elitist, and just generally irritating.

Re: Go: Ten years and climbing

#72

Post by pbohun »

christophilus wrote: post #67
pbohun wrote: post #60

Earlier quoted context omitted.

Here's an example I wrote up for to/from json: https://gist.github.com/anonymous/8487446a2fd908910c66a2aafb... Admittedly, mapping objects to/from database entries is a bit more complicated. There are several ORMs out there or you can role your own.

Yeah. The repeating the field, only camelCased, in JSON annotations feels needlessly painful to me. Subjective, I know, but that kind of painfulness seems pervasive in my (brief) dabbling with Go, and is one of the main reasons I moved on.

The json annotation is optional, but very powerful since it allows you to set the mapped name of the field to any name you like, allowing you to map json fields with snake_case, CamelCase, kebab-case, etc.

Re: Go: Ten years and climbing

#73

Post by hactually »

kmicklas wrote: post #11
pmarreck wrote: post #9

Earlier quoted context omitted.

a developer who hasn’t heard of Go must live under some special kind of rock

Hopefully it's a very good kind of rock where there are no bad languages like Go.

what makes it a bad language? have you written much in it? what didn't you like/couldn't you do?

Re: Go: Ten years and climbing

#74

Post by hactually »

kmicklas wrote: post #13
yumaikas wrote: post #8

I've been using Go on the side since mid-late 2013, so not nearly as long as some here, but I was heavily impressed by both Goroutines and channels as ideas, and by the net/http library. The general portability and simplicity of the language has made it nice for side-project work. I've since used go to write a blog engine, several APIs for school projects, and have been working on a scripting language (pisc.junglecod…

> but I was heavily impressed by both Goroutines and channels as ideas You know they didn't invent this right?

goroutines are definitely unique to go.

I'm sure the approach/style has been done before but this implementation is pretty unique to Go.

Re: Go: Ten years and climbing

#75

Post by ovao »

christophilus wrote: post #67
pbohun wrote: post #60

Earlier quoted context omitted.

Here's an example I wrote up for to/from json: https://gist.github.com/anonymous/8487446a2fd908910c66a2aafb... Admittedly, mapping objects to/from database entries is a bit more complicated. There are several ORMs out there or you can role your own.

Yeah. The repeating the field, only camelCased, in JSON annotations feels needlessly painful to me. Subjective, I know, but that kind of painfulness seems pervasive in my (brief) dabbling with Go, and is one of the main reasons I moved on.

One alternative to writing struct tags by hand is to write a little generator code to map the field names from, say, a reference .json, then calling `go generate` as part of your build process.

I've wondered whether a wrapper library could do rule-based field name mapping automatically with Go's reflection facilities (which could be a productivity win), but I haven't really looked at it closely.

Re: Go: Ten years and climbing

#76

Post by zenlikethat »

ubercow wrote: post #42

I love Go for the concurrency and awesome cross platform support, but my biggest complaint about Go is still the forced GOPATH. I know this is super nitpicky, but I like to keep work and personal code completely separate and changing GOPATHs is very frustrating. With the introduction of `vendor` and software like glide and dep tool, you no longer have to store your sources in `$GOPATH/src`. Since dep/glide are also r…

If you're that fussed about it why not go build -i inside your personal repo ?

Or have a GOPATH with two dirs like:

    GOPATH="~/workgo:~/homego"

Re: Go: Ten years and climbing

#77

Post by brownmenace »

christophilus wrote: post #52

I evaluated Go a few months ago for a web project, but it seemed as if there was a lot of manual work involved in mapping objects in and out of a MySQL database and in and out of JSON (basically, 50% of my day-to-day back end work). It just seemed too arduous. The second thing that bothered me was that an edge-case bug in one of my HTTP handlers paniced the app. If that had happened in production while under load, ma…

We use XO (https://github.com/knq/xo) and JSON-To-Go (https://mholt.github.io/json-to-go/)

Re: Go: Ten years and climbing

#78

Post by chi18 »

h8liu wrote: post #56
Karrot_Kream wrote: post #29

Having dealt with enough spaghetti code over the years (just a few of industry experience, and some more years of academia), I understand what Go's strengths are. It's an opinionated language that stops users from being too clever or writing code that's too complex. That said, I've always hated the trends that have brought Golang into popularity. The engineers I've felt who could benefit from Golang the most could al…

an army of "toddler" developers can overthrow a single hero in terms of productivity, and using a "toddler" programming language makes sure that newly joined "toddlers" can understand (and also maintain or upgrade) existing code, so that the army can just keep growing.

> an army of "toddler" developers can overthrow a single hero in terms of productivity

Depends on what you mean by toddler.

Golang devs imo are not toddlers. The point seemed to be that golang devs could just learn to write C, which is valid. So could Rust developers. But if that was the goal, you'd think both groups would only be using C.

When I think of "toddler" developers, I think of interns being hired into a company to write code with no experience working under mid-level developers that also lack experience, and 5 years later you have what is called f-ing hell. I've worked at a company like that before, and know someone that worked in a company that was mostly VB developers. Same concept but without interns.

Re: Go: Ten years and climbing

#79

Post by iainmerrick »

It's funny that the very first thing discussed is the name. "Go" always seemed like a bad idea, being hard to google for -- and while they were employed by Google, no less!

It fits with the love-it-or-hate-it nature of the whole language.

Re: Go: Ten years and climbing

#80

Post by aphextron »

kminehart wrote: post #69
why-el wrote: post #53

Earlier quoted context omitted.

> As a simple language to wire pieces together, Golang is fine, but it really doesn't give you the tools (imo) to be productive for anything more complex than simple apps. It's a great alternative to JS (again imo), but not something I'd like to write. How do you address its popularity in the field of cloud computing then (which I presume you would agree is pretty complex)? This was mentioned in ample detail by Rob i…

I worry that a lot of developers who have been using languages like Java or C# see Go and immediately feel the need to point out that Go doesn't support language features that they've come to rely on, and so they see that as a weakness or a flaw. With Go, you're getting a lot of high-level language features like anonymous functions, while also gaining the control that you're not able to get in higher level languages…

>I will say though, dependency management in Go is hell. I wish Go had something like Cargo.

This is the number one thing that has kept me from going full on Go. The killer feature of Node was NPM, not Javascript. Unless Golang comes up with something comparable it will forever remain niche.

Post reply on HN