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

81–90 of 244 posts

Re: Twelve Years of Go

#81

Post by grey-area »

throwaway894345 wrote: post #70
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

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

Re: Twelve Years of Go

#82

Post by tdeck »

throwaway894345 wrote: post #77
tdeck wrote: post #67

Earlier quoted context omitted.

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

Oh, I'm not necessarily suggesting that my lack of curiosity about new language designs is a good thing. In fact I think it's kind of a mixed bag. I'm only clarifying because I don't want to seem to be implying something negative about younger developers.

Re: Twelve Years of Go

#83

Post by maleldil »

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/C++/Rust, but then you deal with complicated OS level calls

What OS-level calls are you doing in C++/Rust that you aren't in Go?

> library deployment issues (problems fixed by Go)

How is Go's library tooling better than Cargo? I believe Go's is strictly worse, with its URL-based imports and how it deals with major versions.

Re: Twelve Years of Go

#84

Post by Thaxll »

maleldil wrote: post #83
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/C++/Rust, but then you deal with complicated OS level calls What OS-level calls are you doing in C++/Rust that you aren't in Go? > library deployment issues (problems fixed by Go) How is Go's library tooling better than Cargo? I believe Go's is strictly worse, with its URL-based imports and how it deals with major versions.

I think OP is talking about single binary with no dependencies here.

As for go mod, yes it's not perfect but it's as powerful as Cargo. https://golang.org/ref/mod

Re: Twelve Years of Go

#85

Post by pphysch »

princevegeta89 wrote: post #60
pphysch wrote: post #33

Earlier quoted context omitted.

Definitely suitable. Depends if you want to work within a framework or not. If you want a framework, use Rails/Django/Node as they are very mature. Huge plugin ecosystems, great for prototyping non-trivial features like authn, because a plugin certainly exists for it. If you want more control (fewer dependencies), roll everything yourself with Go. The built-in libraries are fantastic, you can spin up a CRUD app witho…

Thanks. How about a framework which has all these things stitched together already? For example, a good templating engine and an ORM that supports DB migrations out of the box? Do we have one for Go?

GORM (https://gorm.io/index.html) has auto migrations.

But it is still a framework, which means it is making a lot of decisions for you and forcing you to learn its own way of doing things. Ultimately it is a relatively thin layer over builtin Go libraries like `html/template`, `net/http`, `database/sql`; generally speaking, the Go philosophy is to build systems yourself from these components and therefore keep the architecture simple, focused, and maintainable.

Unless you are stuck with Go for a good reason, if you want a framework use one of the industry standard ones mentioned previously.

Re: Twelve Years of Go

#86

Post by grey-area »

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.

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.

Re: Twelve Years of Go

#87

Post by wbobeirne »

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.

Check out https://github.com/microsoft/pyright, it's pretty snappy if you don't mind some JS in your ecosystem.

Re: Twelve Years of Go

#88

Post by bombela »

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…

I have some sort of python language server running with neovim to highlight type errors. This is definitively not fast to add errors. But being asynchronous it's palatable.

Re: Twelve Years of Go

#89

Post by throwaway894345 »

tdeck wrote: post #82
throwaway894345 wrote: post #77

Earlier quoted context omitted.

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

Oh, I'm not necessarily suggesting that my lack of curiosity about new language designs is a good thing. In fact I think it's kind of a mixed bag. I'm only clarifying because I don't want to seem to be implying something negative about younger developers.

I didn't think you were implying anything about younger developers, I was noting the rather significant difference between "I've matured as a programmer" and "maturity was baked into the language I use and its idioms, tools, ecosystem, etc".

Re: Twelve Years of Go

#90

Post by mountainriver »

handrous wrote: post #16
AtNightWeCode wrote: post #13

Earlier quoted context omitted.

I can live with the error handling. But as I wrote. The problem is that it encourages if-programming. Something that is a problem in the Go community.

If it's helping keep the "'if' considered harmful" crowd away, I say keep it. There are plenty of other languages.

Yeah exactly, conditionals around errors are fine. Nothing like being pedantic for no reason
Post reply on HN