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.
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.
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.
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.
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.
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
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.
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.
Can you explain what "use type stacks to encode errors" and
"error chaining" mean ?
On 2022-04-12, Vasco Costa <vasco.costa@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
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 286 |
Nodes: | 16 (3 / 13) |
Uptime: | 86:34:57 |
Calls: | 6,496 |
Calls today: | 7 |
Files: | 12,099 |
Messages: | 5,277,030 |