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

161–170 of 244 posts

Re: Twelve Years of Go

#161

Post by grey-area »

kaba0 wrote: post #152
grey-area wrote: post #86

Earlier quoted context omitted.

Your users typically don't want the program to crash, spare a thought for them. Re stack traces, they're fine I guess, but I prefer a well-crafted error message to 200 lines of irrelevant file locations/functions.

That’s the point of exceptions. They bubble up! I can manage them at a place where it is appropriate. Something had happened during the processing of this web request? Catch the exception and convert it to an appropriate status code. You should only ever let exceptions fall through ”main” when the problem is really not something you can manage to handle.

That's the theory.

In practice often people let the exception eater in main handle it, and it either logs somewhere nobody looks or returns this sort of generic error and exits:

https://www.google.com/search?q=Microsoft+Word+has+encounter...

Re: Twelve Years of Go

#162

Post by msie »

shaan7 wrote: post #96
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…

> Just software, running, forever. Until your users realize that if there was a security vulnerability which was fixed, a system upgrade is not enough. They will have to either hope that you haven't moved on, or build things themselves. But then, thats not a problem with Go specifically, thats a general issue with "static link all things".

Ah, but what if the updated shared lib broke other apps depending on the old version? Pros and cons.

Re: Twelve Years of Go

#163

Post by [deleted] »

quadcore wrote: post #56
jrockway wrote: post #24

Earlier quoted context omitted.

If you want to write unmaintainable code in Go, it's already very easy; just use interfaces incorrectly. Go lets bad programmers write bad programs. If you have a solution to that problem, your programming language will be the one that kills all current programming languages. Generics will be similar; people will misuse them, and you'll curse their names when you have to dive in and debug it. But it will also let goo…

Everything you say compfort me in the fact this is going to be bad. Everything I read in the article about generics compfort me in the fact this is going to be bad. Example: first you agree with me "its already easy to write bad code", well you agree then its gonna be easier. Your example about io.Copy. Yeah bingo, absolutely io is the exception, the only case I know in 25 years of programming that is made tasteful w…

[deleted]

Re: Twelve Years of Go

#164

Post by handrous »

kaba0 wrote: post #159
handrous wrote: post #30

Earlier quoted context omitted.

What it offers is that code you didn't write is significantly easier to read & understand than in most languages.

But code you didn’t write yourself but still have to wade through is still harder to read and understand than code that was not required to be written due to a better abstraction.

Depends entirely on how long ago I wrote it, though.

Maybe it's a style thing, but I tend to have a lot more trouble with "WTF does this (leaky, inevitably) abstraction actually do and where does that actually happen?", when reading code, than with too much code.

Re: Twelve Years of Go

#165

Post by tdeck »

throwaway894345 wrote: post #89
tdeck wrote: post #82

Earlier quoted context omitted.

Oh, I'm not necessarily suggesting that my lack of curiosity about new language designs is a good thing. In fact I think it's kind of a mixed bag. I'm only clarifying because I don't want to seem to be implying something negative about younger developers.

I didn't think you were implying anything about younger developers, I was noting the rather significant difference between "I've matured as a programmer" and "maturity was baked into the language I use and its idioms, tools, ecosystem, etc".

Yeah, my point was that "matured" and "wisdom" are value-laden words and that's not necessarily the connotation I wanted to convey. Ideally I would get excited about both the problem and the tools. I completely understand the point you're trying to make about the ecosystem though.

Re: Twelve Years of Go

#166

Post by nobleach »

mseepgood wrote: post #17
AtNightWeCode wrote: post #13

Earlier quoted context omitted.

I can live with the error handling. But as I wrote. The problem is that it encourages if-programming. Something that is a problem in the Go community.

since when is if-programming a bad thing

Spectre I think? The mitigation patches make branch-heavy code slower.

Re: Twelve Years of Go

#167

Post by pxue »

thatswrong0 wrote: post #134
The_Colonel wrote: post #115

Earlier quoted context omitted.

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.

i have the completely opposite take.

every if err != nil; return err let's me mentally draw a line in the sand and not worry about exception handling for code above that line. It lets me start fresh and restart my mental model with the line of codes below the error handling block.

it doesn't take years of writing Go to understand this, all you need is a open mind to how Go does things.

Re: Twelve Years of Go

#168

Post by moondev »

the_gipsy wrote: post #64
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…

> With Go, you can just emit a binary for every supported platform dump the binary somewhere, and everyone in the world can download it and run it. Does this hold true? Don’t you need to switch to musl or something, to build a static binary?

It's actually easier now. On your target platform just "go run

Re: Twelve Years of Go

#169

Post by closeparen »

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

Earlier quoted context omitted.

> 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…

Most interfaces in Go code have exactly two implementors that will ever be plugged in: the production code and the mock. You want to be able to delve down through the layers of production code, e.g. handler to controller to gateway, to trace what's going on in an RPC request.

Re: Twelve Years of Go

#170

Post by jhgb »

Andys wrote: post #160
kaba0 wrote: post #141

Earlier quoted context omitted.

Than Java 1.14? Yes. Lighter is true of current Javas as well, but faster is dependent on the program. Go can often prevent garbage from being generated in the first place, but when creating garbage is a must, Java will happily handle heaps up to a terabyte in size, and its GCs are simply the state of the art. Also, Go most definitely has a runtime, what runs the GC otherwise?

But its also faster to compile and use as a developer. And by runtime I mean there's no JVM. If you're used to Java you should probably just stick with it, but using Go is a huge relief to me.

> And by runtime I mean there's no JVM

That's an awfully restricted definition of "runtime": https://golang.org/src/runtime/

Post reply on HN