10 ms·

Everybody compares Go and Python. How is it so? Go compiles to a binary, implements static typing, got rid of classes, got rid of exceptions, and added lots of

Everybody compares Go and Python. How is it so? Go compiles to a binary, implements static typing, got rid of classes, got rid of exceptions, and added lots of special purpose keywords on top of reinventing C's syntax. The only similarity I see is the "import" statement.

benmanns 13y ago
I've read that people have had success doing line-by-line conversions of Python scripts to Go scripts without too much reworking. I am guessing that it is the similar level of model and library granularity that drives the comparison.
- aeden 13y ago
  If your Python (or in my case, Ruby) script is highly procedural then the transition over to Go is quite straightforward. The first production Go app I rolled out followed this pattern (previously a small, procedural Ruby script, now a small, procedural Go app) and I'm quite happy with the results. The resource usage is so much better with Go for this case that it really was the perfect case for switching.
  - benmanns 13y ago
    I saw on your blog that you've jumped to full time on DNSimple (congrats). Are you using Go app you wrote as part of the DNSimple system?
    - aeden 13y ago
      Yes. We use it for our redirector (which is the project I mentioned that I switched over) and we're using it for a new zone server that we're working on that is used by our new name servers (which are written in Erlang).
- genwin 13y ago
  I've had success doing that, while never having written in Python.
jlgreco 13y ago
They both approximately match up on mental effort /friction/hassle for me, which largely seems to be coincidence since they do have dissimilar feature sets. For example, it use to be that I would use Python when I thought that C (my language of choice) was going to be too much of a hassle; now I use Go when I think that C will be too much hassle. I think this accounts for a large portion of the Go<->Python talk you see.
- SiVal 13y ago
  When app(lication)s meant desktop apps, most of us used C as an app dev language. Over the years, the platform changed and most app developers switched to Java and C# and, more recently, to Python and Ruby. Those who still use C these days mostly use it to deal with unusually demanding constraints (performance, memory, etc.) They use C when only C will do, which usually is not for apps. C is not the default app programming language; it's a special-purpose language of sorts. Go is not very competitive with C at what people mostly use C for these days: tightest constraints and maximum customization. Go is very competitive with Python (& Ruby), though, as a high-productivity app development language, being almost as productive as those two but with much higher performance, lower memory requirements, and no need to install a big runtime. It's biggest shortcoming, vis-a-vis Py & Ruby, is the immaturity of its environment (libraries, toolchains, web frameworks, etc) due to its relative newness. As that changes, many will switch from P&R to Go, but fewer will switch from C to Go, because most who don't absolutely need C have already switched away from it.
  - jlgreco 13y ago
    I fear I was unclear; I was not advocating using Go in the place of C. Rather I now using Go in the place of Python, in situations where C was not appropriate (traditionally my hobby projects have been something C is appropriate for, or something that Python is appropriate for).
    - SiVal 13y ago
      No, you were clear, and I seem to be thinking the same way your are. Mine was a more general comment on the common observation that Go is pulling more people away from Python than away from C. App developers who don't need the bit-by-bit customization power of C have already left it for more productive languages such as Python. Those who continue to use C are those who really need the bit-by-bit customization that C provides but Go and Python don't. Those who already left C for the huge productivity boost offered by Python can get back a lot of the performance and size advantages they left behind without giving up much of the productivity by switching to Go. That's an attractive option.
pjmlp 13y ago
Because it seems most new Go coders come from Python or Ruby, with limited experience in any other language. As such you tend to see a comparison with the other language they know, which for many is Python.
isbadawi 13y ago
Go has interfaces that you implement just by having the methods, without declaring that you're implementing the interface (e.g. "implements" in Java). This kind of feels like duck typing in python. For example, in python lots of APIs work with file-like objects, e.g. anything with a read method -- you can do the same sort of thing in Go.
- aeden 13y ago
  Almost, except that you still do have to be conscious of argument and return types. The one thing that still catches me (and I'm a relative newbie in Go, so that's probably why) is attempting to return nil when the return type won't allow it, such as the case when the return type is a string. It feels weird, but at least the compiler catches it so I can fix it and move on.
