I confess I am late to the game: the Go programming language came out in 2009 and I had not had the chance to go all in for a real project until two weeks ago. Here is a summary of my experience. Spoiler alert: I’m truly pleased.

The project

What I set out to build is a read-only caching file system to try to solve the problems I presented in my previous analysis of large builds on SSHFS. The reasons I chose Go are simple: I had to write a low-level system component and, in theory, Go excels at this; I did not want to use plain C; Go had the necessary bindings (for FUSE and SQLite); and, heck, I just wanted to try it out!

It only took me a little over two days to get a fully-functional implementation of my file system, and this is without having ever written a FUSE-based file system before nor any non-toy Go code. That said, I had previously written a kernel file system in 2005 and that helped navigating the whole endeavor and tuning the resulting performance.

Where is the code you ask? Nowhere yet unfortunately; I hope to make it available once it is ready.

The Go language review

The summary of what follows is simple: after two weeks, I’m in love with Go.

I remember languages people dismiss Go back in 2009 on the grounds that it was a simplistic language without novel concepts… but there lies its beauty: Go lets you get things done quickly and safely with few performance penalties. I feel I can write much more robust code with Go than with any other comparable language.

Disclaimer: Keep in mind that I’m still a newbie. I’m sure that some of the items below are naïve, incomplete or plain incorrect. If so, please let me know!

The good

The bad

The ugly

A note on Visual Studio Code

To conclude, let’s talk about editors. I’ve been a long-time Vim and Emacs user and now decided to give another editor a try. Heresy!

In fact, some time last year, I started playing with Atom after all the hype around this editor. It really is full-featured, but it also is overwhelming and fragile: overwhelming because there are knobs everywhere and fragile because I had never had an editor throw errors at me routinely during “normal” operation. (I’m sure I can blame some plugin I installed, but still.)

Soon after, Visual Studio Code (VSCode) came out: an open source editor from Microsoft no less. I installed VSCode just to take a look and I found much sought simplicity: just look at the way to configure the editor, which is by adding personal or project-specific overrides to an empty JSON file. I felt I’d enjoy this editor more than Atom though I did not have a use for it at the time: most of my development still happens over SSH so VSCode would not fit the bill.

This experiment with Go gave me the chance to use VSCode, particularly because I was writing the project primarily for OS X (my desktop) and because I wanted an IDE-like experience. As it turns out, VSCode has a pretty good Go plugin. The reason I wanted IDE integration is because writing code in an unknown language with an unknown standard library is a task that truly benefits from autocompletion and inline syntax validation. I wouldn’t have been able to prototype my file system as quickly as I did with a bare editor.

I know, I know, I could have set up Emacs to do the same thing, but I just wanted to give VSCode a ride. And, mind you, I just took a look at what’s involved to set Emacs up for Go and didn’t find it pleasing; way too much manual work involved.

Do you Go already?

Subscribe via RSS · Go to posts index

   Delivered by FeedBurner