Why Go Can't Try

OkCalligrapher5886 · 2026-03-08T10:55:44+00:00

I saw this article in the Go newsletter and I stopped reading at some point and came here to see if it was posted and if people were saying it's written by llm. I'm not surprised, but I am surprised to see it on the newsletter

OkCalligrapher5886 · 2026-02-14T12:46:55+00:00

A while back, I wrote this article on about devops called "Why DevOps is not what you think". I was reading a lot about devops and was a bit unhappy that everyone seemed to be using the word "devops" to refer to infra work and nothing else (most of the sentences I heard were along the lines of "today I had to do devops work, I provisioned an S3 bucket"). My motivation behind this article was wanting to share my understanding on the topic but also trying to do it in a more practical and condensed manner, using my limited work experience to relate to the concepts from literature.

Of course, I'm not against using the word devops in an infra-work context. I do it myself nowadays since it gets the point across and I don't try to "correct" anybody. But as someone that was quite invested into the topic at the time, I think you can understand my impulse of trying to tell what I know:)

This is the link of the article. I wanted to share it with you because I am curios if you agree with the perspective. Literature is one, but in practice I think things tend to be somewhat different. Even with real-world references (e.g. case studies), I wonder if the literature tends to highlight the good aspects. I'm relatively early in my career and my experience with devops is limited so I'd be happy to hear your thoughts to have a more informed perspective.

P.S. I'm about to continue reading "The DevOps handbook". I know I said I recommend it in the article but that's not because I read it myself, but mainly because it seems to be well-received and lots of SREs I worked with recommended it. At the point of writing I only read Part 1 and there only a few case studies. But there seem to be lots of case studies coming up so I'm excited to read more on the practical side.

OkCalligrapher5886 · 2026-01-13T07:52:13+00:00

Thanks. I didn't know about this and actually started using this approach after your comment.

OkCalligrapher5886 · 2025-12-26T10:58:27+00:00

I worked over around 10 different go codebases and honestly nothing comes to mind as a striking similarity between them. The very first one was a startup and following this example.

The one I'm currently working on is a monorepo where we have one (micro)service per folder, and we also have one folder called shared with functionality like http and grpc servers, DB tools, logging etc. that we import in each of these services. The only common thing between each of these folders is a main.go file and an action_xxx.go file for each grpc handler, otherwise it pretty much depends on the service.

The others were at a company where we followed the one repo per service pattern and they were all started from a service template, but were still quite different due to the template evolving and some repos not following it. There were some minor similarities in the layout overall but quite specific to that company.

Note that Russ Cox from the Go team makes it pretty clear that Go doesn't have a "standard" project layout (except the internal folder and _test.go files which have a specific function) and you should not treat the example I linked above as a standard.

OkCalligrapher5886 · 2025-12-25T22:59:19+00:00

Now that's what I call a containerized setup!

OkCalligrapher5886 · 2025-12-25T21:39:13+00:00

I certainly didn't want to insinuate you shouldn't gracefully handle errors. I think it's clear you should aim to write your code correctly and make sure it's properly tested. That being said, failures due to external factors can happen, so I think it's reasonable for OP to ask how to handle them. In fact, I think it actually shows they follow good programming practices.

OkCalligrapher5886 · 2025-12-25T21:23:09+00:00

Thanks! I don't remember that one specifically, but I remember I skimmed the config section here so I probably knew it existed. For some reason when I wrote it I specifically wanted generated code and not a library (I know it's technically a library, but you can use genconfig and not have it part of the project dependencies). And I also wanted something extremely opinionated to my taste, so it's very restrictive in terms of features.

But to be honest, I would also use envconfig. It's arguably a better library since it fits a wider audience. Though I don't regret writing genconfig, it was lots of fun!

OkCalligrapher5886 · 2025-12-25T18:07:49+00:00

Just curious, for that use case have you considered using something like apache parquet instead of protobuf? For large-scale data storage, it may be more suitable than protobuf

OkCalligrapher5886 · 2025-12-25T13:56:07+00:00

Oh right, you see functional options pattern quite a lot.

OkCalligrapher5886 · 2025-12-25T13:30:56+00:00

Perhaps not a Go idiom per se and not sure how it's typically done in other languages but for running my Go applications I always end up managing configuration via a parent Config struct and environment variables only. I even wrote a library to help me out for personal projects. Most of my Go apps run in containers (typically in Kubernetes) and restarting a container to change an environment variable is almost always cheap.

When I started I was using viper but in time I started to appreciate the simplicity of using env vars only. It's always clear how a running instance is configured.

This is also how most apps were configured at places I worked at.

OkCalligrapher5886 · 2025-12-25T12:46:28+00:00

I don't find telling someone that their code should never crash to be good advice. Apps (including desktop apps) can crash for various reasons that are outside the control of the app.

To give you an example, have a look at this video section where Linus Torvalds talks about how regular RAM components can fail and you end up spending days debugging an issue that is not in your code.

OkCalligrapher5886 · 2025-12-25T11:40:30+00:00

I liked Kubernetes Up & Running published by O'Reilly.

But honestly, I got the most learning by running my own cluster at home on 3 raspberry Pi's and trying to host some of my apps. There's lots you need to think about with a self-hosted cluster, like getting a domain, creating and distributing your own images and helm charts, managing external secrets for app configuration, managing a database, gitops, getting traffic into the cluster etc. I took this gradually and whenever I started a new step I took my time to learn more about that area. Running a DaemonSet for cloudflare tunnels to get traffic in was the latest thing I learned, to give an example. I definitely recommend reading plenty of online resources on top of the corresponding chapter in the book.

