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

71–80 of 244 posts

Re: Twelve Years of Go

#71

Post by the_gipsy »

nineplay wrote: post #25
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.

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…

Go errors are better than exceptions, yes, but way worse than Result.

There are too many ways too screw up error vars + nils + control flows.

Re: Twelve Years of Go

#72

Post by throwaway894345 »

_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 this is the case, I think the fault here lies with flawed perception and not the formatter.

Re: Twelve Years of Go

#73

Post by Zababa »

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?

Not having to wrap your imperative code in classes is a big plus.

Re: Twelve Years of Go

#74

Post by kbd »

nineplay wrote: post #25
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.

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…

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

Re: Twelve Years of Go

#75

Post by throwaway894345 »

kryptonomist wrote: post #58

To me, the greatest advantage of Go is the build time, which is almost instant. So you get the joy of programming like in Python/Js, being able to test very quickly your code, without having to deal with stupid errors coming from type mismatch or function parameters. Plus, you get the performance of a compiled language, with a simple syntax. Sure, you get just slightly better results with C/C++/Rust, but then you dea…

> So you get the joy of programming like in Python/Js, being able to test very quickly your code

Ironically the canonical Python type checker, code formatter, etc take ages to run on even small code bases.

Re: Twelve Years of Go

#76

Post by ryandvm »

kryptonomist wrote: post #58

To me, the greatest advantage of Go is the build time, which is almost instant. So you get the joy of programming like in Python/Js, being able to test very quickly your code, without having to deal with stupid errors coming from type mismatch or function parameters. Plus, you get the performance of a compiled language, with a simple syntax. Sure, you get just slightly better results with C/C++/Rust, but then you dea…

C#/Java are almost as fast, but not for immediate execution environments. If you have one off invocations of the code, Go executables will beat the pants off Java as you wait for the JVM to fire up and for HotSpot to kick in.

Re: Twelve Years of Go

#77

Post by throwaway894345 »

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.

The nice bit about Go is that this maturity is baked into the philosophy and thus the language, the tooling, and the ecosystem where it benefits even younger developers. For example, your own hard-earned wisdom is great but it doesn't automatically make your language's package manager (or any other software you depend on, including libraries) better. But when that kind of wisdom is idiomatic, everything is better even when it's built by more junior developers.

Re: Twelve Years of Go

#78

Post by ed25519FUUU »

ryandvm wrote: post #76
kryptonomist wrote: post #58

To me, the greatest advantage of Go is the build time, which is almost instant. So you get the joy of programming like in Python/Js, being able to test very quickly your code, without having to deal with stupid errors coming from type mismatch or function parameters. Plus, you get the performance of a compiled language, with a simple syntax. Sure, you get just slightly better results with C/C++/Rust, but then you dea…

C#/Java are almost as fast, but not for immediate execution environments. If you have one off invocations of the code, Go executables will beat the pants off Java as you wait for the JVM to fire up and for HotSpot to kick in.

Maybe fast in principle but rarely in practice. I’ve never once worked in a Java codebase that started up shorter than 5 or 10 seconds.

Re: Twelve Years of Go

#79

Post by throwaway894345 »

ryandvm wrote: post #76
kryptonomist wrote: post #58

To me, the greatest advantage of Go is the build time, which is almost instant. So you get the joy of programming like in Python/Js, being able to test very quickly your code, without having to deal with stupid errors coming from type mismatch or function parameters. Plus, you get the performance of a compiled language, with a simple syntax. Sure, you get just slightly better results with C/C++/Rust, but then you dea…

C#/Java are almost as fast, but not for immediate execution environments. If you have one off invocations of the code, Go executables will beat the pants off Java as you wait for the JVM to fire up and for HotSpot to kick in.

I've heard smart people argue convincingly that the JVM doesn't actually take long to fire up, and that this is something of a myth. It may take a bit of time for the JIT to optimize, but that shouldn't impact basic CLI tools (un-JIT-ed code is basically just interpreted code, and that runs quickly enough). I'd be curious to hear from people who have looked into this.

Re: Twelve Years of Go

#80

Post by bobbylarrybobby »

throwaway894345 wrote: post #75
kryptonomist wrote: post #58

To me, the greatest advantage of Go is the build time, which is almost instant. So you get the joy of programming like in Python/Js, being able to test very quickly your code, without having to deal with stupid errors coming from type mismatch or function parameters. Plus, you get the performance of a compiled language, with a simple syntax. Sure, you get just slightly better results with C/C++/Rust, but then you dea…

> So you get the joy of programming like in Python/Js, being able to test very quickly your code Ironically the canonical Python type checker, code formatter, etc take ages to run on even small code bases.

I think a lot of that is that Python doesn't launch a server that handles code analysis/formatting requests, so every time you want to do another round of things-to-do-on-save, they all have to do be done more or less from scratch (some info can be cached between runs, but if you're launching a Python process that's like 100ms right there...). I imagine if there were a Python code server that handled formatting and type checking without ever shutting down, it would be quite speedy.
Post reply on HN