Advent of Code 2023

Happy New Year!

Advent of Code rounds off every year since 2015. This year I tried my hand at Go, because as a Java, JavaScript, and C# developer (not all at the same time), sometimes I look and say “Yeah, I really should learn Go.”

This was the year, and I’m happy to report it went pretty well

I learned Go to an extent, I built a programming habit, and it wasn’t too bad of a time. This what I learned from this Advent of Code

Advent of Code is Pretty Great

I’ve been programming for over a decade now, and I’ll say that it’s still fun to code. Advent of Code proved that to me this year.

First, a little about AOC; it’s a programming challenge spanning 25 days. Like an advent calendar of text-based puzzles. It’s a yearly thing that I only started trying this year (that is December / January 2023-2024).

If you haven’t tried it, it’s one of those phenomena that you need to experience. If you’re a programmer you should appreciate the problem space. Perhaps uniquely, Advent of Code is only text and math-based inputs and outputs. This effectively means that any programming language, and many non-programming tools can solve the daily problems. People have solved Advent of Code using Excel, Regular Expressions, and the usual candidates.

The Problems are difficult enough that the answers are not trivial, and the solutions are complex enough to need some brain power. Plus, if you do get stuck, it’s possible to get help from the community.

The last thing

Golang

I have thoughts about Go as a language. I picked it up incredibly quickly, and I was getting stuff done out the gate. The gomod system seemed nice the few times I actually needed to use it.

TLDR, it’s o.k. but I’m not in love with it, which is strange.

Things I like

Go is fast, it’s got pretty good syntax. Go feels familiar like Python and Javascript while also having the speed that a compiled language should have. After coming back to lower-level languages from the likes of C#, Java, JavaScript and the dreaded Python I had forgotten how quick things were when you actually compile them.

Slices are cool and work nicely; I never felt like I needed to dive into arrays to optimize, and the slice syntax is convenient enough that it felt like complicating things to go outside

It’s cool to have a formatter, compiler, and testing as core in the library. Installing packages from git repos is cool

The syntax is good, and it feels almost as good as Python. Maybe Python feels better because it doesn’t complain until you have catastrophic failure, or maybe it’s because the standard library saves you from everything and is very homogeneous. I’m not sure, but writing Go always feels like I’m writing more than I’d expect. Not as much as Java, but more than other languages. I’m not convinced this is bad, so that’s why I’m putting it up here. If there’s one right way to write something, and it’s easy to understand, that’s a good design.

I like Go error handling, at least the errors as value part of it. It’s good - and naysayers who don’t like having to assign errors are wrong. This comes from JavaScript where errors can just float around the codebase without ever telling you they could be there. The problems with the error handling mostly come from the weirdness of variables.

Things I am “On the Fence about”

no ternaries - ternaries get abused a lot, and I don’t miss them that much.

Why did it take until 2022 to get Generics? Who can say, it wasn’t important, but the community recoil from it is so strange. Usually when people see things in go they don’t understand the gophers basically respond with some variation of “get good,” or “it’s simpler,” but with generics allowing some repetitive cases to be broken down it’s not the case. Who can say why, but the few passionate gophers about things also don’t like nice things.

Finally, Golang doesn’t really like packages. I can’t really tell if the gomod system was supposed to fix it, but the hostility seems to still be there, unless you were also making them. I feel like there should be some happy medium between the Javascript Madness and Go, but I think Go is more right than wrong.

Things I don’t like

Why is every go binary so large? Why does the go community not really talk about it? Well they do but they dismiss all questions about every binary being 1.9 MB at least as nothings, with such insights like “we have TB hard drives” or “it’s not as bad as it could be,” e.g. which is a neat way of saying we don’t have the ability to do any better. I’m not interested in diving in to yet another flame war, but it’s strange to me that this really doesn’t get any traction without completely dismissing the issue as a non-problem.

Is binary size a killer for Go? No, not really, but you can’t use it in some situations and if you need to move binaries around you’ll probably need to think about just how heavy these programs are.

Apparently you also get private package symbols being shared, so it’s the worst of both worlds. Fortunately, I didn’t ever run into this problem

