8 ms·

Good work! While speedups of go of the order of 30% in general are a good thing, they do point at the relative immaturity of the language. You would not be abl

Good work! While speedups of go of the order of 30% in general are a good thing, they do point at the relative immaturity of the language. You would not be able to get these kinds of seedups in gcc, where tings presumably already are close to optimal. Another worry I have is the 'backwards compatibility'. It sounds good but in the long run creates its own problems. I think Java and even Python run into major problems with this.

mseepgood 14y ago
Wasn't it Python 3 having major problems by not being backwards compatible? Django still doesn't support Python 3.
- Goranek 14y ago
  Django 1.5 is also the first release with Python 3 support
- ldng 14y ago
  Actually it does since last release. But they are not supporting it, yet. Most probably because surrounding libs haven't yet been adapted to Python 3.
fulafel 14y ago
> [Speedups] point at the relative immaturity of the language. You would not be able to get these kinds of seedups in gcc, where tings presumably already are close to optimal If you actually follow the links, you will see they are reimplementations of the algorithms in assembly. GCC doesn't have any crypto code, fast or otherwise. Crypto algorithms routinely get dramatic speedups when going from C to hand-coded assembly, C compilers produce code that is far from optimal. See eg. http://cr.yp.to/aes-speed.html http://cr.yp.to/aes-speed.html
laumars 14y ago
> Another worry I have is the 'backwards compatibility'. It sounds good > but in the long run creates its own problems. I think Java and even > Python run into major problems with this. At this point in Go's life, it makes more sense to be backwards compatible as the last thing you want to do is turn your back on your small current developer base. As Go grows and people have started adapting to the changes, then you can start depreciating the old stuff.
- LeonidasXIV 14y ago
  Exactly. For an example of doing it wrong, check out D. D is a great language (I'm reading The D programming language and it became one of my favorite books), but they broke compatibility between D1 and D2 and I am not even sure D2 is compatible with itself. And the compiler support is not yet mature. GDC has missed inclusion into GCC 4.8, while Go went into GCC 4.7, which makes using Go possible on a number of platforms and configurations.
  - pjmlp 14y ago
    That was mainly related to political issues with the language's runtime, which are sorted now.
stefantalpalaru 14y ago
Python shoot itself in the foot by breaking compatibility in version 3 and not even providing automated transition tools (like Go does). Look beyond the propaganda and notice the interval between the launch of Python3 and major libraries being ported to it.
- jerf 14y ago
  You mean like http://docs.python.org/2/library/2to3.html http://docs.python.org/2/library/2to3.html ? Static typing arguably makes it easier to provide a deeper and more accurate translation, but Python did at least try. And note that's a link to Python's official docs, not a side project or something; 2to3 was created by the core Python team as part of the official upgrade path, not an afterthought.
  - stefantalpalaru 14y ago
    "Sometimes 2to3 will find a place in your source code that needs to be changed, but 2to3 cannot fix automatically. In this case, 2to3 will print a warning beneath the diff for a file. You should address the warning in order to have compliant 3.x code."
    - jerf 14y ago
      Sorry, that's goalpost hiking. You said they didn't provide an automated transition tool, not that it wasn't perfect. Go's tools will only issue warnings in some cases too, so I'm really lost as to what you think you're saying here.
- jemeshsu 14y ago
  To be fair, Go promises only single version compatibility. Which means all point releases 1.x will be backward compatible. I can see Go 2 breaking compatibility.
  - stefantalpalaru 14y ago
    So far "go fix"[1] took care of incompatible changes pre-1.x . [1] http://golang.org/cmd/fix/ http://golang.org/cmd/fix/
melling 14y ago
Even though they are somewhat contrived benchmarks, I still like to refer to the "Language Shootout" to get some idea of the quality of code that the Go compiler is producing. I would expect the numbers should be better than Scala, for example. http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?test=all&lang=scala&lang2=go http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?t...
- im_dario 14y ago
  Just a note: Language Shootout is still Go 1.0.3. We are going to wait to see the new benchmarks.
  - igouy 14y ago
    Go 1.0.3 is the latest release.
    - voidlogic 14y ago
      True, but it is worth pointing out because this discussion is about 1.1 and people might not realize those are 1.0.3 benchmarks.
- gillianseed 14y ago
  Yes I too find the Language Shootout a very interesting benchmark (while knowing full and well it's shortcomings) and it shows (imo) that Go has alot of work to do in the optimization department, something one can confirm by compiling cpu intensive go code using gccgo which will often yield great performance improvements. Not surprising though, as GCC's optimization backend is very strong and has been developed for a long time, meanwhile Go's compiler toolchain is very young. As for Scala vs Go, Scala compiles into Java bytecode and then makes use of Java's excellent and very mature JIT compiler so I'm not surprised Go loses out to it for the same reasons mentioned above. Also note that the Go version used on the 'Language Shootout' is the 1.03 version, not the upcoming 1.1 version, it will be interesting to see what improvements in performance have been made. AFAIK the 32-bit version of Go (which is what you compared with in your link) has not been given as much love in the optimization department as the 64-bit version, which I guess would do slightly better atleast.

mseepgood 14y ago

Wasn't it Python 3 having major problems by not being backwards compatible? Django still doesn't support Python 3.

Goranek 14y ago
Django 1.5 is also the first release with Python 3 support
ldng 14y ago
Actually it does since last release. But they are not supporting it, yet. Most probably because surrounding libs haven't yet been adapted to Python 3.

fulafel 14y ago

> [Speedups] point at the relative immaturity of the language. You would not be able to get these kinds of seedups in gcc, where tings presumably already are close to optimal If you actually follow the links, you will see they are reimplementations of the algorithms in assembly. GCC doesn't have any crypto code, fast or otherwise. Crypto algorithms routinely get dramatic speedups when going from C to hand-coded assembly, C compilers produce code that is far from optimal. See eg. http://cr.yp.to/aes-speed.html http://cr.yp.to/aes-speed.html

laumars 14y ago

> Another worry I have is the 'backwards compatibility'. It sounds good > but in the long run creates its own problems. I think Java and even > Python run into major problems with this. At this point in Go's life, it makes more sense to be backwards compatible as the last thing you want to do is turn your back on your small current developer base. As Go grows and people have started adapting to the changes, then you can start depreciating the old stuff.

LeonidasXIV 14y ago
Exactly. For an example of doing it wrong, check out D. D is a great language (I'm reading The D programming language and it became one of my favorite books), but they broke compatibility between D1 and D2 and I am not even sure D2 is compatible with itself. And the compiler support is not yet mature. GDC has missed inclusion into GCC 4.8, while Go went into GCC 4.7, which makes using Go possible on a number of platforms and configurations.
- pjmlp 14y ago
  That was mainly related to political issues with the language's runtime, which are sorted now.

stefantalpalaru 14y ago

Python shoot itself in the foot by breaking compatibility in version 3 and not even providing automated transition tools (like Go does). Look beyond the propaganda and notice the interval between the launch of Python3 and major libraries being ported to it.

jerf 14y ago
You mean like http://docs.python.org/2/library/2to3.html http://docs.python.org/2/library/2to3.html ? Static typing arguably makes it easier to provide a deeper and more accurate translation, but Python did at least try. And note that's a link to Python's official docs, not a side project or something; 2to3 was created by the core Python team as part of the official upgrade path, not an afterthought.
- stefantalpalaru 14y ago
  "Sometimes 2to3 will find a place in your source code that needs to be changed, but 2to3 cannot fix automatically. In this case, 2to3 will print a warning beneath the diff for a file. You should address the warning in order to have compliant 3.x code."
  - jerf 14y ago
    Sorry, that's goalpost hiking. You said they didn't provide an automated transition tool, not that it wasn't perfect. Go's tools will only issue warnings in some cases too, so I'm really lost as to what you think you're saying here.
jemeshsu 14y ago
To be fair, Go promises only single version compatibility. Which means all point releases 1.x will be backward compatible. I can see Go 2 breaking compatibility.
- stefantalpalaru 14y ago
  So far "go fix"[1] took care of incompatible changes pre-1.x . [1] http://golang.org/cmd/fix/ http://golang.org/cmd/fix/

melling 14y ago

Even though they are somewhat contrived benchmarks, I still like to refer to the "Language Shootout" to get some idea of the quality of code that the Go compiler is producing. I would expect the numbers should be better than Scala, for example. http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?test=all&lang=scala&lang2=go http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?t...

im_dario 14y ago
Just a note: Language Shootout is still Go 1.0.3. We are going to wait to see the new benchmarks.
- igouy 14y ago
  Go 1.0.3 is the latest release.
  - voidlogic 14y ago
    True, but it is worth pointing out because this discussion is about 1.1 and people might not realize those are 1.0.3 benchmarks.
gillianseed 14y ago
Yes I too find the Language Shootout a very interesting benchmark (while knowing full and well it's shortcomings) and it shows (imo) that Go has alot of work to do in the optimization department, something one can confirm by compiling cpu intensive go code using gccgo which will often yield great performance improvements. Not surprising though, as GCC's optimization backend is very strong and has been developed for a long time, meanwhile Go's compiler toolchain is very young. As for Scala vs Go, Scala compiles into Java bytecode and then makes use of Java's excellent and very mature JIT compiler so I'm not surprised Go loses out to it for the same reasons mentioned above. Also note that the Go version used on the 'Language Shootout' is the 1.03 version, not the upcoming 1.1 version, it will be interesting to see what improvements in performance have been made. AFAIK the 32-bit version of Go (which is what you compared with in your link) has not been given as much love in the optimization department as the 64-bit version, which I guess would do slightly better atleast.