[GO] Who uses Go and what do you like/dislike about it?

[Vasco Costa]

Ever since it came out more than ten years ago it caught my attention.
Back then I was using C/C++ as my goto compiled languages and Python for
scripting or anything more high level. Go hits the perfect balance
between these two worlds. It's easy enough to learn and use, thanks to
its minimalist approach which I appreciate, free of boiler plate noise,
very similar to bare C, but crucially comes with batteries included, in
the form of an excellent standard library. Being a compiled language its
performance is much better when compared to something like Python.

Performance isn't really what I value the most about Go however, instead
what really makes it shine for me is its minimalist set of keywords and
simple approach. I love Python and everything it brings, but if for some
reason I stay away from it for a while, I tend to forget some of its
idiomatic patterns, whereas I can more easily remember Go's equivalents.

Something else I must mention on this initial post about the language is
how I tend to favour Go's error handling over try/catch blocks from
other languages. In my experience, although initially a bit verbose, it
helps me tackling any possible errors where they happen. Somehow in
Python there's the odd exception that I forget about or don't handle
properly, resulting in a runtime crash, whereas with Go I seem to never
have such issues.

On the other hand, sometimes the syntax can look a bit weird, but well,
nothing's perfect ofc. There's much more to say about Go, but before I'd
like to hear from anyone here who actually uses the language. I know
there's a dedicated go-nuts Google Group, but I love USENET and somehow
miss discussing Go here.

--
Vasco Costa

AKA gluon. Enthusiastic about computers, motorsports, science,
technology, travelling and TV series. Yes I'm a bit of a geek.

Gemini: gemini://gluonspace.com/

[meff]

On 2022-04-10, Vasco Costa <vasco...@invalid.invalid> wrote:
> Ever since it came out more than ten years ago it caught my attention.
> Back then I was using C/C++ as my goto compiled languages and Python for
> scripting or anything more high level. Go hits the perfect balance
> between these two worlds. It's easy enough to learn and use, thanks to
> its minimalist approach which I appreciate, free of boiler plate noise,
> very similar to bare C, but crucially comes with batteries included, in
> the form of an excellent standard library. Being a compiled language its
> performance is much better when compared to something like Python.
>
> Performance isn't really what I value the most about Go however, instead
> what really makes it shine for me is its minimalist set of keywords and
> simple approach.

I find that Go's performance is always "good-enough" for me. At work I
work on high availability, low-latency systems and while we don't use
Go that much, Go has had very little trouble scaling. It's GC
throughput is lower than Java's but its low-latency and ease of use
usually trumps anything that we need to twiddle with GC with. In
general if I predict we'll be fighting GC a lot (meaning we can't just
preallocate to avoid GC pressure) then I prefer using a GC-free
language to begin with (like C++ or Rust.) These cases are few and
far-between for us at work and in my hobby work is almost non-existent.

> Something else I must mention on this initial post about the language is
> how I tend to favour Go's error handling over try/catch blocks from
> other languages. In my experience, although initially a bit verbose, it
> helps me tackling any possible errors where they happen. Somehow in
> Python there's the odd exception that I forget about or don't handle
> properly, resulting in a runtime crash, whereas with Go I seem to never
> have such issues.

