1. 34
  1.  

  2. 15

    I do sometimes worry that gains from a full refactor are mistaken from language gains. Hard to tell here, although their benchmarking tells me the lang at least had something to do with it:

    We did some preliminary benchmarking with Go concurrency and found that each network connection ate up only 4kb of RAM.

    1. 3

      Well there’s no question that Go, as a compiled language, is going to outperform interpreted languages like PHP or Ruby. The advantages of PHP or Ruby is fast development and simplicity, but definitely not speed.

      1. 4

        Erlang/Elixir are interpreted, and I kind of chuckled at 4kb/connection.

        1. [Comment removed by author]

          1. 6

            Into bytecode, which is then interpreted. Unless you’d like to suggest that Javascript is compiled now too?

            It’s kind of a silly distinction at this point.

    2. 9

      I think deployment is the main point for most people to pick Go. It’s an underplayed argument and everyone tends to focus on runtime performance itself.

      The first time we used Go was on arm7 boards running Yocto Linux. Slapping a single Go binary on top of that board in comparison to Ada, C, Python applications we used before was a godsend. Spitting out 20 binaries for different platform/architecture combinations in 28 seconds was incredible compared to building Yocto for 4 hours or solving dependency issues.

      It also made testing the software on regular boxes much easier, getting new people of the ground took minutes versus a long and error prone setup.

      Yeah the language is ‘boring’. That’s a nice thing actually. I also like the fact that the whole standard library is basically free of C FFI calls (except really low level parts of the std lib). The tooling is also nothing to sneer about. Stuff like goconvey, go oracle, go fmt, profilers, inline disassembler - they are all great. It is lacking on some fronts (debugging) but the mix of deployment, tooling, small feature scope of the language makes it really easy to pick up & suited for a nice set of tasks.

      1. 5

        The lack of tool support is what made me give up on Go. I really want an IDE, like ruby mine, pycharm, etc.

        The other difficulties were lack of generics.

        Everything else was okay.

        1. 4

          That seems strange to me, because I’ve found the tool support in Go to vastly outpace (e.g.) Ruby (my usual language). I’m using sublime+gosublime.

          1. 3

            All I want right now is an editor based debugger, the same kind of thing we have had for decades for C.

      2. 8

        we had 200 API servers running on m1.xlarge instance types with 24 unicorn workers per instance. This was to serve 3000 requests per second

        This is what blew my mind.

        1. 9

          Well, yeah.

          Given Little’s Law (L = λW), we can model this.

          λ is the arrival rate (3000 req/sec), W is the average duration (which we can estimate at 1 seconds), and L is the average number of requests in-flight at any point in time, which is 3000. 200 instances running 24 workers each is 4800 workers total, so they’re running at ~65% capacity, which seems reasonable.

          This is what happens when your scalability model is per-process but your processes are two or three orders of magnitude larger than a POSIX thread.

          1. 2

            An average response time of 1 second seems way too long, but I don’t know anything about Parse. Most Rails apps should be south of 300ms at least. Github and Shopify hover between 50 and 100ms.

            1. 2

              Seems, yes. Should, yes.

              Is? Probably not.

          2. 2

            Extrapolating from one of my higher-traffic apps that gets 60 requests per second, 200 servers sounds about right. FWIW We’re using 4 c3.large instances with 4 workers each, so I’d guess their traffic patterns are quite different - it’s definitely a different problem domain.

            I absolutely agree that a process per request model breaks down, and it does sound to me like moving beyond ruby made sense for their case. That’s the sort of problem that is great to have, honestly. This was a neat case study to read.

          3. 5

            Huh, last error mail I saw from them had no information on the problem, a glaring spelling error, and only suggested I go to an inactive forum for help. Today they were down for about four minutes but according to the dashboard everything was A-OK. No customer support. I’d strongly warn against using Parse.

            1. 1

              Have you tried Firebase?

              1. 3

                Hah, no, and I inherited this codebase. If I were starting a new thing I’d start with Postgres and add components when scaling that got hard.

            2. 3

              As far as I can tell, the story goes like this:

              “A company decides on working with Ruby and/or Ruby on Rails. The language/framework is great, they are able to create a successful application which has hockey stick growth and enables them to think about a full rewrite. They can even pick a new language and think of how appealing that might be for new employees because they can and want to hire new developers.

              After rewriting the codebase into this new language, seems look better and they are able to grow more or pay less for their infrastructure. Because of that, Ruby sucks."

              1. 3

                Despite the title, this does not appear to be a parody or a really old article.

                I think it’s a legitimate story of learning by an inexperienced team. You could replace “go” in their article with nearly any well-designed concurrent system that has strong types or good error checking.

                So maybe worth reading their perspective even if you already knew what they are painfully learning now, or think this must be a troll.

                1. 1

                  According to the title—"[…] From Ruby to Go and Saved Our Sanity"—using Go will alleviate severe mental illness? Why isn’t Golang all the buzz in professional psychologist and psychiatrist circles?

                  1. 55

                    Why isn’t Golang all the buzz in professional psychologist and psychiatrist circles?

                    Obviously, it is due to the lack of Generics! Those brand name drugs aren’t cheap.
                    I kid, I kid.

                    1. 12

                      That was awful. :)

                      1. 1

                        Oh, hehehe, I see what you did there. ;)

                    2. 1

                      Well, use the right tool for the job. If Ruby gives you too much trouble in too many places, stop using it. I’m looking forward to seeing how Go will develop over the years. In the end, we might agree that Go is generally more consistent and thought out than Ruby. You don’t compare C with PHP either, but in this case, Go even shines in thIs special task whereas Ruby is not useful for anything apart from Web applications. Always keep that in mind if you don’t want to be left behind.

                      1. 8

                        Ruby is not useful for anything apart from Web applications

                        Puppet, Chef, RubyMotion, Ruboto, a bunch of security tools - there’s a lot of non-webapp ruby out there.

                        1. 2

                          Ruby is not useful for anything apart from Web applications

                          I still like using Ruby for scripting. But for doing web applications, I don’t see myself using Ruby for much longer. I’ve been getting into Elixir and so far it’s much more pleasant to work with than Ruby for web development (at least, it is for me. YMMV).