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

Six years of Go

blog.golang.org

Post reply on HN
Print view View original

91–100 of 327 posts

Re: Six years of Go

#91

Post by tptacek »

kasey_junk wrote: post #17
kris-s wrote: post #12

I picked up the new Go book (gopl.io) and have had a lot of fun going through it. The prevailing feeling of Go is "getting things done". I also write a little Go program every day as practice. If you want a sample of some Go. https://github.com/kris-s/daily-go

> The prevailing feeling of Go is "getting things done". This is a common refrain amongst go proponents and I find it quite distasteful. It either implies those of us who prefer other languages aren't "getting things done" or those who feel productive in Go aren't smart/hard-working/educated/etc enough to "get things done" in other languages. I don't think either is true. I think a more accurate way to look at Go is…

I agree with you, but there is something to the argument; it's just poorly phrased as "getting things done".

gofmt, for instance, is uncontroversial. Taking the decisions about how to format code away from developers and standardizing it is widely seen as a win (a win Python flirts with as well).

Well, there's a lot of other things in Go that have been pre-decided for you, not just the formatting. The net effect is that you don't have to waste time:

* thinking about designing a DSL for your programming problem (DSLs in Go require parsers)

* designing a class hierarchy to express your programming problem

* choosing between event-loops and callbacks or pools of threads

* picking the right associative container library (do I want a red-black tree? a hash table? a trie?) for routine coding problems

These pre-decisions can feel confining, but I think for a lot of developers Go reveals that those decisions were usually a waste of time. When you actually hit a place where you need a red-black tree, it's not that big of a deal in Go to bring one in. You're just not going to do that for your session store or for a simple lookup cache --- which is, I think, what a lot of people who can't stand Go's lack of generics would be doing.

Re: Six years of Go

#92

Post by eterm »

aws_ls wrote: post #64

