6 ms·

An interesting tidbit I learnt from a former colleague: He wrote a small but non-trivial project in Go, and ended up re-writing in Python. Over time, he and hi

An interesting tidbit I learnt from a former colleague: He wrote a small but non-trivial project in Go, and ended up re-writing in Python. Over time, he and his team measured both codebases and found that they had roughly the same number of bugs per line of code, but the Python codebase was 1/3rd of the lines of code, therefore had far fewer bugs. I wouldn't attribute this to inexperience either, this is one of the best engineers I've worked with.

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.
defertoreptar 8y ago
So during the rewrite, he had the providence of the go codebase to look back on, and the Python version still had as many bugs per lines? That sounds like an argument for go, if anything.
- danpalmer 8y ago
  This is true, I don't know the specifics, but I would trust that my former colleague wouldn't make such a claim based on such incorrect data. My guess these bugs were "code" bugs rather than "product" bugs, if that distinction makes sense.
deleted 8y ago
[deleted]
theonemind 8y ago
From what I've seen (though I can't find any sources to back it up, apply the appropriate amount of salt), having a number of bugs or defects proportional to the lines of code constitutes one of the robust findings in that pretty muddy area of the world (Does OO increase productivity? Static typing superior? .. at least we know, I think, that bugs run in proportion to lines of code, regardless of language)
weberc2 8y ago
I have the opposite experience. I've rewritten several services from Python to Go; while Go ends up being more lines of code, the type checker actually found far more bugs. When I'm ready to deploy the new service, I'll route a copy of the production traffic to the new service and observe differences in behavior, and the Go version (despite being very young) typically has ~10 percent of the bugs (_especially_ in error paths). Further, the performance usually improves by one or two orders of magnitude, depending on whether or not the old Python code was async (async Python is even buggier than sync Python in our experience) and how CPU-intensive the program was. Lastly, I iterate much more quickly in Go despite having more experience in Python, entirely because the type checker catches silly errors that I would otherwise have to find and fix in a test loop.
fierro 8y ago
Just having strong typing alone has reduced the number of bugs for me, speaking anecdotally

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.

defertoreptar 8y ago

So during the rewrite, he had the providence of the go codebase to look back on, and the Python version still had as many bugs per lines? That sounds like an argument for go, if anything.

danpalmer 8y ago
This is true, I don't know the specifics, but I would trust that my former colleague wouldn't make such a claim based on such incorrect data. My guess these bugs were "code" bugs rather than "product" bugs, if that distinction makes sense.

deleted 8y ago

[deleted]

theonemind 8y ago

From what I've seen (though I can't find any sources to back it up, apply the appropriate amount of salt), having a number of bugs or defects proportional to the lines of code constitutes one of the robust findings in that pretty muddy area of the world (Does OO increase productivity? Static typing superior? .. at least we know, I think, that bugs run in proportion to lines of code, regardless of language)

weberc2 8y ago

I have the opposite experience. I've rewritten several services from Python to Go; while Go ends up being more lines of code, the type checker actually found far more bugs. When I'm ready to deploy the new service, I'll route a copy of the production traffic to the new service and observe differences in behavior, and the Go version (despite being very young) typically has ~10 percent of the bugs (_especially_ in error paths). Further, the performance usually improves by one or two orders of magnitude, depending on whether or not the old Python code was async (async Python is even buggier than sync Python in our experience) and how CPU-intensive the program was. Lastly, I iterate much more quickly in Go despite having more experience in Python, entirely because the type checker catches silly errors that I would otherwise have to find and fix in a test loop.

fierro 8y ago

Just having strong typing alone has reduced the number of bugs for me, speaking anecdotally