The article is more about the process and not the motivation for this port. What problem with Java/JVM caused the organization to commission this expensive porting exercise? And what are the benefits they have achieved after the port.
Bonuses questions: do they other libraries stem from the java root client too or did they evolve separately (even out of house)? Why did you choose Java to port from? Are there interesting lessons in the commonality / differences between the language implementations?
RavenDB is written in C#. At first, it was Windows only but now is cross-platform database engine (Windows / Linux / Mac OS).
As a result, the original and most featureful client is for C# / .NET.
Java client is a port of C# client, done in house by Hibernating Rhinos (the creators of RavenDB).
As far as I can tell, other clients (Python / Node.js and the Go client that I wrote) were contracted to outside people.
The company suggested starting from Java code base. It makes sense because C# client heavily uses LINQ, which is unique to C# (neither Java nor Go has LINQ-like capabilities).
I didn't dig much into non-Java clients so can't speak much to that.
Overall, I was surprised how similar I was able to make Go code to Java code.
Changing from exceptions to errors was pervasive but a simple, mechanical transformation.
Porting functions using generics was the biggest hurdle.
Porting functions that use overloading was easy but annoying.
That being said, a Java code base that heavily used virtual functions and deep inheritance hierarchy would be more challenging to port to Go. Lucky for me, this code wasn't.
Author states: "I was contracted to port a large Java code base to Go". That makes me think his focus is on earning the money, rather than questioning the motives of his client :)
The fact that he tried to port a lot of the Java code directly to Go, where Go had no suitable comparable feature. With generics, he mentions there are two different approaches in Go, but then only mention the one he calls the least preferred one, i.e. using interface{}.
But he never talks about motivation of the original code. Like why it was generic in Java. Sometimes generic code in other languages can be ported to Go to two or three functions, because the general use of the generic code wasn't as generic as the designer may have envisioned, or it just became a nail to their hammer.
Like was the inheritance really important, or could it be implemented another way in Go?
But I guess if you're not questioning your client's motives, you may not be fully questioning how something ought to work, and instead just ensure it works as it does right now.
It's possible they just needed a Go-library for their client code, and then the client code can be tweaked later on to be more idiomatic Go.
With "porting" I guess he doesn't mean replacing one codebase with another one, but creating another client in a different language. In fact, he states
The objective of the port was to keep it as close as possible to Java code base, as it needs to be kept in sync with Java changes in the future
so it doesn't look like they are ditching their Java client.
It’s a client library by the looks. So presumably they have a Go codebase building up and they needed to be able to access RavenDB from there. Caveat, I haven’t finished the article and I’m not familiar with either the RavenDB or Go ecosystems.
