Live data from Hacker News

Go: Ten years and climbing

commandcenter.blogspot.com

61–70 of 193 posts

Re: Go: Ten years and climbing

#61
post #53

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…

> 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…

The article is scant on details as to what exactly it was about Golang that propelled these companies to stardom, if it even did that at all. Do not mix causation with correlation, though this goes both ways and I maybe wrong in doubting Golang.

Re: Go: Ten years and climbing

#62

Earlier quoted context omitted.

Developers may not need the sophistication that you describing. In that case it's just wasted effort learning something that is more complicated. Are Docker and InfluxDB simple apps? What do you consider simple and what do you consider complex?

> Are Docker and InfluxDB simple apps? What do you consider simple and what do you consider complex? Docker and InfluxDB are investor funded organizations that contribute to open source. I'd argue that their success has more to do with the monetary input than anything to do with the language itself.

That's alright. But are Docker and InfluxDB simple apps or complex apps in your opinion?

Re: Go: Ten years and climbing

#63
post #56

Earlier quoted context omitted.

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.

Oh I'm not disagreeing there. I prefer not being a soldier altogether though. There's a reason I didn't go into the military. I'd also suggest that an army of experienced devs is more effective than an army of non-experienced "toddlers". Programming languages and CS fundamentals aren't elite, impenetrable cliques; they can be learned.

They aren't elite, but the latter are already overemphasized and have very little to do with writing quality code or engineering, with some few exceptions.

And the choice of language is incidental for the most part as well.

Re: Go: Ten years and climbing

#64
post #53

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…

> 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…

> How do you address its popularity in the field of cloud computing then (which I presume you would agree is pretty complex)?

Go was simply the first language to successfully target the niche of imperative, natively compiled, GCed languages. It wasn't the first language of this kind, but the first to have a reasonable amount of adoption/backing. Whatever other flaws it has or had were trumped by the lack of serious competition in this area.

Re: Go: Ten years and climbing

#65
post #45
post #33

> Today, Go is the language of the cloud [...] Is that true? First time I hear of a dominance of Go in the cloud. (And what does it mean anyway -- any distributed app that runs on the cloud, or cloud infrastructure... such as?)

> Is that true? First time I hear of a dominance of Go in the cloud. (And what does it mean anyway -- any distributed app that runs on the cloud, or cloud infrastructure... such as?) It isn't. It's like saying Ruby dominates the VM space because Vagrant uses Ruby. Sure there are a lot of orchestration tools written in Go, but look at the actual apps running in the cloud, how many efficient RDBMS written in Go widely…

But you could argue ruby dominates the DSL space, which is effectively what Vagrant is. A DSL around creating VMs. Same for chef and puppet , but more so.

Re: Go: Ten years and climbing

#66
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?

We've asked you before not to conduct programming language flamewars on HN. If you keep doing it, we're going to have to ban you. We're looking for thoughtful discussion, not stale sniping.

Re: Go: Ten years and climbing

#67
post #60

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…

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.

Re: Go: Ten years and climbing

#68
post #60

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…

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.

I don't use go, but it doesn't really seem like CRUD apps are the sweet spot for it. When I think of go, I think of system software, that 10 years ago would have been written in C. I don't think of it as replacing Rails.

Re: Go: Ten years and climbing

#69
post #53

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…

> 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 like Python or Ruby or Java.

I think this works out great for cloud computing, where performance is a major requirement, but the technology is expanding rapidly enough that a step up from C or C++ is very necessary.

A lot of the complaints I hear are related to abstractions, too, and I understand those to an extent. I also think that if you're complaining about the lack of generics, maybe you're not thinking about interfaces correctly. A perfect example is the beautiful simplicity that is the [`io.Reader`](https://medium.com/@matryer/golang-advent-calendar-day-seven...).

So, whenever someone says something like the OP:

> 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.

I take that as meaning, "I've never seriously used Go beyond writing a hello world app. It doesn't have the features I rely on to be productive, therefore I don't think it's a capable language for larger projects."

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

Re: Go: Ten years and climbing

#70

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…

Go's HTTP server handles each request in its own goroutine, and any panics encountered are automatically recovered from. Nothing special needs to be done to prevent a panic from taking down the server.
Post reply on HN