A Farewell to Go • Hacker News Board

Re: A Farewell to Go

#11

Post by samuell » Wed, Aug 09, 2017, 4:03 PM UTC

cft wrote: post #4

Interfaces help to solve the problem with methods of objects, but not with data members. I wonder if the author knows about structure embedding in Go at all.

I guess the author meant that interfaces are defined by methods, not data members. Thus, you can't have an interface that describes you should have a member field "Foo", but instead will need to create a "getter" Foo(), for it, if you want it to be part of an interface definition.

Re: A Farewell to Go

#12

Post by roguecoder » Wed, Aug 09, 2017, 4:07 PM UTC

The verbosity of error handling is what frustrates me most. If errors are supported as a first-class citizen, handling them should be too.

I'm still happy to employ it for what it does well, but using it feels a lot like using Java circa 1997.

Re: A Farewell to Go

#13

Post by owenmarshall » Wed, Aug 09, 2017, 4:08 PM UTC

sergiotapia wrote: post #2

Haven't used Go in about a year and change, is Google going to pull an Angular and pull the rug out from under developers for Go 2.0?

One of the major focuses at Gophercon was on Go 2.0 being an _extremely_ incremental process. Go 1 development is planned to continue with backwards-compatible changes being incrementally added, and Russ Cox hoped Go 2.0 would happen when Go 1.n+1 would either:

* have no changes to be made from Go 1.n other than backwards-incompatible ones, or

* would have no backwards-incompatible changes at all.

I get the feeling that the developers have learned a great deal about not making large breaking changes & segmenting the language.

Re: A Farewell to Go

#14

Post by davidw » Wed, Aug 09, 2017, 4:08 PM UTC

He doesn't mention what he's using instead, which doubtless has problems of its own. I'm not much of a Go user, but its community seem fairly forthright about what it does, how, and its tradeoffs. I didn't learn anything by reading this.

Re: A Farewell to Go

#15

Post by spraak » Wed, Aug 09, 2017, 4:09 PM UTC

No new arguments here, and the author doesn't share what they'd rather use instead.

Re: A Farewell to Go

#16

Post by hsnewman » Wed, Aug 09, 2017, 4:09 PM UTC

So everyone is entitled to their own opinion. And one person's opinion is no different than any others.

That said, I absolutely love go and wouldn't consider any other language for my development. I like the strict coding guidelines. Some of the things listed are bugs/issues that can be fixed in later releases (Feature-Lacking HTTP Library & Broken Package Management to be specific).

Re: A Farewell to Go

#17

Post by roguecoder » Wed, Aug 09, 2017, 4:10 PM UTC

scallycat wrote: post #8

sergiotapia wrote: post #2

Haven't used Go in about a year and change, is Google going to pull an Angular and pull the rug out from under developers for Go 2.0?

Go 2 considered harmful?

I now really, really hope that when they originally named the language it was exclusively to set up this pun. Well played, friend, well played.

Re: A Farewell to Go

#18

Post by philosopherlawr » Wed, Aug 09, 2017, 4:10 PM UTC

majormjr wrote: post #3

I disagree with the authors feelings on code formatting. Gofmt is one of the best features of Go, especially when reading others code.

I think this is the thing I want most languages to adopt. As someone responsible for ensuring a team's work can be supported by new developers, gofmt is a life saver.

Re: A Farewell to Go

#19

Post by 0xCMP » Wed, Aug 09, 2017, 4:10 PM UTC

samuell wrote: post #11

cft wrote: post #4

Interfaces help to solve the problem with methods of objects, but not with data members. I wonder if the author knows about structure embedding in Go at all.

I guess the author meant that interfaces are defined by methods, not data members. Thus, you can't have an interface that describes you should have a member field "Foo", but instead will need to create a "getter" Foo(), for it, if you want it to be part of an interface definition.

Yes, that's annoying. Luckily though through embedded structs he could inherit all the methods to access each of those fields in whatever types he creates and make matching some interface easier.

Re: A Farewell to Go

#20

Post by hardwaresofton » Wed, Aug 09, 2017, 4:10 PM UTC

sergiotapia wrote: post #2

Haven't used Go in about a year and change, is Google going to pull an Angular and pull the rug out from under developers for Go 2.0?

The fact that Go is small, has a large community (outside googlers), and has a completely open spec makes it one of the least likely languages to just fade into obscurity.

The Go language accomplishes some amazing things so far, and it a pretty decent choice in the systems-programming space. Even if google dropped it, there would almost definitely be another company or group willing to be it's benevolent dictator(s).