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

211–220 of 244 posts

Re: Twelve Years of Go

#211

Post by kamaal »

Karrot_Kream wrote: post #202
uncomputation wrote: post #186

Earlier quoted context omitted.

Go’s error handling is a strange this to praise considering it is entirely possible to ignore it without warning and the way to check error kinds was bolted on through type assertions when errors are supposed to be values in Go. Error kinds are important especially in network programming when the error can be dozens of different things. Compare this to something like Rust or Haskell which force you to handle errors a…

Pretty much every form of Go tooling warns you when you ignore an error. If you only choose to run "go build", yes you can ignore it, but a simple "go vet" call and it'll be plain as day.

Certain things need to be available out of the box.

The whole point of a programming language is to make the programmers life easier.

By now decades of exposure to programming languages have made try/catch the standard way of working with errors. Forcing the programmer to guess issues, when the compiler/runtime could be doing it- IMO is just plain waste of human labor. And for even medium to large applications is a pointless exercise.

Re: Twelve Years of Go

#212

Post by grey-area »

mdaniel wrote: post #193
grey-area wrote: post #137

Earlier quoted context omitted.

> That's not 100% accurate; as a concrete example, contain the implementations of this interface method But why? I've often wanted to know what a method does in Ruby and have had to resort to .method(:x).source_location because it is so dynamic only the compiler knows once it has finished running it. I've never had to find all the places that conform to an interface in Go (a very different question) or Java, because…

> your interest should be limited to what they can do, which the interface tells you already That's a very idealistic perspective, and my sincere congratulations that every codebase you've worked with so far has been so great as to completely and unambiguously document every edge case and pre/post condition. If we stick just to the cited example: Features() string // Features are a comma separated string of node meta…

I sincerely have never had a problem with interfaces and never wanted to answer this question, but I suspect I use them far less than a lot of people who seem to use interfaces for almost every function argument in order to use them for testing or out of habit (or use code that does).

This interface is not great as it asks for ambiguous info and three methods.

I'd look at the docs, and what the callee does with .Features() for guidance (which in well written code will usually be in the same package as the interface, ideally the same file), not what one implementation happens to do - otherwise what's the point of the interface as you're coding to one implementation?

So I guess my answer is a variant on 'No true Go programmer would use interfaces this way', genuinely sorry about that, as you say we probably live in different worlds - I don't work on kubernetes or things inspired by it. If this is a big problem for you though, I reckon tooling could solve it for you, as you pointed out.

Re: Twelve Years of Go

#213

Post by azth »

Karrot_Kream wrote: post #208
azth wrote: post #203

Earlier quoted context omitted.

a, err := foo() // oops, unhandled error err = bar() if err != nil { ... } or fmt.Println("...") // oops, unhandled error or more insidiously err1 := foo() if err1 != nil { ... } err2 := bar() if err2 != nil { return err1 } // oops

In the first and the last case, it seems obvious to me where the error is. An obvious code smell caught in review. The second error, yeah, but lots of languages don't enforce error handling around printing to stdout, and even though Rust does in theory, in practice everyone just unwraps it and moves on with their day.

> but lots of languages don't enforce error handling around printing to stdout

They do, they throw exceptions.

> In the first and the last case, it seems obvious to me where the error is

The last case is especially insidious. I've seen it in production several times now. Very easy to miss. Particularly when refactoring/copy pasting code (which you have to do a lot of in golang).

Re: Twelve Years of Go

#214

Post by grey-area »

kaba0 wrote: post #153
grey-area wrote: post #117

Earlier quoted context omitted.

That's the theory. In practice it's impossible to exercise all the inputs your programs may get, and then they crash in production when users do things you don't expect.

Which is better than having a bug silently be in production for years to come due to a silent error.

Which is worse than just handling the error where it occurs.

Re: Twelve Years of Go

#215

Post by grey-area »

lawn wrote: post #126
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.

