why golang for CockroachDB?

[raj.ch...@gmail.com]

hello

i am learning about Cockroachdb and am wondering what was the reason behind using GOLang and not say Java or C/C++ etc.? 

i have tried searching but have not had a good luck. 

[Spencer Kimball]

That probably is something we should add to the README.md.

Most of us on the team have done extensive work with C++ and Java in the past. At Google, C++ was the standard for building infrastructure and there are a lot of good reasons for that. It's fast and predictable. It would be a good choice for Cockroach, except that in the world outside of Google, in open source land, the supporting libraries for C++ are either terrible, incredibly heavyweight, or non-existent. We didn't want to rebuild everything which you take for granted at Google from scratch.

It turns out that Go has many of the necessary libraries, and they're straightforward and very well written. Go's performance is also really good. Not quite C++ levels, but then there are compensations. Go is garbage collected, which means fewer types of memory-related bugs. These can get really tricky in C++ when a code base gets complex. The garbage collection in Go seems quite good so far. It's apparently getting much better in the 1.5 release, due end of summer.

As to Java...well not many of us like that language very much anymore. The mindset of Java developers as a community seems to have veered towards abstraction for abstraction's sake. Of course, we could write straightforward Java code and ignore the wider, evolved community standards. The GC in Java also seems to stubbornly resist behaving sensibly, which is a big problem with a system like cockroach, which will eventually be reliant on predictable user-facing latencies.

One more point worth mentioning: Go enforces a delightfully consistent set of code styles: namely just ONE. It also encourages a minimal set of programming idioms by design. This is incredibly helpful in an open source project, where many contributors from different backgrounds are trying to understand a complicated system like Cockroach. The concepts are difficult enough by themselves; having to understand annotation meta-programming, guice dependency injections, overwrought abstractions or C++ template magic is just adding insult to injury.

Hope that helps answer your question.

--
You received this message because you are subscribed to the Google Groups "Cockroach DB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cockroach-db...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[kant...@gmail.com]

These arguments are not convincing at all. Every Language has pros and cons and most of time the decision seems to be what is latest and greatest and build arguments around it to convince the reader. If anyone thinks they know what they are talking about show us a simple use case or use cases where a certain feature in Go is very powerful, efficient, blah blah compared to Java or C++? Without that I think it's all bullshit.

[Vivek Menezes]

Id argue that folks are not happy with c++ and Java and Go was reasonably mature for our project. Since we've gone that route and are happy with that decision we don't feel the need to change course.

Thanks for your interest in cockraochdb.

Vivek

You received this message because you are subscribed to the Google Groups "CockroachDB" group.

[Vivek Menezes]

I'm curious what your thoughts are on this?

Thanks

Vivek

On Sun, Jul 24, 2016, 4:03 PM kant kodali <kant...@gmail.com> wrote:

yeah so saying folks are frustrated with C++ and Java without actually showing concrete use cases of where they differ and more importantly how that difference would have made a huge impact for you guys to implement cockroachDB at this time carries no substance. I would bet that is not a easy task even for Rob Pike or Bjarne Stroustrup or James Gosling. you guys are merely stating things that just shows your bias nothing else.

No one is interested to change your decision on the choice of programming language you guys picked.  If you guys prove your product works with some benchmarks then it wouldn't really matter which language you picked.

[Peter Mattis]

Hi kanth909,

We're here to build a distributed database, not argue about programming languages. An individual asked why we chose Go, Spencer answered with the reasons that convinced us. You're free to disregard the arguments given. 

You received this message because you are subscribed to the Google Groups "CockroachDB" group.

[kant kodali]

yeah so saying folks are frustrated with C++ and Java without actually showing concrete use cases of where they differ and more importantly how that difference would have made a huge impact for you guys to implement cockroachDB at this time carries no substance. I would bet that is not a easy task even for Rob Pike or Bjarne Stroustrup or James Gosling. you guys are merely stating things that just shows your bias nothing else.