It was early 2013, when we adopted Go as a default language for all our server side (micro or not) services. Before that we had been using Java for some years. The reason for the move were few: 1) Ambivalence on Java roadmap, in my understanding (gradual build up, since after the Oracle's Sun acquisition). Even the earlier clean java docs, suffered from Oracle branding efforts. Downloading older versions were confusi…

You based a business decision to switch language on "boredom"?

What size team are you working with, that you were able to switch from Java to Go?

Re: Six years of Go

#93

Post by aws_ls »

eterm wrote: post #92
aws_ls wrote: post #64

It was early 2013, when we adopted Go as a default language for all our server side (micro or not) services. Before that we had been using Java for some years. The reason for the move were few: 1) Ambivalence on Java roadmap, in my understanding (gradual build up, since after the Oracle's Sun acquisition). Even the earlier clean java docs, suffered from Oracle branding efforts. Downloading older versions were confusi…

You based a business decision to switch language on "boredom"? What size team are you working with, that you were able to switch from Java to Go?

Good question. Small team of 2 developers, so I had that kind of luxury, which I am sure is not there when you have larger teams.

Re: Six years of Go

#94

Post by fauigerzigerk »

hahainternet wrote: post #33
chrshawkes wrote: post #32

Earlier quoted context omitted.

Go brings some good things to the table, yes. I've seen it's popularity rise in recent years, but it seems to be rising slowly. There are a ton of companies that can be listed for almost every technology. Node is another technology I would put ahead of Go as far as adoption. Maybe Go will get better, to me, it's too different than a lot of what I see day to day with Java, C#, Python, JavaScript and on and on. The par…

> Go brings some good things to the table, yes. I've seen it's popularity rise in recent years, but it seems to be rising slowly. There are a ton of companies that can be listed for almost every technology. Then name any company using Swift to the level Dropbox uses Go, or retract your claim. Go code looks nothing like C other than general brace styling. I can't decide if you're trolling or just genuinely this ignora…

>Go code looks nothing like C other than general brace styling.

I disagree. The one thing that makes Go code look more like C than other C descendants like Java, C#, JavaScript, Swift and even to some degree C++ is its error handling style. Having a seperate error value is of course a big improvement over C but visually the error checking code following many statements appears a lot like C.

And the second reason is that Go has pointers with a syntax modelled after C.

So in the eyes of the 90% or so developers who have been using mostly Java, JavaScript and C# for 15 or 20 years, Go has to look a lot like C.

Re: Six years of Go

#95

Post by nickbauman »

eterm wrote: post #92
aws_ls wrote: post #64

It was early 2013, when we adopted Go as a default language for all our server side (micro or not) services. Before that we had been using Java for some years. The reason for the move were few: 1) Ambivalence on Java roadmap, in my understanding (gradual build up, since after the Oracle's Sun acquisition). Even the earlier clean java docs, suffered from Oracle branding efforts. Downloading older versions were confusi…

You based a business decision to switch language on "boredom"? What size team are you working with, that you were able to switch from Java to Go?

Yeah odd choice in that Go is a very boring language (and its enthusiasts consider this a feature).

Re: Six years of Go

#96

Post by StevePerkins »

eterm wrote: post #92
aws_ls wrote: post #64

It was early 2013, when we adopted Go as a default language for all our server side (micro or not) services. Before that we had been using Java for some years. The reason for the move were few: 1) Ambivalence on Java roadmap, in my understanding (gradual build up, since after the Oracle's Sun acquisition). Even the earlier clean java docs, suffered from Oracle branding efforts. Downloading older versions were confusi…

You based a business decision to switch language on "boredom"? What size team are you working with, that you were able to switch from Java to Go?

If he were honest, I'm sure the weights for each factor really look like this:

*

*

*

*

*

*

* *

* * * *

* * * * * *

(2) (1) (3) (4) (5) (all others)

Re: Six years of Go

#97

Post by kasey_junk »

tptacek wrote: post #91
kasey_junk wrote: post #17

Earlier quoted context omitted.

> The prevailing feeling of Go is "getting things done". This is a common refrain amongst go proponents and I find it quite distasteful. It either implies those of us who prefer other languages aren't "getting things done" or those who feel productive in Go aren't smart/hard-working/educated/etc enough to "get things done" in other languages. I don't think either is true. I think a more accurate way to look at Go is…

I agree with you, but there is something to the argument; it's just poorly phrased as "getting things done". gofmt, for instance, is uncontroversial. Taking the decisions about how to format code away from developers and standardizing it is widely seen as a win (a win Python flirts with as well). Well, there's a lot of other things in Go that have been pre-decided for you, not just the formatting. The net effect is t…

I think that falls into my use case of "simple". If you don't need to make those kinds of decisions, then by definition your problem set is simple (at least from a business logic point of view, even simple business problems get complex at scale).

The problem, I have with the sentiment (which I grant is largely me over reading into it) is that a lot of the things people think of as noodling or a waste of time, are the central problems in more complex environments. Making sure your program is correct is very important in some environments. Making it easy to express complex domain knowledge as a subset of a programming language is a huge win in some environments.

That isn't a lack of getting things done, thats just more complex logic requirements.

Re: Six years of Go

#99

Post by Niten »

aryehof wrote: post #44
woah wrote: post #36

Earlier quoted context omitted.

It's true though. Go has a small number of language features, and they are only the simplest ones. It can be learned in a day. Other languages like JS, Ruby, and Python have a big fixation on figuring out the prettiest syntax for stuff (JS promises and chaining etc, "Pythonicness", and Ruby's incessant cuteness). In Go, you can't really make things pretty, so you just bang out code.

>> It can be learned in a day. The syntax perhaps. In reality there are a large number of concepts and idioms to learn on the never-ending road to really becoming proficient.

Yes, but there's a kernel of truth there. I wouldn't say I managed to learn Go in a day, but after perhaps six months using it I was much closer to mastering Go than to mastering other languages I'd been using for years. Go's road to proficiency is a shorter one, there's just less stuff to cover.

Take initialization for example: look at all the edge cases belabored in section 8.5 of the C++14 spec, or even the intricacies of initialization in a simpler language like Python. Now contrast this with how much lexical and conceptual space it takes to describe zero initialization in Go's spec: https://golang.org/ref/spec#The_zero_value

As in other areas, Go's approach here has downsides. (Possibly major ones.) But those tend to be conscious design decisions to minimize the total number of concepts and idioms present in the language.

Re: Six years of Go

#100

Post by nickbauman »

codygman wrote: post #63

I wish the gdb support were better or that delve were more stable. I also had some weirdnesses using cgo on osx. Then I went into #go-nuts on freenode, and I got told I was wrong and there was no problem. Back in 2009 #go-nuts seemed to be a much different place. I write Go at work, and I admire many of the same things in Go I admire about Python. I still wish generics were part of the language and will say their exc…

Go's concurrency is limited to the CSP-style and favors share nothing problems. Languages like Clojure can do CSP just fine, but also have powerful language-level support for heterogeneous concurrency problems that are easy to use and easy to understand.
Post reply on HN