I find it fascinating that some hate it and others love it. I personally vastly prefer Rusts Result and Erlang/Elixirs {:ok, T} you pattern match on or crash the process and recover. The code is cleaner while it also makes harder to make mistakes.

I think a lot of Go programmers would agree with you.

I prefer the current situation to exceptions but would like to see them try something more like Rust or Elixir at some point.

Re: Twelve Years of Go

#217

Post by copperx »

grey-area wrote: post #44
princevegeta89 wrote: post #27

Would you say Go is suitable for web services and apps? I was trying to compare it with a rapid development framework like Rails but felt Go Web Frameworks aren't as mature and ready like Rails. Any insight would be appreciated, thanks!

Yes. I've used Rails extensively before writing some larger sites in Go. Quick comparison of Go vs Rails: Pros: More performance, multi-threaded extremely capable web server built-in, culture of simplicity and low-dependencies, no breaking changes, goroutines, ideal for small services, static binaries (all deps included) so no need for rbenv, docker etc etc, no included JS, great stdlib (far better than Ruby's IMO),…

Is there a canonical ORM to use in Go, or would raw SQL be preferred?

Re: Twelve Years of Go

#218

Post by kaba0 »

jerf wrote: post #189
kaba0 wrote: post #138

Earlier quoted context omitted.

Java’s nominal typing is both better and worse at the same time - but go is not novel in that area, plenty of similar languages existed before as well, so I don’t think having it contributed to go’s success. As for your last paragraph, I feel like we often mean something different between a production-level go and java project. Non-IDE java development is entirely possible, but I think a prod project usually means so…

"plenty of similar languages existed before as well, so I don’t think having it contributed to go’s success." I struggle to think of one that has risen to the heights Go has risen. I'm a computer language polyglot and a bit of a language tourist, though not as much as some people. There's a huge churn of features out there in some language somewhere, that has never manifested in any top-level language like C++ or Jav…

Half-telling, half-asking: isn’t type-scripts structural typing the same as Go’s, but overall much more powerful?

Re: Twelve Years of Go

#219

Post by korginator »

copperx wrote: post #217
grey-area wrote: post #44

Earlier quoted context omitted.

Yes. I've used Rails extensively before writing some larger sites in Go. Quick comparison of Go vs Rails: Pros: More performance, multi-threaded extremely capable web server built-in, culture of simplicity and low-dependencies, no breaking changes, goroutines, ideal for small services, static binaries (all deps included) so no need for rbenv, docker etc etc, no included JS, great stdlib (far better than Ruby's IMO),…

Is there a canonical ORM to use in Go, or would raw SQL be preferred?

There are ORMs available for Golang, but my experience has been better with packages like sqlx [1] or dat [2]. We've since been using SQLX for pretty much all DBMS related work, and regret nothing. In my experience SQLX gave us the right balance between abstraction and control.

[1] http://jmoiron.github.io/sqlx/

[2] https://github.com/mgutz/dat

Re: Twelve Years of Go

#220

Post by grey-area »

copperx wrote: post #217
grey-area wrote: post #44

Earlier quoted context omitted.

Yes. I've used Rails extensively before writing some larger sites in Go. Quick comparison of Go vs Rails: Pros: More performance, multi-threaded extremely capable web server built-in, culture of simplicity and low-dependencies, no breaking changes, goroutines, ideal for small services, static binaries (all deps included) so no need for rbenv, docker etc etc, no included JS, great stdlib (far better than Ruby's IMO),…

Is there a canonical ORM to use in Go, or would raw SQL be preferred?

Not really no, the lack of generics has hampered this as you can't easily return slices of arbitrary objects from an ORM so existing ORMs are pretty ugly. One way round this at present is code generation.

From your comment I think you're talking about a query builder/executor though, which is a specific part of an ORM, they're pretty simple to build if that is your thing or there are a few examples of that out there. You're really just building up an sql string, storing params, adding a few helpers for things like joins and then executing.

I personally use a query generator to generate consistent queries, and generated code per resource to create models from results.

Post reply on HN