With errors there's a bit of essential complexity that you can't get
around. A lot of Go haters tend to point to Go's highly verbose error
handling syntax as a negative. My experience using languages like
Rust, Scala, or Haskell which use type stacks to encode errors has
been "safety" with no provenance: an underlying call will fail and
propagate up the call-stack because of type semantics but the cause
for failure will be masked because these languages do not encourage
chaining errors. Exception-based languages like Python (and I guess
C++ but that's another thing altogether) do abort early and complain
loudly. However I find their unpredictability to be vexing and I'm
really over getting paged at 0200 due to some `IndexError` that
bubbles up. Go's `fmt.Errorf` encourages error chaining and I find the
effects heartening in my code and production code I've shipped.

That said I find Go's `nil` value to be a bit maddening. I've
certainly been bit by having `nil` values for pointers that I
overlooked, causing a panic (usually from a library.) I realize that
the historical lack of generics probably burnished this design
decision but I haven't always been happy with it. Even if you train
yourself to check `if thing != nil`, it'll slip through code review
one day and there goes the barn. Fuzz testing should help, but I've
never used it and can't weigh in either way.

> On the other hand, sometimes the syntax can look a bit weird, but well,
> nothing's perfect ofc. There's much more to say about Go, but before I'd
> like to hear from anyone here who actually uses the language. I know
> there's a dedicated go-nuts Google Group, but I love USENET and somehow
> miss discussing Go here.

I love working with Go. I'm usually quite busy in my own life due to a
combination of work, housework+repairs that I like doing, and general
householding with my partner. With Go I can go from idea to
implementation quickly, efficiently, in a readable way. I've even been
able to make initial work on ideas while intoxicated and have the
style hold up to sober scrutiny afterword.

I also find that Go generally helps me focus on the problem I'm
solving and that there's less temptation to solve a problem in an
/elegant/ way. While that produces code that's certainly more
repetitive than constructs from more /elegant/ languages, I find that
it keeps me focused on the end goal of my program rather than the act
of coding itself. If you're the type that likes to code to express
themselves then Go is probably not your language. The lack of
abstraction in Go does make it easy to paint yourself into an
unergonomic corner and probably does lead to more eager refactoring
than a language with a larger abstraction toolbelt would.

If you're interested I can post stuff that I've worked on with
Go. Most recently I've been working on an NNTP frontend for Reddit
which grabs Reddit posts from the API, drops them into a sqlite
database, and serves them up to a newsreader. As a victim of its own
success, I've stalled in adding new features to it as it's useful
enough for my own regular usage. I have a few more NNTP commands I
need to support and it should have full READER capability support. I'm
also contemplating a simple SIP registration proxy so I can use SIP
phones on private networks that I run and I haven't seen anything else
that does what I'm looking for without a huge manual and configuration
surface.

[Vasco Costa]

On 11/04/2022, meff <em...@example.com> wrote:
> I find that Go's performance is always "good-enough" for me. At work I
> work on high availability, low-latency systems and while we don't use
> Go that much, Go has had very little trouble scaling. It's GC
> throughput is lower than Java's but its low-latency and ease of use
> usually trumps anything that we need to twiddle with GC with. In
> general if I predict we'll be fighting GC a lot (meaning we can't just
> preallocate to avoid GC pressure) then I prefer using a GC-free
> language to begin with (like C++ or Rust.) These cases are few and
> far-between for us at work and in my hobby work is almost
> non-existent.

Go's performance is also good enough for me. It's not worth the extra
trouble of using C or even Java, which I also like. Some people often
mention how heavy the GC is, but honestly, for my use cases this isn't
even something I would obsess about. It would be interesting to hear
from someone where performance is so critical that this could hurt.

> That said I find Go's `nil` value to be a bit maddening. I've
> certainly been bit by having `nil` values for pointers that I
> overlooked, causing a panic (usually from a library.) I realize that
> the historical lack of generics probably burnished this design
> decision but I haven't always been happy with it. Even if you train
> yourself to check `if thing != nil`, it'll slip through code review
> one day and there goes the barn. Fuzz testing should help, but I've
> never used it and can't weigh in either way.

Yes, I forgot to mention on my original message that I've also had
runtime issues with nil. Talking about generics, I haven't tried them
yet in go, now that they're available. Anyone using generics out there?
I would like to know if it improved your workflow.

> I love working with Go. I'm usually quite busy in my own life due to a
> combination of work, housework+repairs that I like doing, and general
> householding with my partner. With Go I can go from idea to
> implementation quickly, efficiently, in a readable way. I've even been
> able to make initial work on ideas while intoxicated and have the
> style hold up to sober scrutiny afterword.

Hah, exactly the same here! Housekeeping tasks and time with my partner
represent an important slice of my time and crucially interrupt my daily
flow quite a bit, meaning I rarely have a "lot" of time in a row to
code. With Go I can implement new features in small steps and fully test
it quickly. I certainly take less time than using most other languages,
so this often helps me avoiding putting something on hold while I solve
some other issue at home.

> If you're interested I can post stuff that I've worked on with Go.
> Most recently I've been working on an NNTP frontend for Reddit which
> grabs Reddit posts from the API, drops them into a sqlite database,
> and serves them up to a newsreader. As a victim of its own success,
> I've stalled in adding new features to it as it's useful enough for my
> own regular usage. I have a few more NNTP commands I need to support
> and it should have full READER capability support. I'm also