- bad_user 13y ago
  Structural typing is nothing like duck typing. People saying that don't know what they are talking about. Yes, both features allow one to escape the manifest typing present in languages like Java. But duck typing is so much more, as duck typing allows you to make shit up at runtime (e.g. come up with new interfaces based on the data you have). By definition a static type system will reject pieces of computation that are correct when described in a dynamic type system. Also Go's static type system isn't even a good static type system, as it makes it next to impossible to work with monads or Haskell's Maybe. And serving as proof that Go's type system is weak, consider how these are non-issues in Haskell or Scala or dynamic languages such as Ruby or Clojure (yes, Clojure developers are know to use monads when it makes sense to do so). Go's type system is a rather poor implementation of features that were properly implemented in other languages, such as Ocaml or Haskell. It's a shame really that such an awful implementation gained so much popularity on account of Google, but on the other hand I view it as a fad that will pass like all the rest.
  - pacala 13y ago
    I'll bite. What are useful uses of monads, other than implementing exceptions, async, state and IO? Granted, it's aestethically pleasing to have a really tiny core on which to layer more sugar, but sometimes using the language as-is suffices. The mother of all monads is Cont (http://blog.sigfpe.com/2008/12/mother-of-all-monads.html http://blog.sigfpe.com/2008/12/mother-of-all-monads.html), but that belongs in the bowels of the compiler.
mseepgood 13y ago
> and added lots of special purpose keywords on top of reinventing C's syntax Added? I think Go has less keywords than C in total.

benmanns 13y ago

I've read that people have had success doing line-by-line conversions of Python scripts to Go scripts without too much reworking. I am guessing that it is the similar level of model and library granularity that drives the comparison.

aeden 13y ago
If your Python (or in my case, Ruby) script is highly procedural then the transition over to Go is quite straightforward. The first production Go app I rolled out followed this pattern (previously a small, procedural Ruby script, now a small, procedural Go app) and I'm quite happy with the results. The resource usage is so much better with Go for this case that it really was the perfect case for switching.
- benmanns 13y ago
  I saw on your blog that you've jumped to full time on DNSimple (congrats). Are you using Go app you wrote as part of the DNSimple system?
  - aeden 13y ago
    Yes. We use it for our redirector (which is the project I mentioned that I switched over) and we're using it for a new zone server that we're working on that is used by our new name servers (which are written in Erlang).
genwin 13y ago
I've had success doing that, while never having written in Python.

jlgreco 13y ago

They both approximately match up on mental effort /friction/hassle for me, which largely seems to be coincidence since they do have dissimilar feature sets. For example, it use to be that I would use Python when I thought that C (my language of choice) was going to be too much of a hassle; now I use Go when I think that C will be too much hassle. I think this accounts for a large portion of the Go<->Python talk you see.

SiVal 13y ago
When app(lication)s meant desktop apps, most of us used C as an app dev language. Over the years, the platform changed and most app developers switched to Java and C# and, more recently, to Python and Ruby. Those who still use C these days mostly use it to deal with unusually demanding constraints (performance, memory, etc.) They use C when only C will do, which usually is not for apps. C is not the default app programming language; it's a special-purpose language of sorts. Go is not very competitive with C at what people mostly use C for these days: tightest constraints and maximum customization. Go is very competitive with Python (& Ruby), though, as a high-productivity app development language, being almost as productive as those two but with much higher performance, lower memory requirements, and no need to install a big runtime. It's biggest shortcoming, vis-a-vis Py & Ruby, is the immaturity of its environment (libraries, toolchains, web frameworks, etc) due to its relative newness. As that changes, many will switch from P&R to Go, but fewer will switch from C to Go, because most who don't absolutely need C have already switched away from it.
- jlgreco 13y ago
  I fear I was unclear; I was not advocating using Go in the place of C. Rather I now using Go in the place of Python, in situations where C was not appropriate (traditionally my hobby projects have been something C is appropriate for, or something that Python is appropriate for).
  - SiVal 13y ago
    No, you were clear, and I seem to be thinking the same way your are. Mine was a more general comment on the common observation that Go is pulling more people away from Python than away from C. App developers who don't need the bit-by-bit customization power of C have already left it for more productive languages such as Python. Those who continue to use C are those who really need the bit-by-bit customization that C provides but Go and Python don't. Those who already left C for the huge productivity boost offered by Python can get back a lot of the performance and size advantages they left behind without giving up much of the productivity by switching to Go. That's an attractive option.

pjmlp 13y ago

Because it seems most new Go coders come from Python or Ruby, with limited experience in any other language. As such you tend to see a comparison with the other language they know, which for many is Python.

isbadawi 13y ago

Go has interfaces that you implement just by having the methods, without declaring that you're implementing the interface (e.g. "implements" in Java). This kind of feels like duck typing in python. For example, in python lots of APIs work with file-like objects, e.g. anything with a read method -- you can do the same sort of thing in Go.

aeden 13y ago
Almost, except that you still do have to be conscious of argument and return types. The one thing that still catches me (and I'm a relative newbie in Go, so that's probably why) is attempting to return nil when the return type won't allow it, such as the case when the return type is a string. It feels weird, but at least the compiler catches it so I can fix it and move on.
bad_user 13y ago
Structural typing is nothing like duck typing. People saying that don't know what they are talking about. Yes, both features allow one to escape the manifest typing present in languages like Java. But duck typing is so much more, as duck typing allows you to make shit up at runtime (e.g. come up with new interfaces based on the data you have). By definition a static type system will reject pieces of computation that are correct when described in a dynamic type system. Also Go's static type system isn't even a good static type system, as it makes it next to impossible to work with monads or Haskell's Maybe. And serving as proof that Go's type system is weak, consider how these are non-issues in Haskell or Scala or dynamic languages such as Ruby or Clojure (yes, Clojure developers are know to use monads when it makes sense to do so). Go's type system is a rather poor implementation of features that were properly implemented in other languages, such as Ocaml or Haskell. It's a shame really that such an awful implementation gained so much popularity on account of Google, but on the other hand I view it as a fad that will pass like all the rest.
- pacala 13y ago
  I'll bite. What are useful uses of monads, other than implementing exceptions, async, state and IO? Granted, it's aestethically pleasing to have a really tiny core on which to layer more sugar, but sometimes using the language as-is suffices. The mother of all monads is Cont (http://blog.sigfpe.com/2008/12/mother-of-all-monads.html http://blog.sigfpe.com/2008/12/mother-of-all-monads.html), but that belongs in the bowels of the compiler.

mseepgood 13y ago

> and added lots of special purpose keywords on top of reinventing C's syntax Added? I think Go has less keywords than C in total.