When making a new path, even in tests, use filepath.Join, not path.Join and definitely not by concatenating strings and slashes. filepath.Join will do the right thing with slashes for the OS.
I see this advice a lot, for every language, but never get it. Windows supports forward slashes just fine. Use them everywhere. All of the bugs I’ve had resulted from somebody inconsistently using both / and \ in different places, mostly by accident but also nearly inevitable. Changed everything to / everywhere, all the problems went away.
I suppose some things might be outside your control (e.g. a base path specified by the user in a configuration file). If you’re in the habit of always using filepath.Join then you’ll never accidentally mix slashes.
The main reason I would use the “proper” backslashes in a Windows application is if those paths are ever displayed or interacted with by end users. Windows users have been trained to expect paths to have backslashes and the forward slashes might be either confusing or, at least, appear slightly off. (It’s a tiny, trivial thing but it feels like a lack of polish to deviate from the platform convention.)
A nice writeup of a sizeable real-world Go application. BTW, Nate Finch was interviewed on episode 24 of Go Time.
I hate to sound critical, but whenever I hear Juju mentioned I wonder who uses it? Outside of Canonical-produced material or interviews with those who work on it, I don’t think I’ve ever heard anyone mention it. As of today, the repo only has 613 stars and 86 contributors, which is fairly miniscule (in contrast, Kubernetes, for example, has 21,739 stars and 1,113 contributors). Yes, fairly meaningless figures, but they do suggest that Juju isn’t particularly widely used?
I was one of the original people hired to work on the Go version of Juju before it was even called juju (there was also a python version before it that they decided to scrap). I think there were six of us back then? Nobody uses juju, I certainly would not use it and would recommend anyone to stay away from it.
The juju abstraction is fucked, and the tech decisions that went into it are even worse. Not sure what’s happening now, but when I was there (I left before Nate joined) we replaced Zookeeper with MongoDB. How do you replace CAS-based system with something just barely better than /dev/null? Very easy, you see Zookeeper has a mode of operation where you can ignore versions and just inconsiderately ram the data in. I don’t know why they have this option, or why they have it so easily accessible, but that is what we used. We didn’t use any abstraction that made Zookeeper Zookeeper! So yeah, it was easy to port to MongoDB.
Funny thing is at some point we needed to have containers. This was before docker. Lxc was available, but lxc was pure garbage and impossible to use from Go correctly for various reasons I won’t get into now. So I did the most obvious thing, I implemented tooling for Linux containers in Go. In one hour I was booting Ubuntu, and in one afternoon I had functional networking plus basic tooling. This happened at UDS in Copenhagen so many people can corroborate this.
The tech lead said that we had to abandon this because we can’t have internal competition inside Canonical with the lxc guys. One month later, some other people dissatisfied with lxc also implemented tooling in Go for it and called it Docker. The rest is history.
I left Canonical very shortly after as it was obvious they didn’t have a clue about anything, and it was a toxic workplace. In a way I am happy they didn’t go with my implementation, as the lack of it paved the way to Docker which ultimately caused Juju’s demise. They deserve it.
To add a few thoughts, I find it interesting that juju is a textbook example of both solving the wrong problem, and of death by technical leadership. When project die, the reasons are usually complex and you can’t pinpoint a single thing that went wrong, but I think with juju, you can, and I find this quite unusual.
When we were hired to do the implementation, Go was a very new language, with very few people in the community, and most of us were very good programmers. All of us in the team were very good and very experienced. Not just as implementors, but people with good vision, good engineering taste and people who truly understood the Go language and its philosophy.
Mark Shuttleworth pretty much stayed out of our way and let us do our thing.
And yet, this team of excellent people unhindered by management produced this turd. That’s fascinating and it’s only because of our technical team leader. It was a dictatorship, and all the decisions were wrong. And that is pretty much all there is to it. Just one mad man driving it to the grave.