No one is interested to change your decision on the choice of programming language you guys picked.  If you guys prove your product works with some benchmarks then it wouldn't really matter which language you picked.

On Sun, Jul 24, 2016 at 9:14 PM, Vivek Menezes <vivek....@gmail.com> wrote:

[kant kodali]

Peter,

Yes I know what you guys are building and yes I have happily disregarded Spencers arguments. They carry no substance in my opinion. I can understand why it is convincing to you or other people at cockroachDB for the reasons that are obvious :)

[kant kodali]

Vivek,

It is simple. Every Language has its pros and cons. In some cases people actually aren't comparing apples to apples (An example of that would be the performance comparison of C++ and Java). one has a VM and other doesn't so we pay a price to get something that we want so it's all about tradeoffs. great. I haven't added anything new!  I can talk a lot about Java's GC vs Go's GC but I want to be sensible enough to not point out the differences (anyone can do that) unless I can show how those differences can make a significant impact in what I am building with some concrete examples or use cases. I haven't seen that in this thread and that tells me you guys are also following the Bandwagon just like any other company in Silicon Valley. I believe it's not an easy task even for the inventors of a Programming Language. 

Finally Go without Google support would probably have not gone very far as much as it is today, We know from the history how this cycle works. 

Thanks

[Radu Berinde]

Kant,

> certain feature in Go is very powerful, efficient, blah blah compared to Java or C++

To reinforce Spencer's last paragraph - in my biased but not inexperienced opinion, I am much more productive writing code in Go compared to C++ or Java. I find this "feature" very compelling.

You can disagree with our viewpoints and that's ok - that's why multiple languages exist. But please be respectful (Spencer took the time to produce an honest and well written answer to a question, your tone and choice of words is not warranted).

Finally, we are not based in Silicon Valley.

-Radu

[kant kodali]

Radu,

I am just very surprised with the argument you guys are coming up with. First of all you need to define what you mean by productive? writing less lines of code? if so, why not write it in python or some other dynamic typed language? This kind of argument I heard it many times and I find it baseless.

I don't have anything personal against you guys so there is no reason for me to disrespect any of you. My frustration are rather towards the arguments/technical statements you guys are coming up with. Your team which I came across linkedin looks very talented but that cannot blur my eyes when I find something that distorts the truth (biased arguments). 

Finally, Spencer took time, you took time and I took time to write something on this thread, so why mention specifically about Spencer? In my world Spencer, you and I are X, Y, and Z. And this is not being disrespectful. This is treating everyone the same in my world.

I am going to stop now since you guys are finding it offensive or disrespectful rather than looking to see if have a point. sometimes its better to hear views/arguments from people outside of your company.

Hope you guys do great!

Sorry if my choice of words are offensive. I just like bitter truth!

[Andrei Matei]

I'll bite too, although I also don't have the kind of benchmarks, lines of codes analysis or bug reports you might be looking for.

