4 ms·

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 langua

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.

kasey_junk 12y ago
Well to be fair it does mention Java (though the deployment model expressed is, shall we say, Byzantine).
- rthomas6 12y ago
  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 12y ago
    There are quite a few comercial JVMs with native compilers the HN crowd tends to ignore.
  - kasey_junk 12y ago
    Fine but calling it slow is unfair, especially in relation to Go.
    - rthomas6 12y ago
      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.
pjmlp 12y ago
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 12y ago
  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.html http://adventgo.blogspot.ca/2014/05/origin-of-go-toolchain.h... [1] http://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.com/2012/06/less-is-exponentia...
  - NateDad 12y ago
    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...
psankar 12y ago
> that's how all compiled languages are You mean, like Java and C# ?!
- rthomas6 12y ago
  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 12y ago
    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.
lateefj 12y ago
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 12y ago
  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 https://github.com/wting/hackernews
- wtbob 12y ago
  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.
bsg75 12y ago
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.

kasey_junk 12y ago

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

rthomas6 12y ago
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 12y ago
  There are quite a few comercial JVMs with native compilers the HN crowd tends to ignore.
- kasey_junk 12y ago
  Fine but calling it slow is unfair, especially in relation to Go.
  - rthomas6 12y ago
    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.

pjmlp 12y ago

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 12y ago
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.html http://adventgo.blogspot.ca/2014/05/origin-of-go-toolchain.h... [1] http://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.com/2012/06/less-is-exponentia...
- NateDad 12y ago
  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...

psankar 12y ago

> that's how all compiled languages are You mean, like Java and C# ?!

rthomas6 12y ago
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 12y ago
  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.

lateefj 12y ago

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 12y ago
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 https://github.com/wting/hackernews
wtbob 12y ago
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.

bsg75 12y ago

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.