Hacker News Reader

Many of the Java monitoring is only critical because of the garbage collection issues with large heaps. Since switching away from Java we don't miss any of the features you've listed. The problem with Java is the mountain of bloated frameworks which have become standard over the last 10+ years - things like Spring, Hibernate etc. which new developers are expected to learn. With Go new developers which join the team aren't saddled with years of legacy frameworks which are expected as standard knowledge. The JVM is a great platform, but Java the language and to a greater extent its frameworks are a major liability for the future of the JVM. Go and Java (the language) are both incredibly boring to program in (a good thing in if you have developers of varying skill levels), but they are a safe choice with a low bar for learning. Java unfortunately has a mountain of legacy cruft which makes it a pretty terrible choice for new hires to ramp up on.

> Many of the Java monitoring is only critical because of the garbage collection issues with large heaps.

That's not true. All JVM libraries expose a ton of monitoring information through the standard JMX interface at every level of the stack, from deep inside the JVM, through logging framework, DB drivers, schedulers etc., and all the way through the application.

And I can only guess that you've yet to encounter Go's even worse GC problems with large heaps.

> Java unfortunately has a mountain of legacy cruft which makes it a pretty terrible choice for new hires to ramp up on.

True, but only in legacy codebases. A new Java project is as pristine as a new Go project, and new Java libraries are just as lean (because there's a lot of cross-influence between the two environments).

> A new Java project is as pristine as a new Go project

The problem is that most Java developers have become so familiar with and attached to bloated frameworks that they simply aren't interested in trying any other way. They have a lot of time and effort invested into mastering these frameworks. "Let's use Spring for that", and endless talk of the "persistence layer" for even the most basic apps.

The same developers who would be willing to try Go would also gladly use new Java libraries, and they will be able to preserve much of their hard-earned expertise.

You're implying that the mere switch -- all things being equal -- has an inherent advantage, while I say the opposite: all things being equal, switching languages is always a net loss, other than a possible advantage in recruiting in some regions where HN is popular. Of course, all things are never equal, so there are many other considerations.

It's not hard to find people switching from Java to Go (e.g. http://www.infoworld.com/article/2608571/application-develop..., which I found within 10 seconds of searching).

It's true that Go doesn't have a lot of those powerful JVM features that you listed, but as with any engineering trade-off there are lots of people who judge the benefits of Go to be worth the loss of those things.

Of course there are people making the switch, but the numbers are not nearly as substantial at as people switching over from scripting languages (even in nominal figures, let alone percentage) -- which perfectly makes sense.

You'll also note that since that article was published, all the advantages listed in in it have either found their way into Java (lambdas, fibers) or to other similar languages like Kotlin (multiple return values). Go has the undisputed upper hand when it comes to command-line apps (I really like it that I can use a language so similar to Java for stuff I never liked using Java for, and I was never fond of using scripting languages that require tedious dependency management for standalone programs), but is at a fundamental disadvantage when it comes to long-running important servers.

Maybe it's just that Python/Ruby programmers are more inclined to publicly discuss their switching?

Go is particularly well suited to long-running critical server apps. It has fewer GC issues compared to Java and is also simpler language (making it harder to screw things up - Java generics can get very complex).

> It has fewer GC issues compared to Java

No, it has more GC issues. It's just that there aren't yet enough libraries and big applications to make that apparent. It hasn't been stressed enough just yet.

It may have more GC issues, or maybe it probably has more GC issues.

I think it's likely that Golang apps won't stress the GC as much as Java does, because of the simple fact that you can't realistically use j.u.c-style concurrent data structures, since you don't have generics. Where the JVM GC really shines is when you're using shared-memory concurrent data structures, which are really great things—however, without generics, programmers just won't use them in the first place.

(I'm not saying this is a negative for Java, BTW; making shared memory data structures both fast and idiomatic is really important if you care about performance of parallel code.)

Why do you think generics are more relevant for concurrent data structures?

Because "programs don't need more than one type of dictionary, so the language can just hard code one implementation in" is at least a defensible position in a single-threaded setting (although I don't agree with it), but it definitely isn't in a scalable parallel setting.

Yeah. Go. The concurrent language with a single, mutable, thread-unsafe dictionary implementation.

> Go has the undisputed upper hand when it comes to command-line apps

Only because most developers don't care to look for the JVMs that offer AOT or refuse to use anything other than the OpenJDK.

That particular example of someone switching is someone whose background is in Java, but moved to a project implemented largely in Go. He switched because he changed projects.

Sure, there is some nice things about the JVM.

However, for me, Java was the first language to get ditched when I got comfortable enough with Go to accomplish similar tasks.

Reasons are many, but Go definitely wins "single native binary" argument. Java has to be installed, and it has different versions that can be installed. Go you simply compile for whatever platform you want, and you literally have a single native binary. No other dependencies need to be installed.

Hot code loading and swapping is neat in Java, but most places I have worked do not have the operational skill to really take advantage of this, and instead compound that against the JVM's slow startup time, which makes it double bad. With Go, you ship a simple binary that starts up very quickly, and so operationally the effect of faster, more seamless deploys are a much better experience.

I think that those advantages are extremely valuable for command-line apps, and hardly matter at all for servers. Those organizations you've mentioned probably do take advantage of bytecode manipulation (they have undoubtedly used shadowing, and probably some agents) even though they don't write manipulation -- or hot-swapping -- code themselves, and they certainly enjoy the JVMs unmatched monitoring.

I agree that the JVM is way, way ahead when it comes to things like agents and monitoring.

For me personally, those aren't a big of enough of a win. I would rather have simple code that is fast to scale and fast to understand.

Dealing with something like a thundering herd of traffic is much more difficult when your application can take upwards of an entire minute to start up, and to optimize itself to run at decent speeds.

There is likely a sweet spot however. My good experiences with go are working on high scale projects with a handful of other senior level developers. Some other projects I am involved in are with more enterprise shops with many more developers with a wider array of skill levels. In projects like these the other aspects of JVM like how well supported it is and how there is so many other tools for it, it might still win in one of these enterprise environments.

But for many of my use cases, the JVM just feels like it has everything-and-the-kitchen-sink, and sometimes you just want a small, nimble solution that does a few things well.

I can see your point, and it's the best one I've heard so far in favor of Go over the JVM. But I feel that there are two serious fundamental problems with Go -- or rather two classes of problems -- that are likely to hinder progress as a Go project grows:

1. Go's over-fitting to Google's development style, especially the over-reliance on dependencies as source-code.

2. Go's lack of hackability that might bite you down the line when you need something that Go really can't provide. Go's only hack-hook is source-code manipulation (which brings us back to point #1), and at this early a stage we already see too many tools going down that ugly road.

Go is probably the least hackable mainstream language I've encountered. In C/C++ you can always poke around the implementation details when there's no other choice; with Rust there's unsafe; with Java (and other JVM languages) there's full bytecode control; with scripting languages there's metaprogramming. All those "backdoors" should, of course, be used sparingly if not rarely, and then are best done by experts and hidden from sight, but they're always there for when you need them -- and you invariably do for that last 1%.

With Go -- there's absolutely nothing. You can't even drop down to C to muck about because you'll mess up the delicate runtime. So Go is indeed a descendant of C, Java and Python, but neglects to provide the hackable escape hatches from the plain language semantics all of them do.

Those two things scare me (not that I'd give up on deep monitoring or polyglotism otherwise, but still) because not only are they risky, they're exactly the kind of thing that people don't notice when the project is young. I feel like there's a very important lesson here that seriously bit people in the ass that Go failed to learn (well, that and no support for immutability of any kind).

Interesting points. I guess time will tell. Having used go for awhile now, these points just don't bother me.

Least hackable is a hard thing to define, but as you've defined it I suppose I agree, albeit in this context it often comes across as a feature to me.

Monkey patches are always monkey patches, and in golang your forced to fork a library to modify how it works. To me this is a good thing. It means that as the codebase evolves, the amount of "hacks" (if you will) are more often than not more clearly defined, and to maintain these hacks its easier to collaborate back and make a pull request, rather than just build up a collection of hacks that have to be maintained separately.

The fact that there is a higher barrier to entry to make these kind of changes, is simply not always a bad thing. Choose your poison, I guess. Golang is all about trade offs. In this case the trade off is its harder to simply add arbitrary code all over the place, but in exchange the culture of golang is more simple.

You forget to mention that golang also has an "unsafe" portion, and I've used it to "hack" around several issues before, all the way up to a (very hacky) dynamic code injection. Don't forget that golang also has an escape hatch of assembly.

That's a terrible escape hatch, because it's brittle and very much dependent on the runtime. A new runtime version can break your code and crash your process. It's mostly intended (as is Java's unsafe) to manually manage off-heap memory -- not to hack around language semantics.

I would think that all of your so called "escape hatches" are just as brittle, if not more. Once I compile a golang program, that binary will always run the same, no dependencies on a runtime that could be updated/changed out at anytime. If you aren't testing your code before deployment, that's your fault.

The only one that actually seems decent is the metaprogramming, which, in my experience, tends to lead to overcomplicated code and worse performance.

All in all, the only times I've ever needed an escape hatch is when I've been writing hacky things, or trying to be too clever. Too much "clever" is bad when programming.

> I would think that all of your so called "escape hatches" are just as brittle

Why are they brittle? They're not brittle at all, they just have looser semantics than the core language. They have their own semantics, which the runtime guarantees to uphold.

> that binary will always run the same... If you aren't testing your code before deployment, that's your fault.

Why work in such a primitive way? We're very familiar with what happens when source-code is overly dependent on a specific compiler version. Besides, dropping to C/assembly in a language with such a high-level runtime (not only a GC but its own global scheduler) is not an escape hatch; it's just using power tools to break through a hatch-free thick wall, which might work if you're careful not to break the foundations by mistake. You could do the same in all languages that do provide an escape hatch, too (if you'd rather break through the wall instead of using the hatch).

> Too much "clever" is bad when programming.

Absolutely, but sometimes just the right amount of clever can let you do truly powerful things that would otherwise be beyond the reach of the language. It's there just for those moments when you're stumped[1].

Experience (and I've been doing this for twenty years) shows that this point where some cleverness is necessary, always arrives at some point in the project's lifetime, and that cleverness often saves you a whole ton of work. Remember, the average codebase lifetime is about 10 years.

[1]: Plus some truly powerful stuff, like the ability to inject tracing code into a running application and then take it out.

When pron posts on a thread about lang X, it tends to be 30% about lang X and 70% raving about the JVM platform.

More like 90% blindly advocating the superiority of Java. Does he ever sleep?