First of all, I think it's fair to say that our team is generally far from being Go fanboys/girls. There's a contingent that likes Rust, there's some functional programming pointy-heads and there's people like me who miss C++ (in particular, Google's C++). If I were to guess, I'd say there's a good chance that if we were starting today, we'd choose Rust (it wasn't mature enough when Cockroach started). You regularly hear people on the hallway complaining about Go, and rarely giving it particular praise.
I'd also say there's a fair amount of personal taste involved in how these decisions are made, and in the end the programming language is not what defines the project. Even "jumping on the bandwagon" is a valid strategy, if you think the bandwagon is going to give you good tooling, libraries and support. Although I wasn't aware there's a big Go bandwagon happening.

Go's selling points: the language is very small and simple, easy to learn by new people, relatively performant (no vm, some control over memory allocation - stack vs heap - and passing by pointer vs value, lightweight slices), lightweight threads that are very nice for servers and hip concurrent programming primitives - the channels (we use them and they sometimes lead to expressive and natural implementations; having them built in the language, together with the select statement, does lead to better code than using library version of producer-consumer queues in other languages).
It also things orthogonal to the language going for it: the tooling. go get/build/test is very nice, and it saves you from having to learn a build system (which would've been necessary with either C++ or Java, let alone Python), and a unit testing framework. So less cognitive overhead. go oracle is a good tool for IDE's code comprehension, which leads to decent code completion and refactoring support across all IDEs. Much easier than getting similar support for C++ in Vim, for example.

And then there's the production-ization stuff: Go's built-in profiler for cpu usage, memory and lock contention are great, and the request tracing, plus the integration with the standard http server. Now that's modern stuff, hard to get in C++ and Java outside of Google.

C++: As Spencer said, 3rd party libraries are a big problem. From my limited experience working on a few toy projects outside of Google, there's rarely a clear default choice for something, and the style of the available libraries and APIs is widely different: some use exceptions, some don't; some use templates, some don't. The preference of pointers vs references varies, as does the sprinkling of const. Some use smart pointers of various sorts. Some use stl containers, some use stl iterators, some use boost, some use some combination and some use none. Some use a plain C style, others have deep object hierarchies. And reading their code leads to varying degrees of satisfaction - not least because of widely varying style guides and the evolution of the language. To be honest, coming from Google that had a very nice walled garden and world-class experts addressing every single aspect of C++, I felt pretty lost outside - wait, do I need to pass -lpthread to the linker? (well, I guess I felt the same come lunch-time so maybe that's just me).

Besides, there's the productivity issue. Productivity is not defined as lines of code written, but time to write, test and read/review the code necessary for a task. C++ is getting better and better in this respect with newer versions, but still, it's not doing great. My old team had a copy of the standard on a desk and we'd go to argue over it weekly. You can sometimes spend hours wrestling with the compiler to get some template magic working (the joys of screen-long linking errors). On the flip side, C++ does give you excellent control over the generated code/machine when you want it, and I do miss that.

Java: I don't know what it is about it, but I don't know anybody who likes this language. It feels bureaucratic, seems it's slower to evolve than even C++ now days. Does it have anonymous functions yet?

I've worked on a big Java system, and somehow the scale of the performance problems we were having was different than with C++. The C++ systems I've worked on were pushing thousands of QPS per core, the Java ones were doing tens at best. It's far from apples to apples, of course, but anecdotally in C++ we got to the point where we were doing more exotic optimizations like lock-free data structures and memory prefetching, whereas in the java world the jvm would sometimes go do something else for like 100ms. And we did put some effort in tweaking the GC. Somehow the perf problems were of a different magnitude; I'm guessing it has something to do with how pointer-chasing-happy Java is. Everything is a reference, every field is a pointer, your allocations just blow up.
But this might not be a universal experience: I was surprised to hear Sameer Ajmani from Go's team say at a conference recently that they currently generally think of Go's performance as being worse than Java, because the JVM had many years to be optimized. I'm not sure what he was referring to. And most of the optimization of Cockroach's behavior under load is still to come, so maybe I'll change my opinion. We probably benefit from using a lot of C++ code under the hood through our dependency on RocksDB. And particularly since that component is the most memory-hungry part.

And then there's the other thing Spencer mentioned - I don't know why, but Java code does seem to devolve into endless hierarchies of interfaces, bindings, adapters. I was trying to read some Java code from an Apache project recently and it took me a good time until I found any code that actually did something.

Python: I think that's a non-starter. Let alone alone the (default) implementation that doesn't even let you have any parallelism within one process and the fact that there's no good build system that can give you a "hermetic binary" (well, I see that Google's bazel has gotten python support now, so maybe that's solved). A language without some degree of type-safety and static typing is just not suitable for a large code base. I've worked on one of these and it was chaos. It requires too much programmer discipline to comment the code enough to make it readable, and in practice this doesn't happen. And without knowing your types, your code is like a (Romanian) presidential candidate's speech: vague an noncommittal.

My 2c.

[Radu Berinde]

I define "productive" by how much time and mental effort it takes to write, debug and test, and (even more importantly) by how much time and mental effort it takes for someone else to later understand the code I wrote and work with it. A loosely typed language like python in a large project actually requires more time and effort despite ultimately writing fewer lines. This is not an argument because it is not my job or desire to convince you of something. It is just my opinion and it is based on my experience (and in that sense, it is not "baseless").

I won't pile onto what Andrei said but I want to add that for me Java is pretty much a non-starter for a system like this because 1) you have zero control over memory arrangement (can't put multiple structures together, everything has to be a pointer), 2) you need to run everything in a relatively heavyweight JVM, and most times you are at it's mercy latency-wise and 3) I find the many layers of unnecessary abstractions in many libraries annoying.