This is absolutely amazing and something I've also considered doing but
never really took off. Reddit, in a way, is the spiritual successor to
Usenet, at least it's the closest thing I can think of. Please share,
I'd be willing to help if possible.

[Spiros Bousbouras]

On Mon, 11 Apr 2022 22:35:54 -0000 (UTC)
meff <em...@example.com> wrote:
> With errors there's a bit of essential complexity that you can't get
> around. A lot of Go haters tend to point to Go's highly verbose error
> handling syntax as a negative. My experience using languages like
> Rust, Scala, or Haskell which use type stacks to encode errors has
> been "safety" with no provenance: an underlying call will fail and
> propagate up the call-stack because of type semantics but the cause
> for failure will be masked because these languages do not encourage
> chaining errors. Exception-based languages like Python (and I guess
> C++ but that's another thing altogether) do abort early and complain
> loudly. However I find their unpredictability to be vexing and I'm
> really over getting paged at 0200 due to some `IndexError` that
> bubbles up. Go's `fmt.Errorf` encourages error chaining and I find the
> effects heartening in my code and production code I've shipped.

Can you explain what "use type stacks to encode errors" and
"error chaining" mean ?

[meff]

On 2022-04-12, Spiros Bousbouras <spi...@gmail.com> wrote:
> Can you explain what "use type stacks to encode errors" and
> "error chaining" mean ?

Sure. Let's take Haskell as an example for "type stacks" (not because
I think it's the best implementation or anything, just because I'm
familiar enough with it not to make mistakes.) Let's say we want to
return a `String` from a file if it exists. A type signature I'd see
for this kind of function would be `String -> IO Maybe String`. Look
at the result type: `IO Maybe String` is a sandwhich of types. The
outermost typeclass, `IO a`, marks that this operation is an IO
operation. The return type of the IO operation, in this case `Maybe
String` is a typeclass of `Maybe a` which means that the value is
either type `a` (in this case type `String`) or is empty (think of
this as a `nil` value in Go or `NULL` in C or `nullptr` in C++.) In
this case, we've encoded the possible errors in the type stack: An IO
operation ocurred (which may have failed) and that returns either a
String or nothing at all (if the file did not exist.)

If we're doing something similar in Go, error chaining looks something
like this:
```
ok, err := lineInFile(f, "myline")
if err != nil {
return nil, fmt.Errorf("error finding line in file: %w", err)
}
```

What the above does is takes the underlying error returned by
`lineInFile` and then appends "error finding line in file" to the
returned error. What results is the toplevel program returning a chain
of errors which helps the author understand the control flow which
ended up causing this error.

There's nothing stopping Haskell (for example) from having this
chaining behavior as well, but due to the culture around types in
Haskell and its do notation, errors are often bubbled up without
context, so you may end up getting an error like "error: buffer too
small" but you have no idea where the error was generated from.

[meff]

On 2022-04-12, Vasco Costa <vasco...@invalid.invalid> wrote:
> This is absolutely amazing and something I've also considered doing but
> never really took off. Reddit, in a way, is the spiritual successor to
> Usenet, at least it's the closest thing I can think of. Please share,
> I'd be willing to help if possible.

Definitely. Should I just follow-up in this thread? I'll clean up a
few things first. Right now the invocation of the program is muddled
between command flags and a config file so I need to clean that up. I
also need to add some functionality to trim older posts so that NNTP
header data is still available but the article body has been
removed. I'm also planning on eventually separating the Reddit
crawling portion from the sqlite serving portion so that other web
forums can be slotted into the architecture (say Hackernews or
Lobsters) without changing the underlying NNTP serving and sqlite
spool code.

[Vasco Costa]

On 12/04/2022, meff <em...@example.com> wrote:
> On 2022-04-12, Vasco Costa <vasco...@invalid.invalid> wrote:
>> This is absolutely amazing and something I've also considered doing but
>> never really took off. Reddit, in a way, is the spiritual successor to
>> Usenet, at least it's the closest thing I can think of. Please share,
>> I'd be willing to help if possible.
>
> Definitely. Should I just follow-up in this thread? I'll clean up a
> few things first. Right now the invocation of the program is muddled

I think it deserves a thread of its own.