1. 12
  1.  

  2. 5

    :) Very entertaining read. I’ve been picking up some smaller components in GO lately. I’ve also rewritten a component I originally built in Python in GO. Which gives a nice but anecdotal comparison:

    Python: 11 days of development, performance, 160ms for ranking 3600 activities GO: 3 days of development, performance, 6ms for ranking 3600 activities

    The project is quite simple. It reads a ranking formula and turns it into a function which runs scoring on a large list of activities. Here’s an example ranking config:

    {
    "functions":{
      "simple_gauss":{
        "base":"decay_gauss",
        "scale":"5d",
        "offset":"1d",
        "decay":"0.3"
      },
      "popularity_gauss":{
        "base":"decay_gauss",
        "scale":"100",
        "offset":"5",
        "decay":"0.5"
      }
    },
    "defaults": {
        "popularity": 1
    },
    "score":"simple_gauss(time)*popularity"
    

    }

    So you basically you need to parse the score expression, translate it to AST, configure the defaults in the context, setup partials for the specified functions, add a bunch of builtin functions and create a huge set of test cases to make sure you’ve covered every possible way in which people can break it :)

    With Python most of the time was spent on benchmarking and performance optimization. The GO code started out at 15ms and with some super simple optimization came down to 6. (GO also had the unfair advantage of a better expression parsing library being available.)

    I used to believe that GO gives you better performance at the cost of developer productivity. For certain projects it definitely seems to beat Python at both productivity and performance though.

    1. 6

      Is it possible that some of the drop in development time was due to being familiar with the application because you had already written it once before?

      1. 3

        You beat me to it. There’s been a lot of rewrite stories debunked because the developers just got better at solving the problem since the first try. That included one with formal methods at IBM that got me where nobody mention it was a second implementation.

        The proper comparison is doing them both the same way with same primitives. That is closer to apples to apples.

        1. 2

          Yeay, it’s comparing apples and oranges :) On the other hand this was my first non-hello world GO project. I’ve been working with Python for 10 years now. GO is super easy to switch to if you’ve been working with Python.

          Most of the time with the Python version was spent on performance optimization. I think GO hits a sweet spot. The language is easy to use and quite productive. Maybe not as easy as Ruby or Python, but pretty close. GO is also not as fast as C++ or Java (it depends a bit on the code you’re running, but in general it’s a little bit slower).

          Basically you get close to C++ level performance at close to Python level ease of use. Now for most use cases i’d still recommend Python. (usually it’s just glue between heavily optimized databases and the overhead of python doesnt matter). But for use cases where the language performance matters, GO really hits a sweet spot.

          1. 3

            Nit: it’s Go, not GO.

            1. 3

              People are never going to get this right. It’s Go: not Golang, GO, Google’s Go, etc.

              1. 2

                haha, that’s probably the hardest aspect of learning Go :)