With C++ you get all the control you want, but also all the responsibility - in particular memory management and thread safety. This is the main reason I feel Go makes things easier to write and reason about. Of course, it comes with a trade-off (GC, less control on scheduling) but so far this trade-off has been sensible for us.

By the way, if you/they are passing around interface{} everywhere, you are probably doing it wrong (in which case your stance against Go is less surprising). The situations where you really have to fall back to using 'interface{}' are rare.. For example in our codebase we have about 300 (non-generated) lines of go code that mention 'interface{}', out of a couple hundred thousand.

-Radu

[Radu Berinde]

> you sound like Go is a magical bullet

I never said anything like that, and I clearly said there is a trade-off involved.

> Thanks for the interface{} clarification although I don't understand why would only count non generated ones. That is the code written by Go Zealots in my team!  

Minor difference, generated is only 70 more (in protobuf go files).

Here's a radical thought - instead of sulking and blaming the language, your team, and to some extent even us (an unrelated team of people who happen to use Go), maybe spend your energy trying to make your code base better :)

-Radu

On Mon, Jul 25, 2016 at 11:38 AM, kant kodali <kant...@gmail.com> wrote:

It's hard to give you the benefit of doubt given that I have already exchanged my views on what productive should be. In either case, it is still baseless because since you don't have any numbers on how long it would take you or anybody to write, debug, test , mental effort that it takes someone else to understand the code. It is clearly subjective and as you said it is just your biased opinion. 

What Andrei had added is probably the best and neutral response by far since he questions Go as well in some cases unlike you where you sound like Go is a magical bullet! great that it is working for you! Wait for the problems you can potentially face with Go's GC!

Thanks for the interface{} clarification although I don't understand why would only count non generated ones. That is the code written by Go Zealots in my team!  

[kant kodali]

It's hard to give you the benefit of doubt given that I have already exchanged my views on what productive should be. In either case, it is still baseless because since you don't have any numbers on how long it would take you or anybody to write, debug, test , mental effort that it takes someone else to understand the code. It is clearly subjective and as you said it is just your biased opinion. 

What Andrei had added is probably the best and neutral response by far since he questions Go as well in some cases unlike you where you sound like Go is a magical bullet! great that it is working for you! Wait for the problems you can potentially face with Go's GC!

Thanks for the interface{} clarification although I don't understand why would only count non generated ones. That is the code written by Go Zealots in my team!  

On Mon, Jul 25, 2016 at 5:13 PM, Radu Berinde <ra...@cockroachlabs.com> wrote:

[kant kodali]

I wanted to stay away but it is hard to resist after your response. I haven't mentioned few things in my previous email that I will mention it now.

I just cannot tell you how many times throughout my career developers had said "They are productive in one language because it allows to accomplish something in less lines of code" This statement totally depends on what you are building but in 99% of the cases it is misused. The reason why I mentioned python is to imply that one shouldn't be talking about being productive means writing less lines of code especially when you are building a large scale distributed system. I would pick a tool that minimizes my debugging time rather than development time and so I strongly prefer a static typed language. I am happy to write few extra lines of code which can help me debug faster. After all, we write code once and read man times in most cases. If this isn't the case we should suspect something is wrong with the direction of the product we are building! To stress a little bit more, I wouldn't even accept an offer from a company where majority of their code base is in a dynamic typed language. 

