Tomorrow is an announcement of EdgeDB 2.0, and I realized that I’ve never shared my experience with it, and it’s been more than a year since I switched every project I could to EdgeDB. So here is a short post on it.

What is EdgeDB?

It’s an open-source relational/graph database built on top of Postgres.

Unlike many other databases, it doesn’t reinvent the underlying engine and uses battle-tested Postgres. But it reinvents everything else for you as a database user. For me, the two most important innovations here are – query language and tooling.

It’s 3AM of 4th of March, 2022, but it’s just “the eighth day” for Ukrainians. We don’t know what day it is any more because every day lasts at least ten lives.

I was in Kyiv a day before the war started. On Wednesday, I flew to Estonia for a regular business trip. I had only a small backpack and planned to return in a few days.

I’m safe, but everything that makes me me – is not. My nation, country, culture, language, self-identity, people I love and the very right of existence are under brutal attack. Being in safety while millions of Ukrainians are sleeping in the bomb shelters or fleeing is killing me. Why did I choose precisely this day for flight?

The newest release of Go – Go 1.13 – finally introduced full support for Go Modules – brilliant and long-awaited solution for built-in dependency versioning problem. Modules now enabled by default, and virtually make GOPATH obsolete.

Technically speaking, GOPATH is still supported, and Go 1.13 Release Notes uses term “GOPATH mode” (as being opposite to the “modules mode”), but still, to me this is a tectonic shift in the Go development ecosystem evolution. Now you or your static analysis tools no longer can assume that all code lives in one large directory.

This is a blog version of the talk I gave at GopherCon Europe 2019 (Canary Islands Edition), where I shared my thoughts on why Visual Programming Languages have failed and revealed for the first time my experiment on visualizing Go code.

I could dive in straight into the project, but I do believe to truly appreciate it, I have to explain the thought line behind it first.

It starts with an almost existential frustration of working with code as a text.

I’ve recently discovered Flutter – a new Google’s framework for mobile development – for myself and even had an experience of teaching Flutter basics to the person who has never been doing programming at all. Flutter is written in Dart – programming language born in a Chrome browser and then escaped to the console land – and that made me think “hey, Flutter could have been easily implemented in Go as well”!

TL;DR In this article I’ll share my experience building an interactive 3D WebGL-based application for peer-to-peer messaging protocol simulation without writing any single line in JS. You’ll learn how GopherJS and Vecty framework can dramatically lower the complexity of building WebGL-enabled web apps in Go.

It’s often said “A picture is worth a thousand words”, but in the era of high-DPI screens and big data, the new idiom is now truer – “3D interactive visualization is worth a thousand pictures”.

^{(source: Anders Sune Berg)}

In the previous article I’ve described a weekend project called txqr for unidirectional data transfer using animated sequence of QR codes. The straightforward approach was to repeat the encoded sequence over and over until the receiver gets complete data. This simple repetition code was good enough for starter and trivial to implement, but also introduced long delays in case the receiver missed at least one frame. And in practice, it often did, of course.

TL;DR: a weekend project for transferring data via animated QR codes, written in Go and using fountain erasure codes. The Go code is reused for mobile apps using Gomobile, and in a web application for automating testing QR codes parameters, built with GopherJS and Vecty framework.

I’ll share my experience building it, some code and benchmark results of using animated QR as a data transfer method.

On the last Golang Barcelona meetup we decided to try new format of conversation and after the talk started open discussion on logging, tracing and metrics. The idea was to encourage people to read a very nice blog post by Peter Bourgon on this subject - “Metrics, Tracing and Logging” and discuss it in a free format.

It went surprisingly well, and while most of the people were conscious about the topic, one thing seemed to be still confusing - what to log and when. I think we’re all more or less agree that we should log only when program requires human to take a look. It wasn’t a case, let’s say, 10 years ago - there were no ELK, solid solutions for metrics or tracing - we were using logs for everything, then were building “log analyzers” to deal with a vast amount of information. But now, when we have all these best practices, powerful time-series databases, visualization platforms, tracing tools - what should we print to the log?

I used to think that misunderstanding interfaces in Go can lead, at most, to not very readable code and worse maintainability. From my observations misusing interfaces becomes visible usually during refactorings, where you questioning what this type or abstraction actually represents. But, at least, the code tends to work and it’s not buggy.

The bug

But here is the interesting piece of code that actually was buggy:

err := SomeFunc()
if _, ok := err.(MyError); !ok {
    log.Println(err)
}

Quite idiomatic, right? Error type naming is good, following recommended way to name error types and variables. We use here normal type assertion, “extracting” underlying static type from an interface. If an error doesn’t have this type inside, we should log it.