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

91–100 of 244 posts

Re: Twelve Years of Go

#91

Post by MapleWalnut »

bobbylarrybobby wrote: post #80
throwaway894345 wrote: post #75

Earlier quoted context omitted.

> 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 t…

Mypy provides a server to help with this called dmypy: https://mypy.readthedocs.io/en/stable/mypy_daemon.html

Re: Twelve Years of Go

#92

Post by jpavel2 »

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 write a variety of CLI tools for my own use in Java.

On this low-end Chromebook (Samsung Chromebook 3 with a Celeron N3060 @1.60GHz) I can start the JVM, load the classes for my CLI program, and print a help message,

    jpavel@penguin:~$ time rcr -h
    Usage: RCloner  get|put  [args]
           RCloner  list
    
    real    0m0.316s
    user    0m0.208s
    sys     0m0.126s
in less than 1/3 of a second. And this is with stock openjdk version 1.8.0_302, which doesn't include the startup time improvements of Java 10 & 12.

Sure, I wouldn't write utilities meant to be piped one into another, but for standalone CLI tools, the JVM startup time isn't prohibitive at all.

Re: Twelve Years of Go

#93

Post by nineplay »

nkozyra wrote: post #41
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…

> Return err, always as the last parameter Well unfortunately, not always.

If you have a good linter it will flag code where err is not last

Re: Twelve Years of Go

#94

Post by shaan7 »

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 to copy code dozens of times and then fixing them all in one go using their ninja refactoring skills. Just a different kind of tradeoff, at the end.

So given how laborious it is to make anything more than simple programs (because of the amount of copy-paste-driven-development required), I generally avoid Go unless I'm writing a webservice.

For me Go's virtues are static typing and wide variety of community packages to do things. The whole "oh not having features is a feature" thing is just an opinion for the sake of having an opinion. otoh, I damn excited to have generics support soon finally :)

Re: Twelve Years of Go

#95

Post by throwaway894345 »

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

Earlier quoted context omitted.

I'll add: * No DSLs for declaring dependencies or otherwise scripting the build system. * Excellent standard library * Incredible ecosystem

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 own dedicated syntax, in which case I don't see the issue beyond "in $MY_PREFERED_LANG, build directives have their own syntax, and that's how I like it!".

In all cases, these issues seem positively trivial compared to "you can't parse JSON or send an HTTP request until you learn some DSL or cargo-cult someone else's build file".

Re: Twelve Years of Go

#96

Post by shaan7 »

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…

> Just software, running, forever.

Until your users realize that if there was a security vulnerability which was fixed, a system upgrade is not enough. They will have to either hope that you haven't moved on, or build things themselves. But then, thats not a problem with Go specifically, thats a general issue with "static link all things".

Re: Twelve Years of Go

#97

Post by nineplay »

kbd wrote: post #74
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…

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

I don't know what scale of projects you've worked on. When you're dealing 100K requests/second you very much do not want to immediately crash. It is absolutely the worst think your code can do.

Re: Twelve Years of Go

#98

Post by jerf »

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…

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 care, exception-based programming and errors-as-values converge in the end anyhow in "code that treats errors correctly". But my exception-based code is a lot more informed by the errors-as-values approach now; a lot more try statements with catch statements that actually do something.

Even Haskell's very nice Either monadic handling can make it too easy to be in the heat of the moment and not thinking about what the errors actually mean and what I can do about them.

I don't think it's appropriate for every domain, which is why I qualified the code I tend to work on. But in those domains I'm thinking a lot more about how every single line of code can go wrong rather than leaning on default exception-based handling and expecting it all to work out.

Re: Twelve Years of Go

#99

Post by vlunkr »

kbd wrote: post #74
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…

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

> First, I want my program to immediately crash if I have a bug.

An error being returned doesn't always mean there's a bug.

> Go is like shell in that it keeps going even if there's an error.

With both Go and shell scripts it's up to you if you want the program to keep going when there's an error.

Re: Twelve Years of Go

#100

Post by ianopolous »

Things I love about Go:

1) ridiculously easy built-in cross-compilation

2) structs (compact memory layout and usage)

3) easily having millions of cheap threads aka go-routines

4) modern standard library for things like cryptography

Things I hate about Go:

1) plugins (very painful to get working and not even cross platform - e.g. Windows)

2) duck typing make refactoring and understanding new codebases error prone

3) no ternary operators (the verbosity!)

4) missing basic collections (like set, various queues etc.)

5) lack of built-in memory use limits

6) errors and error handling (just give me a stack trace for pete's sake)

Post reply on HN