From Java to Go, and Back Again (2016)

"Casual" Java programmers usually miss the most important feature, what really makes it possible to do almost anything in Java. Reflection and runtime code generation. Every time I look at Go this ends up being a problem, worse than lack of generics. A lot of Java libraries use these features under the hood to make things like JPA and JSON serialization work.

Nothing I'm aware of comes close to Java in this, where you can redefine the language and rewrite compiled code at runtime while still maintaining execution and memory safety. Java agents, annotation processors, and libraries like JavaAssist, ByteBuddy, and ASM make seemingly impossible things pretty easy to write.

This is why annotations are used for everything in Java. They're often just tags used to find targets for rewriting code at runtime.

I was trying to write a thin ORM for Go and quickly found out it was impossible to do what I needed without blowing a bunch of nasty generated source files into the build. In Java, I can give the developer a nice clean interface and just generate the code when the app starts. Go forces you to expose all this to the user of your library

>Almost all the tricks I’ve built up over the years for creating embedded DSLs in Java or Ruby or Clojure are simply unavailable.

>...if there’s one complaint I’ve heard consistently from my fellow developers over the years, it’s that they can’t understand my code until they also understand the set of abstractions I’ve introduced

"Tricks" are lovely for personal projects, but no one wants to trawl through them at 3am when the server has gone down. Go removes a lot of tricks, and that makes people sad, but it makes total sense for a language design for large teams. You can still use Go for one-man projects, of course (I do), but don't expect it to be as whimsical an experience as using Ruby or Lisp.

Java is a wonderful language with a terrible culture. Choosing Go or even Kotlin over Java is liberating because it allows an engineer to escape the cultural baggage that comes with Java.

What kinds of baggage? The type of baggage that blindly demands using magical frameworks like Spring and JPA or worse engages in best practices chants as they implement 45 interfaces and create thousands of excess classes because SOLID and DDD said to do so. Yes, I'm exaggerating some but this is a real problem on Java teams.

I sincerely hope that a culture adjustment is included in the Java 11 release.

Maybe is true that I can understand what is happening in every single line of code in my screen, what I found really hard is to understand how those line interact with the rest of the code base.

I honestly believe that there are some part of the code base that should manage the low level stuff like managing files, writing to buffers or interact with the file system and other part that should compose/manage/move those low level parts.

Using go and its focus on "simplicity" it feels like these basic abstraction fall apart and that in every part of the code base I can find something doing quite low level stuff.

I find go quite good for small, self contained projects but honestly I believe that big projects like docker could benefit more from a more structured approach.

Am I the only one feeling this pain?

Returning to Java (and Kotlin) development after a couple of months of Go development, [...] I discovered the value of a certain sort of "plain speaking" in code.

This resonates with me. I've spent 1 year+ in each of C, C++, C#, PHP, Java, Python, and JS. There are obvious benefits to taking advantage of a platform's strengths, but the "plain" code has merits too. Easier to reason about, often more maintainable, faster to ramp up new team members, etc.

> ...if there’s one complaint I’ve heard consistently from > my fellow developers over the years, it’s that they can’t > understand my code until they also understand the set of > abstractions I’ve introduced"

Now I mostly use Scala in an FP style I find I reuse abstractions. The abstraction I want almost always exists in a library. Monads, applicatives, monoids, etc. actually work for code reuse, and this makes it much easier to read code. When I look at a code base such as http4s (https://http4s.org) I find I can read it without much difficulty even though I'm not familiar with the code.

So my contention is you can reduce expressivity to make code easier to read, or you can increase expressivity so that truly reusable abstractions can be created. (You basically need higher-kinded types in addition to the usual FP abstractions.)

This is the YAGNI principle in XP - “you ain’t gonna need it”: https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it

It builds an xml dependency tree of your classes. That's not hard to understand.

Everything it does is well documented on their site as well.

Is @component and @restcontroller and @requestmapping really that hard to understand?

So I wonder, having a smaller vocabulary, it might make learning the language easier. And maybe your first pass on a new piece of code is quicker to read. But after that first pass, or once you've learned the expanded vocabulary, wouldn't it now be even easier to read? And not using it would just make things redundant and appear like noise.

It's like reading: "He felt a deep attachment that was unique and stronger then any other to her." And then you learn about "love". Now from that point on, I'd rather read "He loved her." Seem just easier to read once you know the concept.

I see what the Author is getting at, but he's missing the primary mechanism Go uses for this: Interfaces. This is hard to explain in the abstract, so here's an example I gave in a talk once: (bit.ly/1mBisa6)

Suppose we are building a new podcast platform which dynamically splices advertisements into mp3s. We will do this with an HTTP server. In Go you do:

    f, err := os.Open("somefile")
    ...
    http.ServeContent(w, r, "", time.Now(), f)

    func Splice(
        src io.ReadSeeker, 
        splice map[time.Duration]io.ReadSeeker,
    ) (io.ReadSeeker, error)

    f1, _ := os.Open("/tmp/1.mp3")
    f2, _ := os.Open("/tmp/2.mp3")
    f3, _ := os.Open("/tmp/3.mp3")
    final, _ := mp3.Splice(f1, map[time.Duration]io.ReadSeeker{
        time.Second * 5:  f2,
        time.Second * 10: f3,
    })

    func NewMultiReadSeeker(
        readSeekers ...io.ReadSeeker,
    ) io.ReadSeeker

    func NewSectionReadSeeker(
        src io.ReadSeeker, 
        offset, length int64,
    ) io.ReadSeeker

    final := NewMultiReadSeeker(
        NewSectionReadSeeker(f1, 0, A),
        f2,
        NewSectionReadSeeker(f1, A, B-A),
        f3,
        NewSectionReadSeeker(f1, B, C-B),
    )

1. The file is never built in its totality in memory. Rather we are representing the operations in a lazy fashion that only get executed when you use them.

2. The ReadSeeker supports seeking, which means we can resume from the browser, or seek to the end and skip the middle bits. With the go HTTP library we basically get this for free.

3. Lots of things use these interfaces. For example if I want to write this to disk, I can just io.Copy it. Or suppose I want to use this as another source for a second splicing. It's ReadSeekers all the way down, so I can do that with no changes. With some tinkering I'm pretty sure you could hook this up to S3 too.

That's not true. Here's their example written to be more generic:

  func mapThingToThing(inSlice interface{}, mapperFn interface{}) []interface{} {
  	mapper := reflect.ValueOf(mapperFn)
  	input := reflect.ValueOf(inSlice)
  	output := make([]interface{}, input.Len())
  	for i := 0; i < input.Len(); i++ {
  		item := input.Index(i)
  		output[i] = mapper.Call([]reflect.Value{item})[0]
  	}
  	return output
  }

  fn := func(item string) string {
  	return item + "!"
  }
  res := mapThingToThing([]string{"a", "b", "c"}, fn)
  for _, item := range res {
  	fmt.Printf("item = %+v\n", item)
  }

val exclaimed = strings.map { it + "!" }

Should be

val exclaimed = plain.map { it + "!" }