Live data from Hacker News

Six years of Go

blog.golang.org

251–260 of 327 posts

Re: Six years of Go

#251
post #227

Earlier quoted context omitted.

How? Its an open source project: https://github.com/golang/go

Google represents what 95%+ of the committers ? If you took those away not to mention the message it would send to everyone would be enough to put the language in a death spiral. Good luck convincing management to use a language that even Google abandoned.

FUD.

- Do all opensource projects require corporate sponsorship to be viable?

- Do Python, Ruby, even Rust have corporate backers that cannot widthdraw support?

- Does Java, being under the control of Oracle, present a better option?

- Many business are using VB, C# and F#, which Microsoft owns. F# especially could be abandoned, but it continues to find new use.

The Go code I write and compile today will continue to work for a significant period of time. If Google stopped paying the committers, this would not change - the language may not evolve, but this is a minor concern on a project of Go's popularity.

Some businesses still rely on COBOL and Fortran, but those are not exactly evolving either.

Re: Six years of Go

#252

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…

What I don't understand is the people who say Go doesn't need generics. Go already has generics: channels, maps, make(), len(), range, etc. are all generic. Nobody can argue that generics in Go isn't extremely useful. After all, you couldn't have typed channels without generics. One has to be pretty obtuse to argue that the utility afforded by Go's internal generics wouldn't extend to the language as a whole; that so…

This is a good summary:

https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX...

Re: Six years of Go

#253

I have a bit of a love-hate relationship going on with Go. On one hand, it addresses many of the pain points I've experienced with other languages. It's easy to build and deploy, reasonably performant, and has a powerful and consistent standard library. On the other… developing in it feels like a total slog. It manages to be simultaneously far too anal and overly forgiving about syntax. Visibility definition using up…

You either "get" Go or you don't. Which shouldn't be surprising given that it is a very opinionated language. A diagnostic indicator is whether you gravitate towards things like Martini or Gin, which aren't idiomatic Go and seem designed to ease the pain of using Go for those who don't actually care for it much.

I see what you're saying, but I absolutely "get" what Go is doing – you're right that I don't care for the idiomatic approach that much!

I have enjoyed the gin API. In maybe 10 lines of code, I can build a fast HTTP service that can serve up a small single-page app. The same thing using e.g. Negroni feels like I'm writing more boilerplate for no apparent gain – and I'm a great opponent of writing boilerplate code.

Re: Six years of Go

#254
post #73

Go is a great language. Building REST servers in Go is a doddle and the related tools have obviously been designed to work well together from the outset which is unusual. That said, I started learning D at about the same time as Go, and for some reason D has attracted me more. Possibly the C ABI compliance (I was doing some JNI work at the time). One question that I haven't found the answer to yet though is how well…

I have been running multiple instances of the same Go app on multiple servers without it ever crashing for about a year. The current uptime (since the last release) is about 4 months, no issues at all, and very low resource usage.

Re: Six years of Go

#255
post #251

Earlier quoted context omitted.

Google represents what 95%+ of the committers ? If you took those away not to mention the message it would send to everyone would be enough to put the language in a death spiral. Good luck convincing management to use a language that even Google abandoned.

FUD. - Do all opensource projects require corporate sponsorship to be viable? - Do Python, Ruby, even Rust have corporate backers that cannot widthdraw support? - Does Java, being under the control of Oracle, present a better option? - Many business are using VB, C# and F#, which Microsoft owns. F# especially could be abandoned, but it continues to find new use. The Go code I write and compile today will continue to…

It is not FUD. It is a factor to consider, especially if you are thinking of creating mission critical software. There is no doubt that Google has plenty of form in killing projects, some of which were quite popular and/or highly visible. After all what percentage of Google income/infrastructure depends on Go? I presume it is really, really tiny and could become a casualty in corporate politics.

I personally think it is highly unlikely that Google would kill Go, but I do think one has to consider the possibility before betting the farm.

Re: Six years of Go

#256
post #227

Earlier quoted context omitted.

On the other had, Google could kill Go tomorrow...

How? Its an open source project: https://github.com/golang/go

Tons of open source projects faltered and died when they lost core contributors. The core will remain open source and available, and you might even see a few commits here and there, but that will be it.

Go for the most part is written by a small team of paid contributors -- it's not certain at all that if they went away, other people would step in their shoes.

Re: Six years of Go

#257

Earlier quoted context omitted.

