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

101–110 of 244 posts

Re: Twelve Years of Go

#101

Post by jerf »

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?

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 that boilerplate and frameworkitis that Java is so well known for are just trying to get around the consequences of that mistake, because all the interface-based structure has to be laid down in advance.

It isn't the only difference between the two, but I think it would have consumed enough of the oxygen of the niche Go is currently in that Go might never have been born.

In practice, I find Go to be just slightly harder than working with dynamically typed languages, rather than a huge step, and the benefits I get in return make me prefer it for almost any task above 200-ish lines. I definitely can not say the same about Java, because of this difference and the second-order effects it has on the entire ecosystem.

It is still completely practical to create a production-level Go project by just cracking open a text editor and typing "package main" into your editor and typing away. I get the impression most people would not consider that a practical way to start a production-level Java project.

Re: Twelve Years of Go

#102

Post by jerf »

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…

"I'm not aware of any library which uses struct tags to encode anything that anyone might call a DSL."

There's a couple of struct validation libraries that got IMHO a bit overexcited with what you can jam in a struct tag and then interpret, but they don't seem to have gotten very popular, so it doesn't factor into the language much.

Re: Twelve Years of Go

#103

Post by AnimalMuppet »

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.

And what you learn after a few years in the real world is that, when school tells you "this is the right way", they're almost always wrong. Or, there at least almost always wrong in many circumstances. The real world is a lot more complicated than they teach you in school, and the correct answer is almost always "it depends".

Should you avoid if-statements? It depends. What are you going to have to do instead? You're going to have to do something. Is that something going to be more understandable for your co-workers for the lifetime of the code? Maybe, depending on your co-workers. Maintainability over the lifetime of the code far outweighs and "should" that they tell you at school.

Re: Twelve Years of Go

#104

Post by initplus »

new_stranger wrote: post #42
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'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.

The error handling I don't find so frustrating - it's great that it explicitly marks at the call site which functions can potentially error. It's like a working version of an inverse noexcept from C++. I do wish they would take a leaf out of swifts book though, with the try keyword. In practice error handling flow in my go programs is identical to using exceptions, it would be nice to have some helpers to make this default less verbose without losing the ability to distinguish at the call site which calls are error-y.

Re: Twelve Years of Go

#105

Post by adamc »

tdeck wrote: post #67
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 used to be excited by programming language features instead of what problem I was actually trying to solve with programming. This happened to me too, without using Go. I think I just got older.

I came here to say that. I agree with your analysis.

Re: Twelve Years of Go

#106

Post by jerf »

shaan7 wrote: post #94

I can attest to the fact that programming in Go taught me a lot of good engineering. I certainly find myself better trained at handling errors, for example. However, I always feel exhausted when implementing real-world systems with Go given the lack of $things (that everyone feels is a virtue). Over time I realized that a lot of people just aren't as lazy (or scared of breaking things) as I am - they find it easier t…

If you are or your coworkers are constantly copying and pasting code, stop, and think a bit more. I do a lot of Go development and almost never copy and paste anything anywhere. (And even in those cases it's usually justified. I just a few minutes ago copied and pasted a big struct... but it's because the first struct was defining a JSON message, and the second struct was defining a very similar, but not quite identical, JSON message in another file. This doesn't seem like a big deal to me, because it's defining a separate external data format and while they are superficially similar they are not the same and really shouldn't share code.)

Either you're not using the tools Go has to their full effect, or, possibly, you shouldn't have chosen Go. But I make that last concession not because it probably fits your case, but because it is technically true. (In particular, don't take Go for heavy math code where you need a type system that is ready for lots of mathematics.) But it's probably not applicable.

You should not be copying and pasting all the time.

There are several communities; I happen to hang out on the reddit /r/golang. If you've got something that you'd like to see how to refactor to not be copy and paste, consider posting a question there (ideally with a running version in the playground of whatever you're asking about). It is true that not everything can be improved, but most things can.

Re: Twelve Years of Go

#107

Post by AnimalMuppet »

quadcore wrote: post #12

I cant believe they are moving forward with "generics". Programmers on average already tend to make things more complicated than they should be. Now every single module in the ecosystem is gonna use more abstractions, generics to fit their social environment. Its well known that abstractions are the devil. How many modules are gonna use generics when they should not? Most? Programmers are bad at programming and they…

> Its well known that abstractions are the devil.

Woah there. No, it is not "well known", nor is it correct. Over abstraction is very problematic (and very common), true. But under abstraction is also problematic. There is a sweet spot, and it's hard to find. But the correct answer is emphatically not "no abstraction".

Re: Twelve Years of Go

#108

Post by pxue »

_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 }

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

Re: Twelve Years of Go

#109

Post by nineplay »

AtNightWeCode wrote: post #37
nineplay wrote: post #25

Earlier quoted context omitted.

Error handling is easily one of my favorite things about Go. No 'oops I forgot to put in a try/catch and now my code died with no explanation'. No 'I forgot a finally ( or didn't realize I needed one ) and now I'm leaking resources'. No 'should I return Null or false or an error code?'. No '20 log messages for the same error because every function is reporting it'. The Go model - Return err, always as the last parame…

1. You have something that catches and logs all uncaught exceptions. 2. Defer is nice. As easy to forget as using in C#. 3. Always null/nil. Uncle Bob is plain wrong here. 4. Stack trace. But you should keep things wide and shallow. No matter what technology you use. In Go it is about as easy to swallow errors as with try-catch. But my post was more about how all the if-statements generates more unnecessary if-statem…

These are great designs that have been completely ignored by developers in every large scale codebase I've ever worked on.

"That's the developers fault, not the languages"

Look, the old grey mares of the programming world are doing the best they can. I'm not going to blame C because its developers usually make it up as they go.

But we've learned things over the past 50 years, and one of the things we've learned is that company defined 'best practices' and code reviews can not catch all the mistakes that developers make and all of the things that can bring a service to its knees.

Go has the benefit of experience. It knows what mistakes developers make and it is going to prevent them from doing that. There is Right Way To Handle Errors in Go.

How many times have I seen uncaught exceptions? I saw one a week ago.

How many times have I lost resources because I didn't realize something I was calling could throw exceptions? Dozens.

Null/Nil exceptions. I couldn't count the null pointer errors I've had to fix in my time. Probably in the hundreds.

"should" keep things wide and shallow - somehow when Java 8 came out all the Lambda programmers lost this message.

None of these practices scale. We know that because we've seen it

Re: Twelve Years of Go

#110

Post by vlunkr »

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…

> 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 they happen. As a result, my Go code has very few unexpected errors in production.

Post reply on HN