Talking about Java, I do have respect for the people who were behind it prior to acquisition by Oracle. I have read Java SDK code and JVM code many times. I am very impressed by the quality of the code and the profound thoughts that were behind it. I could see some deep technical expertise just by reading that code (It taught me much more than what MIT or Stanford could have taught me ). I don't know of any Engineer who hated Sun Microsystems. Every Sun Microsystems employee I came across said one thing in common. If that company existed they would want to retire from that company. I haven't heard that kind of statement from anyone these days on any company.  Even today 90% of Apache Projects which fuel many companies are still in Java at the same time I can foresee it may not be the future. Too bad Oracle messed it up! Finally more than Java, I would say JVM is a Jewel! sure people might be able to do better than that given enough time and Money which Google has! but needless to say JVM was a great invention and I would imagine future VM's will copy lot of it ideas from it.

I have done lot of programming in C than say C++ and I liked it a lot but it was a while ago. I am coding in Go these days because some HIPPO's like it in my company! they just like to pass around interface{} everywhere!

Thanks for your response!

[bill...@gmail.com]

I'm not associated at all with CockroachDB. They've given you several concrete examples of why C++ and Java impose a larger cognitive load on a programmer due to differing styles across libraries, unnecessary abstraction, etc., compared to Go, which has a more consistent code base due to a simpler language and newer libraries that conform. It's not our job to convince you "cognitive load" is an issue for readability, programming in the large, and open source work, but I think it's pretty obvious to most programmers.

It's also telling to me that had the internal Google C++ code base been open-sourced, they might not have written CockroachDB in Go but in C++. It's not just the language but the support libraries and how they are written. Go has some advantages in that it is relatively new, the core libraries are extensive, and they are written by decent programmers working to one style. This might also be a reason Rust gets some looks vs C++ and Java.

I am very interested in the final benchmarks for this project and how much gets lost over the C++/Go boundary with RocksDB.

[kant kodali]

First of all I wasn't asking anybody to convince me. so that statement in unnecessary. you either share your opinion if you want to or refrain from doing that. It's as simple as that. 

No one has given concrete examples. The examples you mentioned were subjective. How in the world saying some programming language has a unnecessary abstraction is concrete? That is just some people's opinion. someone else can also say that abstraction is necessary. 

If I were to dissect your statements. Here is what I would say

"Go has some advantages in that it is relatively new" How a language being new is an advantage after all there are many that I know who complain that Go community has not evolved and that they couldn't find the libraries they want? Every Language, technology needs time to mature. 

"they are written by decent programmers working to one style" Every language has some standards and most developers try to follow them. Ofcourse there are developers who may not care but that applies for some Go developers as well.

Yes I am also interested to see the benchmarks. 

[Bill Katz]

"No one has given concrete examples. The examples you mentioned were
subjective."

It's not a matter of opinion if necessary C++ libraries are written to
different styles. Andrei gave specific examples of how libraries
differ. It's not subjective that Java gives you little control over
memory arrangement.

If by "concrete" you want a statistically valid survey of how all
potential programmers that would work on CockroachDB feel about
readability after their small startup develops versions in C++, Java,
and Go, yeah, they aren't going to do that. There's at least N=3 of
people from their core team in this thread alone telling you they feel
Java is less readable, and then they point to the abstraction layers
as an example.

Modern systems languages should consider concurrency and networking as
primary features, and "new" languages like Go and Rust do this.
(Obviously, some older languages like Erlang do as well.) This is
what I meant by an advantage that Go is new and also hasn't ballooned
up with lots of additional syntax over time. Concurrency is not some
bolt-on library but part of the Go language, and programmers like Brad
Fitzpatrick work on the http implementation. And those features
should get better with age even though they are pretty good now.