Hacker News Reader

Hacker News

Comment by gtrubetskoy | Hacker News Reader

Parent Full thread

gtrubetskoy

Compiled to native binary, garbage collected, no JVM and not object oriented is why I like it.

View on HN

Very well put. I would also add nice UTF-8 support, easy concurrency and overall simplicity.

All those points along with the parents apply to Haskell too. Yet Haskell does not enjoy the same hype/success.

I think you'll find some people who wouldn't say that Haskell is overall simple, or at least as simple as Go can be.

> I think you'll find some people who wouldn't say that Haskell is overall simple, or at least as simple as Go can be.

You'll also find some people who say the opposite. We need to qualify what kind of simple we are talking about? Are we talking purely about language?

Are we talking about standard libraries? Ease of use of API's? Ease of use in analyzing performance?

If we just compare Go's syntax to Haskell's syntax you'll find they both have few reserved words.

What's wrong with JVM?

The JVM is a piece of software that rivals the kernel in complexity with for the most part redundant functionality (i.e. memory management, monitoring the running program, etc.). It does have the benefit of being uniform across platforms, but if you're dealing with a single OS, then the extra weight and deployment complexity isn't worth it - you're better off learning your operating system and its tools.

Nothing, IMHO. However, I do like Go's much leaner memory footprint for server side software. At least, that's been my experience: the same code doing the same task takes up much less RAM.

Someone correct me if I'm wrong but I think not using the JVM makes deployments much simpler. At least that was one of the benefits a team at Amazon stated about switching to Go while I was there

In practice, it doesn't make much difference.

You install the JVM once and rarely upgrade it.

You build and distribute your Java apps as fat jars (meaning, all dependencies bundled.)

But what happens when some of the apps require different versions of the JVM?

As long as you're using the latest version then this shouldn't be a problem as the JVM is backwards compatible.

Except on those fun occasions when it isn't really. :\

You know you can have multiple VMs installed, with different JAVA_HOMEs, right?

This is a solved problem.

Among other things, an unnecessary VM layer if all you ever run on is x86.

The VM part of the JVM allows for really great monitoring: there are standard ways for tools to hook into bytecode and add instrumentation without needing the source. There are also lots of mature tools available, but that's mostly because the JVM has been around for so long.

We're looking at Go right now, and our instrumentation is currently done manually at the source level. Are there, or will there be, tools to add instrumentation similar to those available on the JVM? I'm sure it's possible...

Reply on news.ycombinator.com