Please just stop. This is not an objective issue. I for one have spent the last 2 years using Go to build a very performant system which is used by thousands of Bitcoin day traders every day. It's fast, stable, and easy to modify. I have never felt held back by a lack of generics. And yes, I've spent plenty of time using languages that do support generics. It can save you time but I've found it also enables "looser"…

> Please just stop. This is not an objective issue. When it comes to computer science generics have been an accepted part of PL research for decades. The extra expression power they give and the paradigms they enable are neither controversial, not something that's up to individual tastes to judge. Someone might not like them subjectively, but that's not different than someone not liking closures, or map or any other…

It's funny that you mention Java because I have always avoided learning Java. Even from afar it grosses me out as a language. I actually think comparing Go to Java is silly because a lot of motivation behind Go's design came out of avoiding what was done to Java and C++.

The point is, plenty of companies manage to create very good production software with Go, without generics. I didn't mean to rest my argument on my personal anecdote. You can look to Google, CloudFlare, SoundCloud, Dropbox, etc. for reassurance.

If you have a suggestion on how generics would fit into Go, I think the Go team would be happy to read your thoughts: https://groups.google.com/forum/#!forum/golang-nuts.

Re: Six years of Go

#258
post #10

... and still no generics.

It is fairly clear by now that omitting generics is not an oversight, but rather a design choice. If you disagree, it sounds like Go isn't for you. Maybe it's time to just move on and ignore it instead of beating a dead horse. I am always confused by the push to make every language exactly the same by using the same paradigms and features. Some languages try to take a different approach. If you can't figure out how t…

Haskell does support an imperative style, supports it quite well even :)

Re: Six years of Go

#259
post #251

Earlier quoted context omitted.

Google represents what 95%+ of the committers ? If you took those away not to mention the message it would send to everyone would be enough to put the language in a death spiral. Good luck convincing management to use a language that even Google abandoned.

FUD. - Do all opensource projects require corporate sponsorship to be viable? - Do Python, Ruby, even Rust have corporate backers that cannot widthdraw support? - Does Java, being under the control of Oracle, present a better option? - Many business are using VB, C# and F#, which Microsoft owns. F# especially could be abandoned, but it continues to find new use. The Go code I write and compile today will continue to…

>FUD

We're talking about decisions to adopt a language, so FUD and especially "uncertainty" is a very important factor to consider. This is not 1999 and Microsoft badmouthing Linux.

>Do all opensource projects require corporate sponsorship to be viable?

Not all of them, but a lot of them do. Especially languages. Even something like OCamL needs Jane Street and that french university a lot.

Go is not setup as even a 50-50 internal/external community. While the long tail is, well, long, the majority of commits and all of the steering is from Google devs.

>Do Python, Ruby, even Rust have corporate backers that cannot widthdraw support?

Rust has Mozilla and lots of paid programmers (all the core team for one). Without it, it would have gone nowhere.

Python and Ruby had had corporate sponsorship themselves too, but they have been far more organic (grass-roots) open source communities than Go from the start.

>Many business are using VB, C# and F#, which Microsoft owns. F# especially could be abandoned, but it continues to find new use.

Devs/Teams using F# are extremely few and far between compared to any established language such as C#, Java, etc. We're talking probably 2 orders of magnitude or more.

>Some businesses still rely on COBOL and Fortran, but those are not exactly evolving either.

Fortran is still evolving actually. Also Fortran and COBOL have been always mostly based on commercial compilers -- not community efforts, because that's how stuff worked back in the day.

And it's not like people write green projects in COBOL -- they just rely on it because they have huge important codebases that are 40-50 years old.

That's not the case with Go.

Re: Six years of Go

#260

Earlier quoted context omitted.

> Please just stop. This is not an objective issue. When it comes to computer science generics have been an accepted part of PL research for decades. The extra expression power they give and the paradigms they enable are neither controversial, not something that's up to individual tastes to judge. Someone might not like them subjectively, but that's not different than someone not liking closures, or map or any other…

It's funny that you mention Java because I have always avoided learning Java. Even from afar it grosses me out as a language. I actually think comparing Go to Java is silly because a lot of motivation behind Go's design came out of avoiding what was done to Java and C++. The point is, plenty of companies manage to create very good production software with Go, without generics. I didn't mean to rest my argument on my…

>It's funny that you mention Java because I have always avoided learning Java. Even from afar it grosses me out as a language.

May I guess you're either some old Lisp/Smalltalk etc veteran, or, much more probably, someone who entered IT after, say 2005?

Because back in the day very few thought of Java as "gross" -- it was greeted as a welcome change from the existing landscape which at its best was something like C++.

Post reply on HN