arialdoDec 9, 2022

First impressions of #golang

- the compilation speed is just insane. I often compile twice, because I don't believe.

- I'm not used anymore to such amount of mutability
- the syntax is meh
- having to deal with nil dampens enthusiasm

Show threadElanDec 10, 2022
@arialdo wait until you have to do error handling every single time.
Show threadarialdoDec 10, 2022
@elan how could they design error handling like that? I cannot explain.
Genuine question: are there developers loving and defending that approach?
Show threadElanDec 10, 2022

@arialdo yes

https://davidnix.io/posts/error-handling-in-go/

And

https://www.quora.com/Why-does-Go-not-have-exceptions

😂😂😂

Go's Error Handling is Elegant

The Go authors put a lot of thought into error handling. I feel they came up with one of the better solutions out there. It's simple and elegant

David Nix
Show threadmtpDec 10, 2022

@elan @arialdo Can’t speak to C#, but I have equivalent experience under my belt with Go and Java. The biggest win is treating errors as values and data, which yields ergonomic flow control with shallower nesting and more clear variable scope over exceptions: https://go.dev/blog/errors-are-values.

Merely checking whether the error value isn’t nil and returning is a picobrain approach. If you’re not using package errors or cmp, you’re designs are missing out.

Errors are values - The Go Programming Language

Idioms and patterns for handling errors in Go.

Show threadarialdoDec 10, 2022
@matt @elan I see. I find using structures such as Either more elegant. Of course, as long as I’ll be playing with Go, I’ll stick with its idiomatic way of handling errors. I’m curious to see if on the long term I’ll be able to appreciate it.
Show threadElanDec 10, 2022

@arialdo @matt idiomatic error handling is probably best.

I've seen folks try to build exceptions using panic and recover at the cost of performance

Show threadarialdoDec 10, 2022

@elan @matt I would never use exceptions and catches for handling custom errors: I believe using exceptions for controlling the application flow is an anti-pattern.
That said, an

actual, err

result to be checked after each function call seems to me equally very inconvenient.
Either<Error, Result> is the best option I could think of.

Show threadarialdoDec 10, 2022
@elan @matt Either, used as a Functor, an Applicative or a Monad, would handle errors keeping the domain code clean from the error handling boilerplate.
I’m not sure that would be possible in Go, though. For sure, it would not be idiomatic at all.
Show threadElanDec 10, 2022

@arialdo @matt yep agreed. Exceptions as control flow.

A Result type is what I've used in DDD. Exceptions are also good when you're many layers deep and have a top level orchestration to catch the exceptions and manage them accordingly.

Show threadarialdo
@elan @matt interesting. How are the success and error branches handled, with Result? With if statements? Also, with which language did you apply that?
Dec 10, 2022 at 10:03pmWeb
Show threadElanDec 10, 2022

@arialdo @matt this is a #csharp implementation specific to #msftorleans

https://github.com/Applicita/Orleans.Results

The concept remains for any other language.

GitHub - Applicita/Orleans.Results: Concise, version-tolerant result pattern implementation for Microsoft Orleans 7

Concise, version-tolerant result pattern implementation for Microsoft Orleans 7 - GitHub - Applicita/Orleans.Results: Concise, version-tolerant result pattern implementation for Microsoft Orleans 7

GitHub