Allowing uninitialized variables: this just seems like dogma wrapped up in ego. Gophers will often say that you don’t need to do this, because what else could a variable be? But what it feels like is we’re just accepting that sometimes code does what it wants because that’s “simpler.” I don’t think they’d lose anything if we required variables to be initialized, especially for more complicated types where it’s not always obvious what the “zero” value should be. The simplicity of it is that you can write bad code faster, because you can make a bunch of dangling variables. Gophers might also say something like “just don’t do that,” which is a common trait of the community. If you could have a tool that has 0% chance of shooting your foot off, it would be better than the one where it’s possible to happen 1% of the time - and there’s not really a downside here besides a loss of “simplicity.” It’s like saying taking the safety off of a gun is better because there are fewer moving parts.

At best, you feel clever. At worst you have a bug because you forgot that “something” happens by default, rather than actually nothing.

The worst part about variables acting this way is that combined with the error handling, variables having their nil value and after assignment not being able to use the := assigner, means that if you’re working with a lot of error-possible code you’re going to have to make a bare err variable.

the UpErCaSe Is ExPoRt is a bit silly. This is probably bias from my typescript experience, but I don’t like it; for me it made it difficult to know what was leaving the module. Even if it is “simple” you do give up a control you have in other languages.

Modules being dictated as single words is not great. It has the upshot of saying you can’t really express anything that’s more complicated than 1 word, but it also means you’re limited if you choose to actually follow the advice here. And the community saying that you should use single-character variables for most things is not a good in itself. I’m not going to say from on high which variables require multiple words, but I do not abide by the madness of most things having only two letters, simply because we can’t shadow in this language.

If you couldn’t tell, I’m not a fan of the go community: most times they feel generally helpful, but sometimes it’s just annoying, especially when you want to change anything about thier language. I’m not saying many things should, but there’s no point arguing about go: it’s best because it’s simple, except when it’s not and it’s actually bad.

It’s a New Year

I’ve been pursuing atomic habits with some friends, and so far it’s been going great! I’ve been programming daily and the key has been to keep it small. Advent of Code supercharged and kicked it off this year; the problems aren’t always something I can knock out in 1 day, but they’re digestible enough to at least attempt every day.

If you’ve already fallen off the resolution bandwagon, maybe try picking up coding a little every day - even if it’s just opening the editor. My takeaways from the very begining of this year are to pick up a habit, and to try to have fun doing what you do.

Why Do AOC?

Advent of Code is one of those things that people say “I should do that,” and then never do. Why should you? It’s chalk full of problems that only need simple tools and yet are decent head scratchers. Seriously, there are some tricky problems in Advent of Code.

If you haven’t done AOC, the cool thing about it is that the previous years are still open; you can cut your teeth on these problems, and I’m actually using this opportunity to pick up a new language and try it out. Maybe I’ll write about Advent of Code 2022 in 2024!

Why Learn Go?

I’m not sure you should! I did because there are a few projects I want to work on that use go. Go as a language feels like it has a good premise, and a decent core. Go isn’t fundamentally exciting, and that’s good and bad. It’s probably a great workhorse language - I don’t personally use it for work, so it’s hard for me to really evaluate that.

Why you should:

• If you’re into web services, concurrency, or small tools it’s an excellent choice
• If you have a project written in Go that you’d like to contribute to
• You need a compiled language that’s simple, easy to read, and quick to write

Why you shouldn’t

• You need WASM (though it’s getting support), assembly, or other specialized runtime environment. Go requires that you live in it’s special world for reasons.
• You want a complicated, challenging, or a difficult language. Think Haskell for your first functional language, or Rust, or C++. These languages are deep, and can become amazing tools after putting in a lot of work.
• You don’t like google, and think they’ll kill yet another project. I’m not sure they could entirely kill go, but they might try.

I’m overall on-the-fence when it comes to Golang, and I don’t really see many go zealots. That feels like a pretty good thing, but I also don’t see a lot of passion from anyone about the language. Most discussions about the language resolve to “it’s too complicated to add a feature,” or “just rewrite It’s a mild community, but it’s also a stable one. Some people might not want that.