4 ms·

This. Is it really a surprise that the Python VM is not performant? I thought everyone knew that by now. Any reasonably well engineered VM (e.g. V8, JVM, Go) w

This. Is it really a surprise that the Python VM is not performant? I thought everyone knew that by now. Any reasonably well engineered VM (e.g. V8, JVM, Go) will blow it out of the water. This should be well known to anyone who calls themselves a software engineer. The Disqus system could have been written in a large number of other languages and have performed more or less the same as the Go system. The only advantage I can see of Go is that it's reasonably close to Python/Ruby in terms of semantics. If Python or Ruby is your only tool then Go might be a good choice. Not so if, for example, you're more into the functional style. Edit: Ok, so Go doesn't use a VM. It still has a runtime, as all languages must. Substitute runtime for VM above as appropriate. Point still stands.

voidlogic 13y ago
>>Any reasonably well engineered VM (e.g. V8, JVM, Go) will blow it out of the water. FYI, Go does not use a VM like V8 or the JVM; Go code compiles to native binary. However, like many VM based languages and unlike (a lot of) C, Go should be write once, (compile) and run everywhere(Win,Lin,BSD,Mac). Also like many VM languages Go is type/memory safe and is garbage collected. Edit: It appears V8 is also not a VM, it is a interpreter that performs just-in-time (JIT) compilation of source with no intermediate representation such as bytecode (Java instead JITs bytecode). This makes sense since Java programs are distributed as bytecode and Javascript programs are distributed as source. @calinet6: Thanks for pointing this out. Life-cycles: Developer's machine | Runtime -------------------------------------------------------- Go: source->binary | exec binary Java: source->bytecode | interp. bytecode / JIT & exec bin JS: source | interp. source / JIT & exec bin
- pjmlp 13y ago
  It is going to take ages to clear young developer minds that safe strong typed languages don't require a VM and we have to thank Sun and Microsoft to have spread that misconception.
  - pstuart 13y ago
    As an older developer, I'm ok with that :-)
  - drivebyacct2 13y ago
    Where does that come from? People who have only ever used Java or C#? I mean, there's nothing conceptually about VMs or strong typing that would lead to such a conclusion?
    - pjmlp 13y ago
      I would say, it is developers that: - started coding after Java and .NET became mainstream - only know C and C++ as compiled languages, never tried anything else (e.g. Modula-2, Delphi, Haskell, ...) - lack CS background So they think any language with stronger type system than C or C++ can only be provided via a VM based runtime.
- prodigal_erik 13y ago
  Does V8 specify a virtual machine and instruction set which you could make a real processor for? I thought it went straight from Javascript to either x86 or ARM.
  - calinet6 13y ago
    Correct, V8 compiles Javascript directly to machine code in a JIT fashion; there is no intermediate instruction set or bytecode. https://developers.google.com/v8/design?hl=es-ES#mach_code https://developers.google.com/v8/design?hl=es-ES#mach_code So in that sense, yeah, V8 is not really a VM but just a JIT compiler/interpreter.
- pjmlp 13y ago
  There are native code compilers for Java, like gjc, JET, Aonix, RoboVM, Aicas, ...
- JulianMorrison 13y ago
  Also, Go (via its usual compiler) is even more self contained than most binary languages: it compiles to a statically linked binary - it doesn't even depend on /usr/lib. If the CPU and OS is good, you can just throw around the binary with scp and run it wherever, no setup.
  - pjmlp 13y ago
    That used to be like that in any non UNIX OS back in the old days, direct calls to the kernel.
