4 ms·

I think people write in Go because it's ostensibly faster in runtime (and maybe easier to deploy). It always was going to require more lines of code than langu

by fouc 8y ago

I think people write in Go because it's ostensibly faster in runtime (and maybe easier to deploy). It always was going to require more lines of code than languages like Python or Ruby, that's not a surprise at all?

danpalmer 8y ago
The fact it required more lines was expected. The fact that despite the additional tooling, type system, safety, etc, it had 3x more bugs than a Python implementation was unexpected.
- IshKebab 8y ago
  3x more bugs that you know about. I wouldn't be surprised if Go's static type system just found more bugs, and the Python program had just as many bugs but you didn't happen to hit them at runtime.
  - bb88 8y ago
    I would assume he's talking about non-type system bugs. In 2018, most people won't look at a PR unless it compiles and the unit tests works.
    - danpalmer 8y ago
      I got the impression these were bugs that made it into a tracker of some sort, and I don’t think most engineers log “bugs” they encounter during local development before some notion of a release (be it to staging, the world, the master branch, whatever).
  - zzzcpan 8y ago
    Go static type system doesn't find bugs a Python program might have, but introduces plenty of possibilities for bugs too.
    - PeterisP 8y ago
      Can you elaborate about types of bugs that are caused by a static type system, about extra possibilities introduced by it? There are many commonly understood disadvantages of static type systems, but extra possibilities for bugs usually isn't among them.
  - nwmcsween 8y ago
    The type system has to support the language features, there are tons or races, deadlocks etc due to go language features without a type system to express these features.
- zzzcpan 8y ago
  It shouldn't be unexpected, it's very natural. I guess it's a bit hard to grasp why, in which case there are bug studies showing same effects. Essentially higher level of reasoning (think reasoning about fewer things) and producing less code for the same functionality creates fewer possibilities for mistakes.

by fouc 8y ago

danpalmer 8y ago

The fact it required more lines was expected. The fact that despite the additional tooling, type system, safety, etc, it had 3x more bugs than a Python implementation was unexpected.

IshKebab 8y ago
3x more bugs that you know about. I wouldn't be surprised if Go's static type system just found more bugs, and the Python program had just as many bugs but you didn't happen to hit them at runtime.
- bb88 8y ago
  I would assume he's talking about non-type system bugs. In 2018, most people won't look at a PR unless it compiles and the unit tests works.
  - danpalmer 8y ago
    I got the impression these were bugs that made it into a tracker of some sort, and I don’t think most engineers log “bugs” they encounter during local development before some notion of a release (be it to staging, the world, the master branch, whatever).
- zzzcpan 8y ago
  Go static type system doesn't find bugs a Python program might have, but introduces plenty of possibilities for bugs too.
  - PeterisP 8y ago
    Can you elaborate about types of bugs that are caused by a static type system, about extra possibilities introduced by it? There are many commonly understood disadvantages of static type systems, but extra possibilities for bugs usually isn't among them.
- nwmcsween 8y ago
  The type system has to support the language features, there are tons or races, deadlocks etc due to go language features without a type system to express these features.
zzzcpan 8y ago
It shouldn't be unexpected, it's very natural. I guess it's a bit hard to grasp why, in which case there are bug studies showing same effects. Essentially higher level of reasoning (think reasoning about fewer things) and producing less code for the same functionality creates fewer possibilities for mistakes.