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

Twelve Years of Go

go.dev

Post reply on HN
Print view View original

131–140 of 244 posts

Re: Twelve Years of Go

#131

Post by kisstheblade »

grey-area wrote: post #65

Coming from other languages, the most interesting thing about Go for me (in my limited experience of a few other languages) was all those things they left out: No inheritance - no more digging through the massive world-tree of objects to find the code that actually does things. No churn - I have not seen a Go update break my code in about 8 years of use. No complexity - I like the culture of simplicity and eschewing…

"No inheritance - no more digging through the massive world-tree of objects to find the code that actually does things."

You still have interface methods? I had problems navigating a new codebase and find the places "actually doing things". Some object was passed in somewhere which mysteriously implemented a one method interface defined on the spot in the other go file. I.e. the implementation had no relation to the interface which was obvious without a lot of searching and finding the right implementation.

Also passing in functions (callbacks?) all over the place is a little messy at least for a newbie. It was hard to find where the functions where called and at what point and how the program flowed.

(this is hard to explain but maybe somebody gets the point...)

edit: somebody else touched on what I also meant: " duck typing make refactoring and understanding new codebases error prone"

Also the modules and dependencies management surely is a joke? Pulling stuff from github willy-nilly? Quite bad in any case when compared to maven where you have a local repository with all the dependencies (so they don't change or disappear from the internet so that you can actually build your software 5 years later, exactly in the same way)

Re: Twelve Years of Go

#132

Post by mdaniel »

grey-area wrote: post #65

Coming from other languages, the most interesting thing about Go for me (in my limited experience of a few other languages) was all those things they left out: No inheritance - no more digging through the massive world-tree of objects to find the code that actually does things. No churn - I have not seen a Go update break my code in about 8 years of use. No complexity - I like the culture of simplicity and eschewing…

> No inheritance - no more digging through the massive world-tree of objects to find the code that actually does things.

That's not 100% accurate; as a concrete example, tell me which files (to say nothing of the actual downstream types!) contain the implementations of this interface method: https://github.com/kubecost/cost-model/blob/v1.88.0/pkg/clou... (err, without using github's fancy new SourceGraph-lite integration, of course, that'd be cheating)

I find the sibling "No declared interfaces - they are defined at the point of use, not declared elsewhere" similarly suspicious, but suspect we're having a nomenclature mismatch

Re: Twelve Years of Go

#133

Post by mdaniel »

kisstheblade wrote: post #131
grey-area wrote: post #65

Coming from other languages, the most interesting thing about Go for me (in my limited experience of a few other languages) was all those things they left out: No inheritance - no more digging through the massive world-tree of objects to find the code that actually does things. No churn - I have not seen a Go update break my code in about 8 years of use. No complexity - I like the culture of simplicity and eschewing…

"No inheritance - no more digging through the massive world-tree of objects to find the code that actually does things." You still have interface methods? I had problems navigating a new codebase and find the places "actually doing things". Some object was passed in somewhere which mysteriously implemented a one method interface defined on the spot in the other go file. I.e. the implementation had no relation to the…

Heh, that's amazing, we posted within 30 seconds of each other with basically the same observation. Great minds, and all that :-)

Re: Twelve Years of Go

#134

Post by thatswrong0 »

The_Colonel wrote: post #115
pxue wrote: post #108

Earlier quoted context omitted.

Compressing this into 1 line provides absolutely nothing for the reader, in fact, it absolutely takes away reability.

Readability absolutely suffers when almost everything you see on your screen is boilerplate.

Seriously. I see so many functions in my code see that consist of 1 line of thing I actually care about followed by 3 lines of boilerplate if err not nil… over and over again.

IMO if Go didn’t have its tooling, no one would care about it.

Re: Twelve Years of Go

#135

Post by grumpyprole »

jrockway wrote: post #29

A good twelve years. Go really changed the way I think about programming. I used to be excited by programming language features instead of what problem I was actually trying to solve with programming. I'd spend hours condensing 10 lines of perfectly working code into 1 line of the most concise text possible; huffman encoded better than even gzip could imagine. And I'd feel great about it. I'd imagine people reading i…

I'm happy to entertain the idea that Go is a sweet spot for many, but please let's not pretend language features are universally bad. After all, Go benefits enormously from a garbage collector and its language-level support for Hoare's CSP. Two very important features that e.g C and C++ do not have (they do however have structs, for loops and if statements).

IMHO Go certainly chose wisely when it left out many OOP features of questionable value. And perhaps in doing so, it avoided the whole OOP culture, which has produced a lot of over-complicated software and tools. The culture of simplicity in Go is a really good thing and worth defending. However, we should be open to the idea that one or more additional language features might help to further this goal.

Re: Twelve Years of Go

#136

Post by kaba0 »

throwaway894345 wrote: post #61
jrockway wrote: post #29

A good twelve years. Go really changed the way I think about programming. I used to be excited by programming language features instead of what problem I was actually trying to solve with programming. I'd spend hours condensing 10 lines of perfectly working code into 1 line of the most concise text possible; huffman encoded better than even gzip could imagine. And I'd feel great about it. I'd imagine people reading i…

Agreed. It still surprises me that so many other languages fail at the fundamentals (minimal learning curve, static binaries, fast builds, reproducible dependency management, great tooling, great stdlib + ecosystem, etc) and yet many devotees of those languages have positively hyperventilated about Go's error handling and type system for 12 years. Go is finally getting generics and I'm sort of cautiously excited abou…

I’m not arguing that there are languages where the state of tooling is bad to say the least, but how did Go raise the bar compared to something like Java or C#, the actual “blue-collar” languages?

Re: Twelve Years of Go

#137

Post by grey-area »

mdaniel wrote: post #132
grey-area wrote: post #65

Coming from other languages, the most interesting thing about Go for me (in my limited experience of a few other languages) was all those things they left out: No inheritance - no more digging through the massive world-tree of objects to find the code that actually does things. No churn - I have not seen a Go update break my code in about 8 years of use. No complexity - I like the culture of simplicity and eschewing…

> No inheritance - no more digging through the massive world-tree of objects to find the code that actually does things. That's not 100% accurate; as a concrete example, tell me which files (to say nothing of the actual downstream types!) contain the implementations of this interface method: https://github.com/kubecost/cost-model/blob/v1.88.0/pkg/clou... (err, without using github's fancy new SourceGraph-lite integra…

> That's not 100% accurate; as a concrete example, contain the implementations of this interface method

But why? I've often wanted to know what a method does in Ruby and have had to resort to .method(:x).source_location because it is so dynamic only the compiler knows once it has finished running it. I've never had to find all the places that conform to an interface in Go (a very different question) or Java, because that's what an interface is for, so that you don't need to know, and new people can come along and conform too: your interest should be limited to what they can do, which the interface tells you already. Maybe this is a problem in getting to know a large complex codebase I guess? I've never encountered it in the real world.

The second point is linked - interfaces are used the way you describe in a few other languages, Java among them, (find me all the implementors of x), but not in Go, the whole point is you have no idea who the implementors of an interface are, new ones will arrive, and that's ok.

It's certainly possible to write bad, confusing and enterprise Java flavoured code in Go, but the lack of inheritance at least does away with a whole bag of hurts related to overabstraction.

Re: Twelve Years of Go

#138

Post by kaba0 »

jerf wrote: post #101
leoc wrote: post #50

Earlier quoted context omitted.

If you think there's some virtue in writing verbose and inexpressive imperative code, what does Go provide in that department that you couldn't have got from Java 1.44?

I have often thought that if you could travel back in time and make Java's interfaces work like Go, there would be no Go today. The first-order effects of that change may not seem like much, but the second-order effects of that change is profound. In Java, interfaces must temporally precede their implementations; in Go they don't have to. This turns out to be huge in practice. It turns out that huge swathes of all th…

Java’s nominal typing is both better and worse at the same time - but go is not novel in that area, plenty of similar languages existed before as well, so I don’t think having it contributed to go’s success.

As for your last paragraph, I feel like we often mean something different between a production-level go and java project. Non-IDE java development is entirely possible, but I think a prod project usually means something much larger than it does in case of go.

Re: Twelve Years of Go

#139

Post by kaba0 »

initplus wrote: post #116
leoc wrote: post #50

Earlier quoted context omitted.

If you think there's some virtue in writing verbose and inexpressive imperative code, what does Go provide in that department that you couldn't have got from Java 1.44?

Go is constantly being improved and refined compared to Java 1.44, there is a strong community of third party packages, you aren't shoehorned into the OOP box by basic language design, you get green threads in the form of goroutines while in Java land you are dealing with native threads & the issues they involve (curiously just learned Java <1.3 actually did use green threads, I suppose they were a casualty in the ef…

Comparing a moving thing to a static one is quite meaningless, but regarding third-party packages the JVM is parallel only to the python and node ecosystems.

Re: Twelve Years of Go

#140

Post by ohCh6zos »

kisstheblade wrote: post #131
grey-area wrote: post #65

Coming from other languages, the most interesting thing about Go for me (in my limited experience of a few other languages) was all those things they left out: No inheritance - no more digging through the massive world-tree of objects to find the code that actually does things. No churn - I have not seen a Go update break my code in about 8 years of use. No complexity - I like the culture of simplicity and eschewing…

"No inheritance - no more digging through the massive world-tree of objects to find the code that actually does things." You still have interface methods? I had problems navigating a new codebase and find the places "actually doing things". Some object was passed in somewhere which mysteriously implemented a one method interface defined on the spot in the other go file. I.e. the implementation had no relation to the…

I really do think Go has a discovery problem. Function signatures don’t tell you hardly anything, does this need something deferred, what types does it implement, etc.
Post reply on HN