181–190 of 425 posts
Earlier quoted context omitted.
Anti-cleverness is what makes Go great. Go code is simple, and it is easy to read/understand. It's a feature of the language
Go code is all about being able to see the trees, forget about the forest. Go programs are rarely easy to read or understand unless they are written by exceptionally talented developers in my experience.
Just try writing three Go programs with error handling, then, try other languages! I was pissed at first. However, now I cannot code in any language without overusing try and being scared of each line. Using Go's error handling is actually making your code smarter, I mean, you don't want your code to break with a weird message because of something stupid. The simplest example is adding a default-path whenever I'm rea…
with {:ok, val1} handle_notfound_error()
{:error, :eperm} -> report_permission_error()
_ -> raise("don't worry this process is supervised, let it crash!")
end
Earlier quoted context omitted.
> Do I particularly like managing errors that way? No, but I do think that it improves the transparency and quality of a lot of Go projects. So long as we can all agree that it feels super bad, I guess this is fine. But it does sort of mean that Golang approaches the Java world back with checked exceptions where principle trumped ergonomics. That lead to a world where folks felt "forced" to use Java, and that's a sti…
You can't compare it to Java checked exceptions. Java checked exceptions are one of those billion dollar "mistakes". It is the single worst thing in Java for me. Checked exceptions add nothing and break almost everything around clean design & code. For that comparison to work, java would have needed to only have checked exceptions, with some added language features to deal with them cleanly, and then it might actuall…
void foobar() rethrows IOException as AppException rethrows FooError, BarError as WtfError {
The exception syntax itself is also clunky. If you have a complex expression, you have to extract it and assign it to a variable. But you still have to declare that variable outside the try/catch. And, of course, every exception requires Yet Another Class Definition. I'd do:
class SomeClass {
exception ThingBroke handles ArithmeticException;
exception DatabaseDown handles SQLException;
void method(int a) {
try {
int x = (555 / a rethrows ThingBroke) + (getNum() rethrows DbDown);
} catch(ThingBroke e) {
Maybe a better approach would be to add an Unchecked interface, though from my reading of the source for exceptions, they seem to be very brittle and maybe there's just no fixing it.
This hits at something fundamental about Go, which is what I like the most about it... It's a language intended to have few primitives with an emphasis on code being transparent and errors being values, requiring you to think about what they might be at each point as you're forced to carry them up the chain. Do I particularly like managing errors that way? No, but I do think that it improves the transparency and qual…
> Do I particularly like managing errors that way? No, but I do think that it improves the transparency and quality of a lot of Go projects. So long as we can all agree that it feels super bad, I guess this is fine. But it does sort of mean that Golang approaches the Java world back with checked exceptions where principle trumped ergonomics. That lead to a world where folks felt "forced" to use Java, and that's a sti…
Enjoy your ecosystem, I'm going to continue to use languages that actually like me, and care how my experience is.
This hits at something fundamental about Go, which is what I like the most about it... It's a language intended to have few primitives with an emphasis on code being transparent and errors being values, requiring you to think about what they might be at each point as you're forced to carry them up the chain. Do I particularly like managing errors that way? No, but I do think that it improves the transparency and qual…
Maybe something like vectored error handling (like in Basic) would fit the language better - was curious why Golang didnt implement that - seems a natural pattern their model would work well with.
Earlier quoted context omitted.
It's error prone in that you aren't forced to handle the error. In languages such as Rust or Haskell, you have a Result type which can either be an Ok(val) or an Err(err). In order to "unwrap" a Result, you have to check the error case. Basically there's a compile time guarantee that errors are handled.
I'm not a Rust expert but afaik Rust doesn't enforce error checking since you explicitly need to unwrap(). It's very possible to panic because you forgot to check something. It's similar in Go since you can't compile with unused variable so you need to explicitly discard the error with _. Ex: result, _ := func() This is for multi-value returns, for single value you can even omit the _ https://golang.org/doc/effective…
Your example re Go errors is incorrect. The go compiler allows you to ignore errors in returns without any compiler error.
For example
err := doThingThatErrs()
and
doThingThatErrs()
are both valid Go code.
Earlier quoted context omitted.
> Should I compare it to "Golang Dependency Hell Claimed My Project?" As someone just learning Go, what is Golang Dependency Hell?
It's not a problem you have to deal with but those of us from the world before bundled vendoring list projects because of Go's creators not having sympathy with people not living in a single global monorepo universe and most of its audience not having the discipline to vendor stuff by hand.
also google: we don't have that problem at google, so it's not a problem
Earlier quoted context omitted.
> Because they think go needs something better, and if this passes, they'll never get it? More that they will never get rid of it, even after something better comes along. Same reason Go has been careful about adding generics. There have been many generics proposals over the years. Any one of them – or even all of them – could have been implemented, but all of them had faults that the Go maintainers did not way to fo…
Unfortunately, they saddled the language with the lack of generics, which has a nonzero cost, too. Worse yet, Go community may develop, or already has, a taste to the lack of genetics. When a really really good proposal comes along, and is implemented, it may produce a Python 2/3 rift with the existing code bases, or not be accepted at all because of this.
IMO, this is because with generics (and we even get shades of this in error handling), we are running into limits with the type system itself. Coming up with a proposal that’s universally acceptable for generics would probably require a bottom-up (and potentially compatibility-breaking) refactor of the type system. Would that be this worth the effort? Eventually, probably, yes, because you might unlock other benefits for free (compilation time, GC efficiency, etc.).
Today, however, there are many lower hanging & valuable fruit to pluck. In the meantime, new languages with better type systems are invited to capture market share. :)