6 ms·

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

• nobullet 11y ago
  What's wrong with JVM?
  • wiremine 11y ago
    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.
  • rifung 11y ago
    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
    • icedchai 11y ago
      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.)
      • rifung 11y ago
        But what happens when some of the apps require different versions of the JVM?
        • bitmapbrother 11y ago
          As long as you're using the latest version then this shouldn't be a problem as the JVM is backwards compatible.
          • tacticus 11y ago
            Except on those fun occasions when it isn't really. :\
        • icedchai 11y ago
          You know you can have multiple VMs installed, with different JAVA_HOMEs, right? This is a solved problem.
  • bkeroack 11y ago
    Among other things, an unnecessary VM layer if all you ever run on is x86.
    • pmahoney 11y ago
      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...
  • gtrubetskoy 11y ago
    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.
  • yo-code-sucks 11y ago
    Memory overhead, and the ability for endless abstraction to save three lines of boilerplate code and then the fact that it has only one actual implementation, meaning the abstraction was unnecessary.
• lohengramm 11y ago
  Very well put. I would also add nice UTF-8 support, easy concurrency and overall simplicity.
  • wz1000 11y ago
    All those points along with the parents apply to Haskell too. Yet Haskell does not enjoy the same hype/success.
    • rakoo 11y ago
      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.
      • codygman 11y ago
        > 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.