[rthomas6]

Why does this article only compare Go with interpreted languages at the top? Go is a compiled language; wouldn't it be more fair to compare it with other languages that can be compiled, like C++, Rust, Haskell, or Lisp/Scheme?

I mention this because the article acts as if getting rid of abstraction layers between the OS and the code is a new idea. No, that's how all compiled languages are... that's the point of compiled languages. I suppose Go's most common use case lines it up against a bunch of slow interpreted languages, but really there's no reason except good libraries that you can't use the other compiled languages I mentioned for web apps.

[lateefj]

Author here. I was comparing things that I have developed software in. It would seem unfair to compare things that I have not actively contributed production code and deploy. I mainly write web applications (services) of which C++, Rust, Haskell or Lisp/Scheme are not languages I find compelling to write web applications with. Would love to hear if you find this otherwise.

[rthomas6]

No, I honestly know next to nothing about web apps programming. I do know there exists decent-looking support for web apps for Rust, Haskell, and Scheme (Racket, but Racket isn't compiled to a binary), but I don't have the knowledge base to assess how good web programming is in these languages, if it's even good at all. I know this website is written in Arc (a Lisp). https://github.com/wting/hackernews

[wtbob]

There are some nice things about writing web apps in Lisps, since one can represent HTML as s-expressions, e.g. (:html (:body ((:p (:class "main")) "Foo bar baz."))). And of course macros mean that one can create nice abstractions quite difficult or impossible in other languages.

[pjmlp]

That's quite common when selling Go.

Go advocacy tends to ignore what other modular languages with native compilers offer since the early 80's, as well as, present a cut down version of what modern runtimes are capable of.

[kyrra]

If you read any posts or listen to any talks by Google's Go team, they are a fairly modest about Go. They know it isn't as fast as it could be (since they don't have decades of compiler optimizations yet that GCC or other compilers would give). As well, it's just a newer language. One thing a lot of people don't always realize is Golang started with the Plan9 C compiler[0]. So they actually generate all the way from source to machine code with their own compiler toolchain (no LLVM, GCC, or other compiler required).

When you look at the people coming to Go, most are coming from Python or Ruby, not C, C++, or Java. So a lot of the experience Go developers have are those other languages. As Rob Pike pointed out 2 years ago[1], while they set out for Go to replace C++, it ended up actually being a much better fit for Python and Ruby developers.

[0] http://adventgo.blogspot.ca/2014/05/origin-of-go-toolchain.h...

[1] http://commandcenter.blogspot.com/2012/06/less-is-exponentia...

[NateDad]

It's actually a really great fit for C# and Java developers too... C# guys like it because it's cross platform and they get to stop the madness of worrying about what version of the .Net platform is installed. It's also nice to have a single executable and not 100 dlls to deploy... no more need for an installer to do everything for you, just drop an executable.

I would imagine it's similar for the java guys, especially now that there's java 8, you start having to worry whether it's installed etc. I think Java is a harder sell, because most Java guys don't recognize the complexity inherent in their huge type systems, and they have all these new toys to play with in Java 8 without having to learn a whole new language.... I think they'll come around eventually, though.

Go happens to also be a really great alternative to C and C++ (at least in applications where you don't need the strict timing of a GC-less language...) It's much less error prone than C and C++, with memory safety making most truly critical security bugs simply impossible. Again, like the Java guys, it's a little hard to convince people that have been working in the language for 15-20+ years that there's something that can make their lives easier...

[pjmlp]

Specially when we know our eco-system well enough to beat Go on feature by feature.

[NateDad]

I didn't really know what eco-system you were talking about, so I looked at your comment history, from that I assume you're talking about Java.

So, I really didn't mean to denigrate any communities or languages, there's definitely nothing intrinsically wrong with Java, and the ecosystem is at least an order of magnitude larger than the one for Go. Java guys have probably the least reason to switch to Go of all the languages I mentioned. I can certainly understand why a Java dev would look at Go and wonder why anyone would ever choose it over Java.

Go isn't likely to beat many languages on features, since it was purposely designed to have fewer features than most other languages. I do think it offers some advantages over Java, but Java also offers some advantages over Go. It's not a contest. No one has to "win". There's a time and a place for nearly every language.

[pjmlp]

You got it almost right, I also do know C++ and .NET quite well. My fault for not expressing myself correctly.

However I find both your answers quite faire.

My pet peeve is more with younger developers that promote Go vs other languages, without knowing how rich they actually are. Or the alternatives that came before, lost in the mist of time, with similar features.

Nowadays I do find that Go is a good and safer alternative, for C programmers doing applications that can live with a GC.

For other backgrounds in languages with native compilers available, I guess we have to agree to disagree. :)

[kasey_junk]

Well to be fair it does mention Java (though the deployment model expressed is, shall we say, Byzantine).

[rthomas6]

Java, while compiled, isn't compiled to machine code, and the bytecode to which it is compiled is run on a virtual machine. For this reason, I consider Java more of an interpreted language than a compiled language per se.

[pjmlp]

There are quite a few comercial JVMs with native compilers the HN crowd tends to ignore.

[kasey_junk]

Fine but calling it slow is unfair, especially in relation to Go.

[rthomas6]

Ah, true. I guess I didn't mean to call Java slow, but interpreted languages in general (at least, their reference implementations) are pretty slow. You're right... Java's kind of in its own category in a lot of ways.

[bsg75]

Because that is the trend of adoption. More people are using Go who also use Perl/Python/Ruby than C/C++/Java. It was originally targeted at the latter, but the actual result was from the scripting language set.

I am one of them - have used (and still use) Python since v1.52, but found Go an excellent option when performance / concurrency was needed.

[psankar]

> that's how all compiled languages are

You mean, like Java and C# ?!

[rthomas6]

No I mean languages compiled to machine code. I guess that happens sometimes with JIT or with some implementations of these languages? In general Java and C# are run on top of portable virtual machine layers, right?

[kasey_junk]

This is a very nuanced issue. The reference implementation of the JVM for instance will most assuredly compile some code to machine code, but it does so JIT. The developer/build server compiles to byte code that is run on a VM layer (though the distinction between the VM and a Run Time like Go's seems blurry as well).

That even leaves out Java compilers that skip the JVM step.