Initializing channels in Go

With most variables in Go we can declared them in a couple of different ways. Using the var keyword, initialize them as we declare them with the := operator; or using the new or make keywords.

Most variables can be declared with var, which only reserves storage for a named variable. If no assignment accompanies the statement, the variable is set to it's zero value. Using var to declare a channel crates a nil channel. The underlying header is created, but there is no backing data structure. If we use the make keyword we reserve storage, initializes memory, and create the backing header for the specified type.

Declaring variables using var reserves storage and initializes with a Type's zero value. Channels work this way too, they are initalized to a nil channel. Which we could use if if we have an existing channel we want to assign, or have a function that creates a channel we want to assign to our named channel. Sending or receiving on a channel does not initialize it.

In most cases we will want to use make when creating channels to use ourselves.

View on the golang playground.

Continue reading ...

fmt.Scanf Introduction

From the fmt package; the Scanf function is used to read input from stdin. When you run this snippet of code the main() function will wait for user input a string, a number, and a second string. Which it puts into variables, and then uses to print some information.

Scanf woul be used when you want to write a command line program that requires user input during the running process.

var s1   string
    var s2   string
    var rint int

    _, err := fmt.Scanf("%s %d %s", &s1, &rint, &s2)
    if err != nil {
    fmt.Println("this is the first string from the commandline: ", s1)
    fmt.Println("this is the first int from the commandline: ", rint)
    fmt.Println("this is the second string from the commandline: ", s2)
Continue reading ...

Firefox to integrate Pocket

I was shocked when I saw news of Mozilla's Firefox native integration with Pocket; the popular read-it-later bookmarking service. This is the first time I can remember when Mozilla has integrated a commercial third-party service. It feels a little odd.

I understand why they might have done this. My guess is that Pocket is another revenue stream for Mozilla. I can appreciate the need for money; it keeps the employees happy, and the Firefox updates rolling out in a timely fashion. Not to mention funding research projects like Rust and Servo that are very exciting for the future of the web.

I can understand this, and yet it still feels weird to me. Not bad, or too uncomfortable, just a little odd. Still, that is how the slippery slope starts, with a slow steady boil. This the part that makes me feel the most ill-at-ease; how long until the next commercial integration.

Frederic Lardinois writes in TechCrunch

Mozilla probably could have built this kind of service from scratch, but must have decided that supporting applications on these different platforms from iOS to Kindle and Android to Windows wasn't what it wanted to do.

I would have preferred Mozilla develop their own solution, but Pocket was an easy choice. They have the servers, and the service; built, ready, and working. Their brand in this niche does not hurt either. It looks to be a win-win for both sides.

So in truth it is a benefit for those who use both, and not even an annoyance for those who do not. My hope is that this weird feeling I have fades away into nothing; and the cause of it, becomes but a footnote in the long, free, and open source history of Firefox.

Continue reading ...

Building Go projects with gb

Sähköä ilmassa sunset behind power lines
Image courtesy of smerikal

gb is a new build tool for Go created by Dave Cheney. It address the problem of reproducible builds. Building the same functional binary anywhere at any time is a problem of dependency management. Of knowing exactly which library version to use, and having it at hand. gb is a radical tool compared to current dependency solutions, which work with the existing Go toolchain and idioms. gb takes a different approach, it replaces not only dependency management tools, but the Go build tools themselves. Instead of using go build or go install you would use gb build.

Dependency management in Go has always been a little wonky, a little weird. From the beginning there was go get but no other specific tools or process. go get infers a location from the import path about where libraries live, and grabs them. Placing them ever so lovingly in the src directory along side project code. go get knows enough about DVCS to grab the HEAD code, but not much more. There are no options for specifying which, if any, versions should be used, or commit hashes to checkout. The idea was to simply keep everything up to date manually. Keeping everything at HEAD sounds nice, but in practice it has proved problematic.

Continue reading ...

Understanding Go Dependency Management

lego blocks, dependency management
Image courtesy of kreezzalee

Right now there is a discussion thread on the golang-dev mailing list about formalizing how Go manages dependencies. The Go Team is putting forward that Go use vendoring to manage dependencies, and asked the community to formalize a configuration format that tools can use to manage vendored code.

Continue reading ...