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

A Farewell to Go

churchwood.at

Post reply on HN
Print view View original

21–30 of 85 posts

Re: A Farewell to Go

#21

Post by djrogers »

setheron wrote: post #10

This was a terribly worded blog post. The problems the author faced with go were so paper thin -- I don't think they warranted claiming "every line of go i've written is now deprecated". It's pretty clear going into go from the initial HelloWorld -- that you are expected to: 1 - use gofmt 2 - won't have inheritance 3 - Drudge your way through a solution for dependency versioning To complain about it so late into a pr…

> To complain about it so late into a project really speaks poorly to the author.

There's really no need for such a personal attack here - why do you feel a need to lash out at this author?

It is entirely reasonable to start a project knowing of limitations, and finish that project with a better understanding of how those limitations affect your productivity in the real world. That's what we call experience, and learning from it is a critical element of personal growth.

Re: A Farewell to Go

#22

Post by cft »

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.

     Go willingly chose to not support this behaviour causing me to write a lot of duplicated code. For example, my SAP analysis web interface uses three different product group structures, as the required amount of details varies between user stories. Go forces me to maintain the same code in three different places.
I think his reference to "duplicated code" means that he has the same data members in different structures, and that he duplicated those members, instead of using structure embedding. He then looked for a solution in interfaces, and naturally did not find it there. If so, he is at a very basic level of Go knowledge. Having dealt with complex Go codebases, I have never seen "code duplication"

Re: A Farewell to Go

#24

Post by beat »

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.

Access to data members violates encapsulation. This is OOP 101. Complaining that a language doesn't allow declaration of data members in an interface declaration (and thus reliable direct access to data members) is basically complaining that the language enforces best practices for a 40 year old programming paradigm.

Re: A Farewell to Go

#25

Post by Qworg »

pmarreck wrote: post #9

http://www.golang.sucks/ is both a better and a more comprehensive critique of Go. Rob Pike's quote about "They’re not capable of understanding a brilliant language" is extremely unfortunate, and a missed opportunity to elevate the art/science of programming and the much larger understanding of information theory in general for all programmers, instead of trying to appeal to the lowest common denominator. My first qu…

"Because many developers have a limited depth of understanding and no desire to increase it" is the pithy but correct answer.

Re: A Farewell to Go

#26

Post by Shywim »

I would agree that go has many flaws, but the formatting and gofmt is not one. I welcome a language that enable me to not care at all about the formatting, and just focus on programming.

- Write a messy formatted code - Run gofmt - Commit

Re: A Farewell to Go

#27

Post by owenmarshall »

adrianlmm wrote: post #23

I almost picked Go for a project, I've read so many complains about it that I feel like I skiped a bulled.

You can find complaints that range all the way from "spot on" to "wildly inaccurate" for any tool.

What project did you have in mind? What specific complaints did you see that made you think "this isn't a good fit"? And what did you pick instead?

Re: A Farewell to Go

#28

Post by 0xCMP »

setheron wrote: post #10

This was a terribly worded blog post. The problems the author faced with go were so paper thin -- I don't think they warranted claiming "every line of go i've written is now deprecated". It's pretty clear going into go from the initial HelloWorld -- that you are expected to: 1 - use gofmt 2 - won't have inheritance 3 - Drudge your way through a solution for dependency versioning To complain about it so late into a pr…

Yes, in go these things have solutions. Maybe not the best ones we can have, but there are ways to approach the problems beyond just giving up.

1 - Most editors automatically support that. I wouldn't say being forced to follow a certain code convention is bad, but it understandable that it may bother some people.

2 - You can still the code-reuse features of inheritance by using embedded structures with methods attached to them.

3 - There are many solutions which solve the problem without needing to commit the vendor directory to git like `glide`.

Re: A Farewell to Go

#29

Post by hardwaresofton »

davidw wrote: post #14

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.

I wonder if the author has gotten a chance to use Java or C++ for any extended period of time. While I don't think Golang is the greatest language ever invented, the trade-offs it offers for the productivity it provides is paramount to me.

I think an appreciation for Go and the choices it makes can only be fully felt once you've spent a significant amount of time in another less expressive/convenient/simple language.

Re: A Farewell to Go

#30

Post by zac123 »

I am not surprised you mention "missing generic". It can be done by using interface. As "no inheritance", you can use encapsulation. As "broken package management", you can use "vendor". Above are all about how to engineer application. There is no only one way to solve it. (if you are from java/C++, I don't think those OOP concepts are the king rules) As of "Google Guidelines", I would judge you just entered the beginning level of software engineering. (You dont know how much pain without those)

In conclusion, I think you blog title is just making horrible attention.

Post reply on HN