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

111–120 of 244 posts

Re: Twelve Years of Go

#111

Post by grey-area »

throwaway894345 wrote: post #95
grey-area wrote: post #81

Earlier quoted context omitted.

They do have a few little DSLs, which I dislike: struct tags (optional, I prefer to avoid), magic comments which provide build directives (this seems icky to me, but avoids breaking Go1 promises I guess). https://dave.cheney.net/2018/01/08/gos-hidden-pragmas

I don't want to be too contrarian, but I'm not aware of any library which uses struct tags to encode anything that anyone might call a DSL. At most, they're used for key-value pairs (e.g., `foo:bar`), which is pretty easy to get one's head around. I don't use build directives and ideally we wouldn't need them, but most (all?) mainstream compiled languages have them. Maybe the complaint is that they don't get their ow…

Have a look at some of the bugs related to struct tags (420 open ones) - they can control marshalling and have lots of little directives in them like omitempty,attr,-,set plus they combine too (for xml,json,asn1 etc) and you can stuff your own little language in too if you want, the possibilities are endless! They are a set of limited yet unvalidated translation DSLs stuffed into a string.

https://github.com/golang/go/search?p=4&q=struct+tags&type=i...

Personally I think the language would be better without them, but it's too late now.

Re build directives - the complaint is they are comments which do things and change code/compilation, the syntax I don't care about, but I do care that they've abused comments to do this.

I agree, these problems are pretty trivial, I don't lose sleep over them.

Re: Twelve Years of Go

#112

Post by ohwellhere »

jerf wrote: post #98
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…

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…

This is exactly my experience. Being forced to handle so many more errors showed me how much error handling I was inadvertently eliding in other languages!

Re: Twelve Years of Go

#113

Post by JoeyJoJoJr »

grey-area wrote: post #86
kbd wrote: post #74

Earlier quoted context omitted.

> No 'oops I forgot to put in a try/catch and now my code died with no explanation'. This is so backwards. First, I want my program to immediately crash if I have a bug. Go is like shell in that it keeps going even if there's an error. Second, I'm used to getting stack traces, Go is the language that will give "no explanation" by comparison if there's a failure.

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.

I want my program to crash obviously during development so that I know of the existence of bugs, which can be ironed out before getting to production.

Re: Twelve Years of Go

#114

Post by JoelMcCracken »

jerf wrote: post #98
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…

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…

I think this is for sure the first time I have ever heard someone say that Haskell makes it too easy to handle error cases.

Re: Twelve Years of Go

#115

Post by The_Colonel »

pxue wrote: post #108
_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 }

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.

Re: Twelve Years of Go

#116

Post by initplus »

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?

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 efforts to improve performance), the Go stdlib is much leaner but simultaneously much more useful compared to the Java 1.44 equivalent (even latest Java stdlib is missing basics like JSON!), date/time handling is sane compared to pre-Java 8 equivalent, etc. etc.

Re: Twelve Years of Go

#117

Post by grey-area »

JoeyJoJoJr wrote: post #113
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.

I want my program to crash obviously during development so that I know of the existence of bugs, which can be ironed out before getting to production.

That's the theory.

In practice it's impossible to exercise all the inputs your programs may get, and then they crash in production when users do things you don't expect.

Re: Twelve Years of Go

#118

Post by Andys »

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?

It is lighter and faster and requires no runtime.

Re: Twelve Years of Go

#119

Post by xh-dude »

AtNightWeCode wrote: post #26
mseepgood wrote: post #17

Earlier quoted context omitted.

since when is if-programming a bad thing

What you learn at school when it comes to programming is to avoid if-statements for control flow. It is error prone. If-statements are mainly used for various types of guards.

I really think Go’s opinion here arises from a sense that some abstractions of control flow just should be verboten for concurrency. For example exceptions dumping a stack trace in a concurrent program is often OK and occasionally extremely cursed.

Re: Twelve Years of Go

#120

Post by Zababa »

_0w8t wrote: post #68
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…

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?

Post reply on HN