deleted 13y ago
[deleted]
calinet6 13y ago
Minor (or major, considering it's the main topic of this article) correction: Go does not run in a VM. It compiles to native executable binaries.
raverbashing 13y ago
Yes Then try PyPy
- mindcrime 13y ago
  Or Jython. From what I've seen, the Jython guys have been at the forefront of squeezing more performance out of the JVM, especially using the new invokedynamic / Method handles stuff.
  - raverbashing 13y ago
    I'm not sure how compatible Jython is with most code, Pypy has some issues as well so it may not be possible to run somethings.
obviouslygreen 13y ago
"Point still stands" is a pretty snarky response considering you got important details flat-out wrong while suggesting your "information" should be "well known to anyone who calls themselves a software engineer." It's OK to be wrong, just don't be a jackass about it... people will take you a lot more seriously if you're gracious when they notice it.
- noelwelsh 13y ago
  Let me try to be clearer: The CPython implementation is very slow. There are many language implementations that are much faster (e.g. O'Caml, Haskell, Scala, Clojure, Java, Lua, C, probably Rust). Any one of these is likely to produce a system about as fast as the Go system with about the same amount of effort. Thus dwelling on Go being faster than Python is not interesting. What is interesting is the properties of Go that make it better or worse suited to particular organisations and problems. This is what I tried to get at in the second paragraph. The precise implementation strategy of Go/Python/V8/whatever is interesting in its own right but irrelevant to my points.
  - zem 13y ago
    i'm guessing go is easier to translate python code to than any of the languages you mentioned, so "with about the same amount of effort" is not true.
- klibertp 13y ago
  Wait, what? You mean that the claim that "they could write it in a number of other languages" was falsified? Or maybe you think that "Python VM is slow"? No? Then these points still stand. Geez. There is nothing special about ditching Python and getting speedups. Just last week I did the same with rewriting a service in Erlang - and I'm almost certain that it will perform even better on 8 cpus than even Go would.

voidlogic 13y ago

>>Any reasonably well engineered VM (e.g. V8, JVM, Go) will blow it out of the water. FYI, Go does not use a VM like V8 or the JVM; Go code compiles to native binary. However, like many VM based languages and unlike (a lot of) C, Go should be write once, (compile) and run everywhere(Win,Lin,BSD,Mac). Also like many VM languages Go is type/memory safe and is garbage collected. Edit: It appears V8 is also not a VM, it is a interpreter that performs just-in-time (JIT) compilation of source with no intermediate representation such as bytecode (Java instead JITs bytecode). This makes sense since Java programs are distributed as bytecode and Javascript programs are distributed as source. @calinet6: Thanks for pointing this out. Life-cycles: Developer's machine | Runtime -------------------------------------------------------- Go: source->binary | exec binary Java: source->bytecode | interp. bytecode / JIT & exec bin JS: source | interp. source / JIT & exec bin

pjmlp 13y ago
It is going to take ages to clear young developer minds that safe strong typed languages don't require a VM and we have to thank Sun and Microsoft to have spread that misconception.
- pstuart 13y ago
  As an older developer, I'm ok with that :-)
- drivebyacct2 13y ago
  Where does that come from? People who have only ever used Java or C#? I mean, there's nothing conceptually about VMs or strong typing that would lead to such a conclusion?
  - pjmlp 13y ago
    I would say, it is developers that: - started coding after Java and .NET became mainstream - only know C and C++ as compiled languages, never tried anything else (e.g. Modula-2, Delphi, Haskell, ...) - lack CS background So they think any language with stronger type system than C or C++ can only be provided via a VM based runtime.
prodigal_erik 13y ago
Does V8 specify a virtual machine and instruction set which you could make a real processor for? I thought it went straight from Javascript to either x86 or ARM.
- calinet6 13y ago
  Correct, V8 compiles Javascript directly to machine code in a JIT fashion; there is no intermediate instruction set or bytecode. https://developers.google.com/v8/design?hl=es-ES#mach_code https://developers.google.com/v8/design?hl=es-ES#mach_code So in that sense, yeah, V8 is not really a VM but just a JIT compiler/interpreter.
pjmlp 13y ago
There are native code compilers for Java, like gjc, JET, Aonix, RoboVM, Aicas, ...
JulianMorrison 13y ago
Also, Go (via its usual compiler) is even more self contained than most binary languages: it compiles to a statically linked binary - it doesn't even depend on /usr/lib. If the CPU and OS is good, you can just throw around the binary with scp and run it wherever, no setup.
- pjmlp 13y ago
  That used to be like that in any non UNIX OS back in the old days, direct calls to the kernel.

deleted 13y ago

[deleted]

calinet6 13y ago

Minor (or major, considering it's the main topic of this article) correction: Go does not run in a VM. It compiles to native executable binaries.

raverbashing 13y ago

Yes Then try PyPy

mindcrime 13y ago
Or Jython. From what I've seen, the Jython guys have been at the forefront of squeezing more performance out of the JVM, especially using the new invokedynamic / Method handles stuff.
- raverbashing 13y ago
  I'm not sure how compatible Jython is with most code, Pypy has some issues as well so it may not be possible to run somethings.

obviouslygreen 13y ago

"Point still stands" is a pretty snarky response considering you got important details flat-out wrong while suggesting your "information" should be "well known to anyone who calls themselves a software engineer." It's OK to be wrong, just don't be a jackass about it... people will take you a lot more seriously if you're gracious when they notice it.

noelwelsh 13y ago
Let me try to be clearer: The CPython implementation is very slow. There are many language implementations that are much faster (e.g. O'Caml, Haskell, Scala, Clojure, Java, Lua, C, probably Rust). Any one of these is likely to produce a system about as fast as the Go system with about the same amount of effort. Thus dwelling on Go being faster than Python is not interesting. What is interesting is the properties of Go that make it better or worse suited to particular organisations and problems. This is what I tried to get at in the second paragraph. The precise implementation strategy of Go/Python/V8/whatever is interesting in its own right but irrelevant to my points.
- zem 13y ago
  i'm guessing go is easier to translate python code to than any of the languages you mentioned, so "with about the same amount of effort" is not true.
klibertp 13y ago
Wait, what? You mean that the claim that "they could write it in a number of other languages" was falsified? Or maybe you think that "Python VM is slow"? No? Then these points still stand. Geez. There is nothing special about ditching Python and getting speedups. Just last week I did the same with rewriting a service in Erlang - and I'm almost certain that it will perform even better on 8 cpus than even Go would.