May 4, 2019

Learning C++, day one

A long time ago, I started programming with Python. Everything was great and I was happy.

Then I discovered Go. Everything was fast and portable and powerful.

This is my first day into learning C++.

Why? A SQL metaphor

I used to be contributor to an opensource Go database adaptor: something like an object-relational mapper. Back then, I was fascinated by the idea of abstracting away SQL from my applications.

In my experience, developers integrate ORM-like libraries for two main reasons:

  1. Simplicity. Write applications without exiting the boundaries of the programming language they’re using: SQL is hard to get right.
  2. Portability. Code independently from the specific database, replace mySQL with Postgres with little to no code changes.

However, that concept seemed illusory to me, the more I learned about SQL and databases, and the more I gained experience on real-world applications.

How can you possibly hide the complexity of a database, for so many use cases, under a single abstraction? And furthermore: is it worth sacrificing database-specific features in the name of portability?

Eventually, I’ve come to value much more the return of investment for writing your own SQL statements and carefully tailor the interactions with the database on your specific case.

Generally speaking, I still think that it’s possible and desirable to encapsulate implementation details of a specific behaviour, but I found two fundamental issues with generic ORM-like libraries specifically:

  1. If you really want to know what’s actually going on at the wire level, you’ll need to invest time for studying the library itself. My choice has been to learn a bit of SQL instead.
  2. You’ll potentially miss out vendor-specific optimisations. What if Postgres’ JSONB or geometric types are the most efficient solution to your problem?

OK, enough with databases now. My point is: I want to figure out what’s going on lower in the stack by learning a language that supposedly brings fewer abstraction layers than Go.

Go does an incredibly awesome job in abstracting away the incidental complexity of dealing with memory and CPUs, for enabling safety and concurrency. It has a very simple syntax and its abstractions are impressively well designed.

But sometimes, when dealing with (hash)maps or iterating concurrently, I wonder what it would be like to have more control over the treadoffs between simplicity and efficiency.