1. 9

  2. 11

    TL;DR: “We don’t understand how the JVM works and Go was the language which allowed people to contribute without spending too much time learning the necessary tools.”

    1. 9

      “Why we chose X” blog posts are almost always great if you like X and a complete letdown if you don’t like X. In this case, if you like Go then yay, this blog post confirms all your existing beliefs. If you don’t like Go, the reasoning given confirms all your existing beliefs.

      From a pure logic perspective, I think their argument is weak. They give a list of languages that one can write distributed systems in, now claim that it is a “fact” these are the best options, then claim Go beats the other options for various reasons. This is difficult to distinguish from “here is a list of languages I’m aware of and I like this one the most”.

      1. 3

        It’s at least some sort of progress since most of “Why we chose X” I see is about syntax, presence/absence of semicolons, etc.

      2. 3

        Java’s known performance issues made it unappealing

        What are the supposedly known performance issues in Java compared to Go?

        When comparing to Java, we appreciate the tight focus on implementation instead of OOP and abstraction: interfaces can be added when needed, not as an initial, often unnecessary, step.

        How are interfaces in Java required when they are initially unnecessary?

        1. 1

          Java has a heavy (slow) startup. Especially with the 64 bit “server” vm I found it unbearable to develop with. Or trying to do anything with less than 1GB of ram. Go seems to perform much better (or at least responsively) on modest hardware.

          Some numbers for context. OpenBSD/amd64 with go 1.4 and jdk 1.8.

          Java “hello world” takes 0.2s to run. The go version takes an unmeasurable 0s, but if I write a shell loop, I can run it 100 times in 0.2s.

          Java uses 20M ram to start, go uses 1M.

          1. 3

            The JVM isn’t great for smaller utilities and scripts because of the startup time and base RAM usage, but are those really important performance considerations for a database? Postgres is written in C and takes on the order of seconds to start up, not milliseconds. Unless I’m misunderstanding how CockroachDB is intended to be used, db servers seem like the kind of long-running software where you’re more interested in steady-state throughput than startup time.

            1. 1

              It matters less as a user, but as a developer contemplating what to use for my next project, it makes a huge difference. I think “java is slow” is a pretty tired meme, but the tooling necessary to make it fast doesn’t fit my dev style either.

              I don’t really have a clue about cockroachdb, but I guess I could imagine wanting to run it on a cluster of raspberry pis? In which case maybe you’d care a bit more about the overhead.