7 comments

[ 2.0 ms ] story [ 31.4 ms ] thread
If you use golang, I can’t recommend reading parts of the standard library enough. Make sure you can jump to source easily! This is true for many languages (less interpreted ones that are partly in C). Given how there are very few ways to do things in go, the libraries are very clear, concise, and performant. For interfaces I’d start at the io or http package.
This comment and the post are actually very helpful, thanks. I hadn’t taken much time to look at io or http from this perspective, but I already see the value. Coming from more dynamic languages, Go has been a little funny to get used to, but I’m seeing the convention very clearly in these packages.
When I picked up go back during the original announcement, it was a breath of fresh air coming for c++. The std library was so easy to follow and understand compared to c++. Go's std library will teach how to write go, how to solve problems the go way and it's very approachable.
Yeah, C++ std was created to be used, not to be looked at, unless one wants to loose sanity ;) Using it however especially with the smart IDE is a breeze for the most part.
This is a bit tangential, but it relates to the post: I'm currently working on a little side-project and I wanted to write (part of) it in Go. As a side-note, the last time I wrote Go was all the way back when I made a few small contributions to the language, circa 2009. As soon as I set up my environment, my gears were already turning (coming from Python, TypeScript, Java, etc.): how should I structure things? Where should this live? What should be calling what, and where should things be passed from and into?

And, like a breath of fresh air, I started remembering how Go works: it's a very simple, stupid language -- in the best possible way -- and it just works. You start writing code, and then you write more code. You write a function. And then you write another one. Slowly, your program gets bigger. Sometimes you need to split up functions.

And that's it. No fiddling with project structure, with taxonomies, and with hierarchies. I forgot what it felt like to just sit down and write some code. I've gotten used to battling tooling, fighting with opinionated frameworks, and having a zillion ways of doing something -- stuck in an eternal analysis paralysis.

I missed Go.

God I need a job in Go. I'm definitely not a coffee person.
This elides the most important thing to understand about interfaces, which is that they should usually be defined by the code that consumes them, rather than by the code that provides things that implement them.