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.
It requires database drivers (client libraries) for as many languages as possible.
More client libraries, more programmers can use RavenDB, more licenses for RavenDB sold.
They already have C#/Java/Python/Node.js libraries.
I ported Java client library to Go, so that people who program in Go can access RavenDB database.
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.
Not true since Java 8, with the introduction of streams and functional interfaces, which keep being improved with each release.
What Java doesn't have are expression trees, which are convenient but not a requirement for LINQ like features.
There needn't be any "problem with Java". This is a client library. You want to have it in as many languages as possible.
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.
That being said, from a business point of few, making Go code base be as close as possible to Java version makes a lot of sense.
Java client is written the way it is. It already shipped and is used by people. Breaking its API was out of the question.
RavenDB is 10 years old and will most likely be here for the next 10 years.
In those future years, both Java client and Go client will have to be evolved to provide access to new capabilities of the server.
The closer the two code bases are, the less effort it takes to maintain those code bases.
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.