How We Became A 'Go' Company

● Highly-threaded scalable server software,

● Recalling C++ as the choice to go,

– Alternatives: java, c#, c

● So … C was chosen

– With proper enterprise support (using XML)

Previous Decade

● creating tons of threads (couple of hundreds)

● memory management hell,

● thread hell,

● codebase grew uncontrolled much of the time,

● (too) much of the time was spent on fixing segmentation faults (mostly memory management issues)

Two Years Ago

We Needed A Hero ...

● Personally toyed with the language a bit before 1.0 release

● Fast, concurred and minimalistic,

● Based on a true story:

me: “hey, what if we try this 'Go' thing?”

boss: “okay, let's make a prototype”

… two weeks later …

me: “here's the prototype”

boss:

Go Language

● Working prototype had 26% less code, fully garbage collected

– some performance penalty (binary network protocol, reflection),

– smooth learning curve, small specs, C-family language

● Next-generation server software 100% written in Go

– debugger-less programming,

– no memory issues at all,

– resulting in 42% less code,

– most of the time, things just work ...

Go Language

Go Language

Okular NetworkManager

Gateway

sock

etsocket

socket

Okular NetworkManager

Gateway

ZMQ message bus (other components)

Unix socket-based IPC

ZeroMQ-based IPC

● Some projects have short life-span

● web framework paradise (goweb, web-go, martini, revel, negroni),

● lesssion learned: choose dependencies very carefully

● Language changes can break dependencies

– Go 1.3 CGO changes totally broke Gtk+ 3 bindings

External dependencies

● Go 1.3 won't allow referring to an incomplete C type from one package to another

– Package a: func CallC() *C.some_struct

– Package b: res := a.CallC()

● Solution: encapsulate C types inside a struct

● Fixing the problem:

– hot-fixing in our fork,

– cooperating with project maintainers

Things Can Also Go Bad

● Often discussed topic,

● Community moves towards godep,

● Tons of other solutions(https://code.google.com/p/go-wiki/wiki/PackageManagementTools)

● We use git subtree:

– early solution to vendor locking,

– easy to pull latest code

Dependency Management

● Binaries without external dependencies work on every compatible system

● In reality, one build for one system

● Tests simply run after build and before packaging (w/o extra web services)

– fails are still properly reported

Deploying

● don't regret nothing

● most of the software is now written in Go (including the whole server software and various web back-ends),

● our python/nodejs devs love Go – prefer Go for some projects

The End

Visionect

• Developing electronic paper products since 2007• 20 employees focusing on epaper development• 11 international awards

Signage solutions developed by Visionect have been working for more than 2 years, and stretch

from ice-cold Alpine ski resorts to scorching hot Australian roads.

Visionect is the only company in the world with extensive

outdoor electronic paper experience.

Visionect d.o.o.www.visionect.com

Luka Napotnikluka.napotnik@visione

ct.com