Inheritance and Generics: How's the discussion for Golang 2 going? Do we get _some_ code reuse mechanism? Macros? Anything?
A Farewell to Go
41–50 of 85 posts
Re: A Farewell to Go
#42Did the author even learn Go? Gofmt is for consistency for all devs to be on the same page, the format and structure is part of the language. Are they complaining about the inheritance and generics, again did they learn Go? Stop thinking in about other languages when you are writing Go code, think the Go way.
What is the Go way to implement a generic data structure that can't be trivially realised by wrapping a couple maps and arrays into a struct (without using interface{} and throwing away the safety Go's type system, such as it is, provides)?
You first reconsider your need to make a generic data structure and evaluate on a case by case basis.
Re: A Farewell to Go
#43Earlier quoted context omitted.
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…
Aha, yes, I see now.
Re: A Farewell to Go
#44According to my opinion, a programming language should let a developer use his or her style. gofmt is the best part of Go. Everybody's code looks the same. Broken Package Management This is a solved problem with dep. Switch your Go projects to dep today. In the documentation there is no mentioning of those missing things, you expect from a modern HTTP library. Go's philosophy is "less is more." This is the journey of…
Spot on.
Hopefully someday they build a monument to K&R with "less is more" written on it. As someone currently stuck in a Scala project, I'd donate a sizeable sum towards that goal.
Re: A Farewell to Go
#45I disagree with the authors feelings on code formatting. Gofmt is one of the best features of Go, especially when reading others code.
Indeed, forget goroutines and channels. The most innovative thing Go brings to programming is gofmt. Between that and the simplicity of the language, it makes it so easy to dive into large foreign code bases and actually understand what you're reading. That's one of Go's strengths.
This is, IMO, one of the things that makes Go exceptionally well suited to enterprise development: software tends to pass around multiple different teams with widely varying skillsets, and tends to have a surprisingly long shelf-life.
A simple language with enforced formatting means the code that I wrote several years ago looks much like the code I'd write today. Vendoring dependencies means I can ensure my environment works today as it worked when the application was being developed, and I don't need to go hunting for old dependencies that may not be there anymore. Lots of batteries included in a standard library that has a strong backwards-compatibility pledge means I often don't need libraries.
I've never worked with Go outside of an enterprise; I wonder if these pieces are maddening there.
Re: A Farewell to Go
#46Earlier quoted context omitted.
What is the Go way to implement a generic data structure that can't be trivially realised by wrapping a couple maps and arrays into a struct (without using interface{} and throwing away the safety Go's type system, such as it is, provides)?
You first reconsider your need to make a generic data structure and evaluate on a case by case basis.
Mhm, sure, I can go back a couple decades for the sake of argument.
Say I can make do with instances of my data structure for, I don't know, int8, int16, and strings.
Re: A Farewell to Go
#47I disagree with the authors feelings on code formatting. Gofmt is one of the best features of Go, especially when reading others code.
I can agree with gofmt being great, but I can't agree that a simple newline before a brace should be treated as a syntax error. You're forced to use Google's coding style, whether you like it or not. Preferred coding style is subjective, and Go ignores the fact that not everyone works for Google.
Re: A Farewell to Go
#48Earlier quoted context omitted.
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.
Go permits struct fields to be public. Ergo, Go doesn't care about enforcing the notion that field access violates encapsulation. It is up to the programmer to decide what is being encapsulated.
Re: A Farewell to Go
#49According to my opinion, a programming language should let a developer use his or her style. gofmt is the best part of Go. Everybody's code looks the same. Broken Package Management This is a solved problem with dep. Switch your Go projects to dep today. In the documentation there is no mentioning of those missing things, you expect from a modern HTTP library. Go's philosophy is "less is more." This is the journey of…
This is a solved problem with dep. Switch your Go projects to dep today.
This never works correctly for me and I have no idea why. I haven't written enough Go lately to get this sorted – but it's definitely not quite so obvious.
This is the journey of every Go programmer:*
There are steps after that though:
Oh, I guess I have to copy that code from before. No big deal.
Oh, right. I have to copy it again, with some changes? I guess that's okay.
Wait, did I fix this bug in the other copies too?
fire and burning pain.Re: A Farewell to Go
#50Earlier quoted context omitted.
> 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 lea…
> There's really no need for such a personal attack here - why do you feel a need to lash out at this author? the whole blog post is lashing out at something. You reap what you sow. There's no "these are the tradeoffs, and this is why I disagree with those tradeoffs"; every argument goes like this: - I have an expectation - that expectation is informed by my priors, not by Go - Go didn't meet my expectations - even t…
I don't think that's fair. More – "Go suggested I think in a different way, then I did it and it still wasn't good like it was advertised, and now I'm going"