Even if creating CLI applications is straighforward with Go, there are many libraries to help with that task, specially to handle subcommands and flags. Cobra is likely one of the more popular ones. It’s relatively simple to use and it’s easy to get something working very quickly. A very basic example looks something like this: rootCmd := &cobra.Command{ Use: "demo", Short: "demo shows how to pass a context.Context to a cobra command", Run: rootFn, } if err := rootCmd.

Recently I ran into a curious behavior related to the go directive in the go.mod file. It’s well documented, but it’s nevertheless surprising. Go 1.11 introduced support for modules, as a way to define a collection of related Go packages. You can find details about its use and operation in the documentation. This support has continued to evolve throughout 1.12 and 1.13. A module is defined using a go.mod file, described here.

This is a long overdue follow up to my glibc’s dynamic linker/loader post from last year. With the Go 1.8 release around the corner, which adds support for dynamic plugins, this is a good time to revisit the topic. Plugins in Go are described by Ian Lance Taylor in the “Go Execution Modes” design document. They are part of a larger effort to support dynamic shared objects in Go. As Ian points out, Go 1.

The post “10 LDFLAGS I love” by Jessie Frazelle reminded me that I know a thing or two about the dynamic linker that many people using Linux rarely need, but when they need them, it’s because they really need them. I came by this knowledge a couple of decades ago, back when I was much more active within Debian than I am today. Debian has always paid a lot of attention to handling shared libraries, and the distribution has pretty strict rules as to how to package them, which led me to dig a bit deeper into how this part of the system works.

The “Faneuil Hall” problem comes next in line in “The Little Book of Semaphores” and deals with taking the Oath of Citizenship in the city of Boston: There are three kinds of threads: immigrants, spectators, and a one judge. Immigrants must wait in line, check in, and then sit down. At some point, the judge enters the building. When the judge is in the building, no one may enter, and the immigrants may not leave.

The next problem in “The Little Book of Semaphores” is called “the senate bus problem” and reads as follows: Riders come to a bus stop and wait for a bus. When the bus arrives, all the waiting riders invoke boardBus, but anyone who arrives while the bus is boarding has to wait for the next bus. The capacity of the bus is 50 people; if there are more than 50 people waiting, some will have to wait for the next bus.

The author of “The Little Book of Semaphores” wrote this week’s problem inspired by real life events at Colby College. The problem’s statement is the following: The following synchronization constraints apply to students and the Dean of Students: Any number of students can be in a room at the same time. The Dean of Students can only enter a room if there are no students in the room (to conduct a search) or if there are more than 50 students in the room (to break up the party).

Next problem in line in the the little Go book of semaphores series is about caring for children. It comes from the book “Operating Systems and Middleware: Supporting Controlled Interaction” by Max Hailperin (problem 4.6). It reads as follows: State licensing rules require a child-care center to have no more than three infants present for each adult To put it in a different way: there’s a room where both adults and children are found.

The next chapter in the the little Go book of semaphores series introduces the “not remotely classical problems” and the first one is called “the sushi bar problem”. Imagine a sushi bar with 5 seats. If you arrive while there is an empty seat, you can take a seat immediately. But if you arrive when all 5 seats are full, that means that all of them are dining together, and you will have to wait for the entire party to leave before you sit down.

After that short intermission in reactive programming, it’s back to the little Go book of semaphores series with “the Modus Hall problem”. I didn’t understand the reference in the footnote and after some googling, it turns out that “Modus Hall” is the nickname given to a set of temporary student residence buildings at the Olin College of Engineering where the author of the problem, Nathan Karst, was a student. The problem reads as follows: