1. 11

  2. 11

    Gradually switching languages to something “better” (e.g. to a language with a better domain fit), seems like a very reasonable approach that I see quite often. Frequently stories present the migration to a different stack almost apologetically, as a tale of “we should have done this first”.

    However, I think starting off in a language that your team has competency in, and/or a language that is easy to hire for, and optimizing for early development speed, is often the right first choice. Later when needs/requirements change (such as you need higher performance, or higher concurrency), switching to a new tech stack makes sense. Hopefully you have more resources at your disposal at that point as well (funding, more engineers, etc).

    Coupled with the old adage of “throw the first one away”, I think people should more often feel good about this decision, instead of almost feeling bad about it and/or making excuses about the historical choice.

    This article seemed pretty positive about the historical choices made, which I found refreshing.

    1. 2

      Agreed! I would love to rewrite my Large Project simply to know everything is clean and does just what I want. If they have time to rewrite in almost any way, seems like a positive.

    2. 4

      I’m really curious how much of their 100ms to 10ms response mean was just not using django in the first place.

      1. -1

        10ms? I find that hard to believe. That service must not be touching a database.