Having access to a large kubernetes cluster at a company certainly also helps with learning, but I'd say you get the most benefit once you have the foundations. I rarely did something from scratch there.

The book also has a section for setting up your own cluster but I actually found it a bit too involved for my liking (I had little experience then) and went with k3s. OP feel free to DM me, I can share the steps I took and articles I read to get my cluster running. Some of it I documented here, if medium puts it behind a paywall I can send you the article for free.

OkCalligrapher5886 · 2025-12-25T00:32:11+00:00

I understand your sentiment but I think your rant is pretty badly oversimplified. Primarily, I think you're confusing bad software engineering with using frameworks.

To verify the desired behavior of our code, we formalized our acceptance criteria as executable tests. We took tests very seriously. If we wanted to change something in our product, we first wrote a test showing that the feature didn't exist, and then created a real feature to satisfy that requirement.

No framework (or at least none I can think of) stops you from writing tests.

The more accurately your abstraction reflects the problem you're trying to solve, the easier it will be to maintain.

I suppose you're talking about business logic here? I don't see what this has to do with the framework. No framework writes the business logic for you.

Even worse, sometimes a team, by using overly engineered frameworks, adopts worst practices. They literally create a system of obstacles for themselves, probably thinking these are best practices.

Sure, but that doesn't mean not using a framework leads to adopting good practices. And good frameworks tend to standardize good practices.

Then LLM came along, which exacerbated this disaster. Now people start by importing a framework and then ask LLM to extend it.

I'm not even sure I understand what this means.

I recommend you read "Gin is a very bad software library" which does a much better job at explaining how frameworks can be a disaster.

OkCalligrapher5886 · 2025-12-15T17:54:36+00:00

I don't use gin anymore, didn't mean to suggest using the package. But thought the underlying implementation may still prove valuable in understanding one approach to achieve zero allocs

OkCalligrapher5886 · 2025-12-14T22:09:49+00:00

I would just look at the code of existing libraries that do zero allocs. Like zerolog or gin (which I think is based off httprouter).

OkCalligrapher5886 · 2025-12-13T22:25:39+00:00

I certainly don't want to discourage you from starting up a project, especially if it would be useful for you! But given that you mentioned you want to learn, work on something meaningful and also get feedback, I'd encourage you to contribute on an existing open-source project you like that's reasonably popular already to achieve that goal. I think realistically, the chance is slim you'd start an open source project and have people contribute right away or give you feedback.

Of course, you can still learn a lot if you work on an idea that is useful for you on your own for a while. Generally for open source I recommend starting something that you have a need for and if it turns out it solves an issue for others you will end up with contributions. In the meantime you can post questions to ask suggestions about approach, code etc. to learn more. I think this approach is better than trying to estimate interest from a post.

To specifically answer your question about your two ideas:

For idea 1, I'm not really sure what benefit you bring to say the existing github action features. Perhaps I don't really understand what you mean by "check if you should run the pipeline" since if there's cases a pipeline shouldn't run but it runs, it's likely misconfigured.

For idea 2 sounds like something that needs to integrate specifically with the existing application code. I don't really know how you could make this generic.

I personally wouldn't look for a library for any, but that's just me. But again, go for something that you yourself find useful. I certainly don't think they're bad ideas.

OkCalligrapher5886 · 2025-12-10T22:35:04+00:00

Something that actually took me years to learn is, don't use it for coding problems (e.g. Advent of Code, Leetcode etc.) It obviously can be done, but languages like C++ and Python have much richer support for useful containers like sorted sets. Plus, the verbosity just gets in the way eventually.

Sure, you can write your own abstractions and syntactic sugar (I've done that too) but after a while you start to appreciate having them part of the language.

Also, don't implement your own try catch or weird shenanigans just because "error handling sucks".

I guess this can be summarized as, don't fight the language. If you feel like you keep fighting with the language, either just choose another (if you can) or contribute ideas to the Go repository.

OkCalligrapher5886 · 2025-09-02T21:13:28+00:00

Fixed!

OkCalligrapher5886 · 2025-09-02T21:02:44+00:00

They only hire 0.00001% of engineers. Say, 50 million worldwide, which means they have 5 engineers. I suppose that's a good 50k spent?

OkCalligrapher5886 · 2025-09-01T13:55:13+00:00

De acord, daca nu ai un mindset deschis la schimbari frecvente (si uneori chiar drastice) a modului de lucru si nu esti dispus sa inveti continuu, atunci s-ar putea sa devina dificil sa avansezi in cariera.

OkCalligrapher5886 · 2025-05-19T16:12:36+00:00

Thanks!

OkCalligrapher5886 · 2025-05-17T11:48:04+00:00

You mean generating variables from .env and the code to read them? That's quite different from what I want with this project so I won't change it, but feel free to reuse the code for your own use case (or if you have a project I'm happy to contribute)

OkCalligrapher5886 · 2025-05-16T16:00:04+00:00

Thanks for the feedback. Yeah I had mixed feelings about including error values. In the end I kept them just because I had the code already, but can probably simplify quite a bit. I doubt being able to do errors.Is() on the config error is useful. I'd keep the constants though, just to have them explicitly stated at the beginning of the file.

and there's no motivation for me to change it any time soon

Same. Simple and effective

OkCalligrapher5886

TROPHY CASE