Tag: go

Ferric

I spent the past few days working through the first 3 chapters and the first 23 sections of chapter 4 of the Rust book. Here are my initial thoughts on Rust:

    • Cargo is pretty sweet. It’s an easy to understand build and dependency management system. Even though I’m only using it for simple things so far I’m really happy with it and have not run into any issues. I’ve also gotten very used to running cargo new <project_name> [--bin] to start new Rust projects.
    • Compared to Go, Rust is a much larger language, with many more concepts to learn. Go is a simple language to learn. I feel that Rust has a steeper learning curve.
    • Memory safety is one of Rust’s strongest selling points. It is one of the trickier concepts to understand and is unlike anything I’ve experienced in C, C++, Java, Go, Python, etc. I’d say the concepts that come close to resembling it are unique_ptr and shared_ptr in C++11. Consequently I spent the most time on the three sections dedicated to references and borrowing, lifetimes, and mutability. Most of the bugs that I ran into while writing Rust code were also related to these concepts.
    • Rust has generics. This was something I missed in Go.
    • I haven’t gotten used to writing functions without an explicit return yet.
    • The Rust book is very well written but there are a few areas of improvement. My major gripe is that it introduces new language constructs but doesn’t explain what they do. For instance the chapter on trait objects introduces the format! macro for the first time without explaining what it does, the chapter on closures uses a Box to return a closure from a function without going into what exactly a Box is etc.

 

Go pipelines

As mentioned in this talk the main concurrency features Go provides are goroutines and channels. While these constructs might seem pretty simple they are immensely powerful and one can use them to build advanced systems. One such system is a pipeline as described in this blog post. What I think is really awesome about the system described is that downstream functions can signal to the upstream functions to stop producing values, while still keeping the code easy to understand and not horrendous.

Let’s Go.

One of my goals of 2014 was to learn a new programming language, and for various reasons I decided on Go. While my learning progress has been pretty terrible for most of the year, I was able to make pretty good progress this week.

(Chart generated using the awesome pygal library. Code can be found here.)

Screen Shot 2014-09-28 at 11.09.48 AM

What made me get to 40% this month? Several things, but by far the most important one was A Tour of Go.

The tour is a fantastic resource for a person beginning to learn Go. It does a great job of explaining the important language features and constructs, and lets you try Go without having to install Go on your machine. This ability to try Go without having to install Go locally and setup your environment is incredibly powerful (this is how it works under the hood) and is something that I wish more languages incorporated into their websites. With the ability to compile almost anything down to Javascript one does not even have to build a remote sandbox environment (though that is more powerful and robust in my opinion) in order to introduce newcomers to your language.
I feel that the Tour could be improved by adding three things – syntax highlighting to the code in the console, more exercises, and including solutions to the exercises. Apart from that, I think it is a perfect learning resource.

My thoughts on Go? I think it is an interesting language, and something that I will most certainly delving into more. I’d read some Go code before (mostly Docker code) so I was vaguely aware of what the language looked like. I was initially a bit hesitant about the fact that Go has both high level (e.g. functional programming) and low level (e.g. pointers) features, but I think I quite like this ability to have and use both. The concurrency primitives look excellent, and I can’t wait to write some code using it. Another thing that scared me a little was the lack of classes, but structs + interfaces seem to be powerful enough to deal with that. I’ve read online about Go’s lack of generics being a problem, but I haven’t written enough code in Go to comment on this issue. I really liked the fact that the Go compiler doesn’t allow you to compile code that has unused imports or unused variables.

Next steps – read Go by Example and An Introduction to Programming in Go, and begin writing Go code to implement the two phase commit protocol.