
Why Go Was the Right Choice for CockroachDB - scapbi
http://www.cockroachlabs.com/blog/why-go-was-the-right-choice-for-cockroachdb/
======
readams
The article seems to make a lot of very dubious claims about Java. Especially
when they started this project, Java performance was much better than go
(Those double-digit second GC pauses weren't a concern with go?), and the Java
garbage collection remains much more sophisticated than even current bleeding
edge go.

Also the claim that you have to add extra interfaces to Java is completely
false. There's no reason at all you need to add pointless interfaces in Java.
Java's type system is strictly more powerful than go's type system. This was
actually a design choice in go to make the language easier.

Java generics are also a huge boon when writing something like a database.

Modern C++ also would have been an excellent choice for writing a database,
and would have been much more productive than go.

~~~
arthursilva
> Modern C++ ..., and would have been much more productive than go.

This is definitely not correct. Any GC language with even the most basic
packaging support (go get etc.) is miles ahead of C++ productivity wise.

~~~
maccard
Why does package support make it more productive than c++? For most c++
libraries you download the source, build it (platform dependent) and set
includes/libs and youre done. More so, you only tend to mess with dependencies
infrequently, so who cares if it takes an extra 5 minutes once every 6 months?

------
schmichael
"Perhaps most telling that Go is a good fit is that a lack of previous
exposure to the language has not been a barrier for contributors"

This. It's true at the 100% Go backend company I work at that's never hired
anyone with Go experience, and I've heard many others repeat this mantra.

While many people like to think of Go's lack of features in the realms of
packaging, types, syntactic sugar, etc. as downsides, they're huge upsides
when learning the language. There's just so much less to learn. Onboarding a
new Go developer takes days, not weeks or months.

------
fasteo
>>>>> Java’s known performance issues made it unappealing

I have read this many times and every time I read it and it seems to me that
this is just a rationalization, probably an unconscious one:

"Offering false or inauthentic excuses for our claim because we know the real
reasons are much less persuasive or more embarrassing to share, or more harsh
than the manufactured ones given." [1]

Maybe not the case in this particular instance, but every reason I have heard
about choosing Go can be summarized as: "We chose Go because it is new new
cool language. Ahh, and you can deploy by copying a single exe file"

[1] [http://www.logicallyfallacious.com/index.php/logical-
fallaci...](http://www.logicallyfallacious.com/index.php/logical-
fallacies/150-rationalization)

------
akbar501
In case anyone's interested in trying CockroachDB, I have been writing some
docs on how to install it, use the SQL commands, etc. So far, I've found it's
easy to get started with if you're familiar with another relational DB,
although its definitely still (pre)alpha.

CockroachDB docs:

[https://www.grockdoc.com/cockroachdb/alpha/articles](https://www.grockdoc.com/cockroachdb/alpha/articles)

FYI: The installation docs are at the bottom of the list.

------
sportanova
A little late, but why not Rust? Not the right libraries? I would think no gc
would be one of the biggest factors

~~~
bdarnell
CockroachDB engineer here. Rust would definitely be a contender if we were
starting the project today (we have several rust fans on the team), but when
the project was started in early 2014 it wasn't ready yet. The language was
still changing too much to make such an investment in (they hadn't even
removed the @ and ~ pointer syntax from the language yet).

~~~
erickt
Longtime Rust developer here. You definitely made the right choice, it would
have been a pretty big risk to bet a startup on rust back in 2014 if you
didn't have the freedom to keep up to date with the breaking changes. Crazy
people like me had a lot fun seeing the language evolve in realtime, but it
certainly would have been stress-inducing if I was betting my livelihood on
it.

Now that we're stable, please let us know if you plan on experimenting with
Rust. We'd love to hear how it goes (I run the SF meetups and am always
looking for speakers), and what we can do to help. One of our short/medium
term goals is to make some high quality bindings to other languages, so that
projects like yours could slowly introduce Rust where it makes sense.

------
cs702
The gist of it is, they believe they're more productive with Go than with C++
or Java. In particular they mention Go's small idiomatic footprint and its
focus on simplicity and consistency, which they say make it easier+faster to
pick up the language (for new developers) and write cleaner, understandable
code (for all developers).

As to performance, they _expect_ it will be comparable to C++ and better than
Java. I say "expect" because they don't provide any evidence to back that
claim.

PS. I often feel like I'm walking walking on eggshells when discussing
computer languages on HN. For the record, I'm neither "pro-Go" nor "anti-Go."
Languages are tools, not religions. Go is just a tool:
[https://news.ycombinator.com/item?id=10465697](https://news.ycombinator.com/item?id=10465697)

------
hectormalot
Excuse me if this is a dumb question, but I've seen a lot on HN these days
where people would suggest Erlang/Elixer for this kind of use case (high
performance distributed). Any reason (beyond syntax preference) that this was
not one of the languages considered?

~~~
jerf
I wouldn't recommend the Erlang VM for anything that needs to _itself_ be
running at the highest performance levels. The VM is not very fast when it
comes to computation. It's a great VM for what it does, and absolutely should
be considered for many other such tasks, but probably not a great choice for a
database.

To some extent, but a lesser extent, the same could be said for Go:
[http://benchmarksgame.alioth.debian.org/u64q/which-
programs-...](http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-
fastest.html) (It's a bit weird reading that page, because it's broken into
two graphs, but they appear to be about the same thing.)

If I were thinking "trendy language to write my next database in" personally
I'd favor Rust by a country mile. This is _exactly_ where you'd like all that
stuff Rust provides just for correctness' sake, and this is the sort of task
where you may even be able to outrun C++ if Rust helps you write correct code
with fewer barriers slathered about for correctness.

Edit: Ha, and just below this comment as I read it I see the team commenting
about Rust.

------
shockzzz
Can anyone link a reference for known performance issues in Java? And is it
issues in Java or the JVM?

~~~
valarauca1
I can't provide a direct link. But generally Java itself is rarely the
problem. The language is fine, the byte code is great.

The JVM on the other hand with its _stop the world_ garbage collector is a
constant source of performance issues. Especially once you start getting over
2-4GB heaps. GC cycles can take 1s+

~~~
slantedview
There are plenty of options for storing select data off heap, which a database
such as Cockroach could certainly have taken advantage of.

~~~
shockzzz
so this is an oversight on their part? it sounds like they had maybe a half-
baked justification, but idk

------
vishalzone2002
I agree to most points. One thing I struggled trying it is lack of information
on interenet as compared to more mature languages like c++ or java. Since most
of the cockroachdb team including founders come from google, I wonder if they
have access to better advice too.

