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 threadmtp

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

Dec 10, 2022 at 2:46pmWeb
Show threadElanDec 10, 2022

@matt @arialdo I'm familiar with the concept. I'm just not a fan, yet.

I've been doing go for a year and still long for that familiar try catch block 🤤

Show threadmtpDec 10, 2022

@elan @arialdo Beyond keeping functions short, one technique to replicate the semantics is to inline anonymous functions in others with defer statements. It isn’t the most beautiful thing, but sometimes it is exactly what’s needed, especially when computing an output value.

To the extent it’s useful, there may be other gems in https://google.github.io/styleguide/go/. There are a lot of projects out there — notable ones — that do not model idiomatic design well.

Go Style

Style guides for Google-originated open-source projects

styleguide
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 threadarialdoDec 10, 2022
@elan @matt interesting. How are the success and error branches handled, with Result? With if statements? Also, with which language did you apply that?
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