I’ve been working with Go(for work) and Rust(for fun) lately. I got pulled into the two languages for different reasons (easy concurrency and memory safety respectively) and ended up staying for a totally different reason altogether. Their type systems.

Composition instead of inheritance feels elegant, right and very readable. I’m going to talk about something that happened today when I was very thankful for composition and typing itself.

A colleague and I ran into a problem that quickly devolved into an argument and as it is with professional software engineers, wanton namecalling. For work, I’d written a common request making library. It wasn’t anything special. It would branch off of a http.Client and make requests and responses and parse them to specific interfaced outputs that we used for our internal client sdks.

Ever since Tensorflow released Bindings for Go, I’ve been itching to give it a go. The ease of deployability with Go and microservice friendliness and even simple http performance improvements make it really handly to build a working prediction application with Go.

The immediate and apparent downside for anyone who’s tried to train a model is how unintuitive scoping is with Tensorflow for Go.Python’s a lot easier to train models with for a newcomer because of a lot of things:

Ever wake up on the symmetrical side of the bed? Like at the middle? Yep. ThatÕs when you decide that you are never going to (ever) code in constants in your application. So how do you get them? Configuration files? JSONs? Yamls? Environment variables are more elegant and easier with a docker-compose no?

12 factor apps are what cool kids are doing these days (read three years ago). And it makes sense that you put your configurable variables into the environment and do a getenv. But what happens when you have twelve twelve factor apps with twelve different sets of environment configurations?