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

61–70 of 244 posts

Re: Twelve Years of Go

#61

Post by throwaway894345 »

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 about it (like I was when Apple added the TouchBar to MacBook Pros), but any net benefit is going to be positively negligible in comparison to the degree in which Go raised the bar on the fundamentals.

Re: Twelve Years of Go

#63

Post by ssteel »

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…

The if-statements are not unnecessary if you want to handle errors in place and make the code highly readable. Just because you don't like it doesn't make it wrong.

Re: Twelve Years of Go

#64

Post by the_gipsy »

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?

Re: Twelve Years of Go

#65

Post by grey-area »

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 dependencies in favour of writing the minimum code required.

No dynamic libraries - deployment is easier and apps more stable

No declared interfaces - they are defined at the point of use, not declared elsewhere

No header files - why C++, why?

No implicit type conversion - of the kind that plagues JS (see WAT), this rarely makes it more verbose.

There are of course a few gnarly corners - nils, errors, panics, struct tags are not very satisfactory IMO at the moment.

There are also lots of great positive things about it – the GC, tooling, fast compiler, stdlib and docs are a great example for other languages IMO.

I'll be really interested to see where they take it next, while hopefully keeping the culture that has made it so pleasant to use. Thanks to everyone working on Go from me, and here's to another 12 years of Go.

Re: Twelve Years of Go

#66

Post by throwaway894345 »

caente wrote: post #54
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. I'd spend hours condensing 10 lines of perfectly working code into 1 line of the most concise text possible (...) they should be impressed by what the program does for them, not what language features you used to implement it. Interestingly, what made me go through similar evolution was the…

Our individual lives and experiences don't make the package manager better, though. Rather, Go's package manager (and its overall philosophy more generally) is good because Go was developed by people who had a lot of "life and experience". And it seems intuitive to me that someone who uses a language with a strong, mature philosophy would influence even more junior users.

Re: Twelve Years of Go

#67

Post by tdeck »

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.

Re: Twelve Years of Go

#68

Post by _0w8t »

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…

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 }

Re: Twelve Years of Go

#69

Post by ignoramous »

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?

Well, at some level you could say Go (pre 1.18) is Java 1.44 but with speed as a differentiator. Development speed, build speed, deploy speed, and runtime speed.

If Russ Cox ever proposes to rename Go to JavaScript, I guess no one would complain. ;)

Re: Twelve Years of Go

#70

Post by throwaway894345 »

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…

I'll add:

* No DSLs for declaring dependencies or otherwise scripting the build system.

* Excellent standard library

* Incredible ecosystem

Post reply on HN