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

121–130 of 244 posts

Re: Twelve Years of Go

#121

Post by grey-area »

initplus wrote: post #104
new_stranger wrote: post #42

Earlier quoted context omitted.

> I'd spend hours condensing 10 lines of perfectly working code into 1 line of the most concise text possible Which is also the hardest part of convincing people to use Go for me: "Why can't I just .map()/.filter()/.find()?" followed closely by "Why do I always have to check for errors?" What is odd to me is that while yes, my Go code is more verbose than my node services - I always end up writing less Go for the sam…

I'm a huge go proponent, but I do think the lack of map/filter/find etc. is a big downside to the language. I know how to write for (if item == myItem...) or a for (if item > max...) but it feels like a colossal waste of time every single time I write one of these loops. Go would benefit a lot more from some basic slice manipulation tools compared to features like generics that have actually made it into the language…

I imagine they'll add map/filter/find after generics are in. It's pretty easy to define some slice types though which include those in the meantime, type Slice []string and add some functions then just use your new type for collections.

Re: Twelve Years of Go

#122

Post by grey-area »

leoc wrote: post #50
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…

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?

Epic troll, but there is life outside The Kingdom of Nouns.

Re: Twelve Years of Go

#123

Post by new_stranger »

vlunkr wrote: post #110
jerf wrote: post #98

Earlier quoted context omitted.

My non-Go code is starting to look more like my Go code. One of the things Go taught me is that I was not being as careful about my errors as I should be. It can be argued that exception-based handling provides you a nice baseline default, but it makes it way to easy when doing network or system-type programming to thoughtlessly default to that, when you need to be thoughtfully defaulting to that. With sufficient car…

> One of the things Go taught me is that I was not being as careful about my errors as I should be. I identify with this so much. Especially when dealing with external things (file system, database, network) things can go wrong at nearly every step. And yeah, that means you have to check errors at every step, but it forces you to think about how you want to handle them, and what message you want to propagate when the…

Hard to overemphasize this. Handling errors is similar to the benefits that writing tests provides - slower upfront, but a more stable product gets shipped.

Handling errors everywhere means problems are already solved before they happen. No 1 am pagerduty alerts because we didn't consider what would happen if a DNS server hung until we timed out and thought just wrapping in a try/catch and crashing was a good idea.

Re: Twelve Years of Go

#124

Post by mdaniel »

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?

I believe you may be thinking of `CGO_ENABLED=1` which causes golang binaries to fail to run on musl distros

So yes, your comment is probably right, but I get the impression the grandparent was a tiny bit tongue in cheek anyway

Re: Twelve Years of Go

#125

Post by closeparen »

Zababa wrote: post #120
_0w8t wrote: post #68

Earlier quoted context omitted.

Most perceived verboseness of Go comes not from the language or libraries but from the formater that does not allow to compress 3 lines of the error check down to single if err != nil { return err }

> if err != nil { return err } I'm far from a Go expert, but I feel like this line is a bit pointless, especially if you write it a lot. At this point, why not just not handle the error, or panic?

The community strongly discourages panic.

Re: Twelve Years of Go

#126

Post by lawn »

AtNightWeCode wrote: post #10

12 years and still no proper error handling. World stars. ;) Seriously, the error handling is a big problem with Go. Not the way it works, the way it effects how people do control flow in general.

I find it fascinating that some hate it and others love it.

I personally vastly prefer Rusts Result and Erlang/Elixirs {:ok, T} you pattern match on or crash the process and recover.

The code is cleaner while it also makes harder to make mistakes.

Re: Twelve Years of Go

#127

Post by lawn »

princevegeta89 wrote: post #27

Would you say Go is suitable for web services and apps? I was trying to compare it with a rapid development framework like Rails but felt Go Web Frameworks aren't as mature and ready like Rails. Any insight would be appreciated, thanks!

You should also consider Elixir with Phoenix, as it's a comparable experience with Rails (although not as many libraries) while giving you much better performance. And Phoenix LiveView is just an incredible productivity boost, there's nothing quite like it.

Re: Twelve Years of Go

#128

Post by wtf_is_up »

The thing about Go that pulled me in around 10 years ago was that I could inspect the source code of an open source Go project on GitHub and actually tell what was going on. And on top of that I could easily cross-compile and deploy binaries in a way that blew automake/CMake away. And of course the goroutines... no more pthreads. It's a real case study in opinionated language design.

Re: Twelve Years of Go

#129

Post by Zababa »

closeparen wrote: post #125
Zababa wrote: post #120

Earlier quoted context omitted.

> if err != nil { return err } I'm far from a Go expert, but I feel like this line is a bit pointless, especially if you write it a lot. At this point, why not just not handle the error, or panic?

The community strongly discourages panic.

I think a panic is still better than a chain of if err != nil { return err } that bubbles up and does nothing. Of course the best solution would be proper error handling but not everyone does that (and it's not always obvious what to do).

Re: Twelve Years of Go

#130

Post by skybrian »

mseepgood wrote: post #28
skybrian wrote: post #20

Earlier quoted context omitted.

It depends on what kind. I didn’t find maintaining codebases littered with platform-specific ifdefs all that fun. If statements used for error checking are a bit verbose but basically fine.

Go doesn't have platform-specific ifdefs sprinkled throughout the source. Platform-specific code is separated into files guarded by build tags as recommended in 'The Practice of Programming'. Compile-time control flow is not mixed with runtime control-flow.

Sure, that was in C. Go is an improvement.
Post reply on HN