Ask HN: When to switch startup backend from Python to Golang? | Hacker News Reader

Ask HN: When to switch startup backend from Python to Golang?

10 pointssilentsea9015 comments

Self explanatory question, but you could replace Python with NodeJS or any script like fast paced language, and Golang with Java or any sturdy compiled statically typed language

I don't want our startup to slow down much but also don't want our life to be hell (performance, code quality, jenga brick backend) later with our choices.

Did any of you start with Golang perhaps and felt you were as fast as perhaps Python would have made you?

Is there a standard canonical best practice around this?

View on HN

The limit for your startup's success is more likely to be your ability to acquire and keep users. After that, it might be your engineer's velocity - their ability to keep up with the pace of change as you learn what your users _actually_ need.

The performance of your backend can be very low on your priority list.

My experience there comes from working at Twitch. The entire video platform's backend was in Python for a long, long time - at least 5 years before some components moved to Go, piece-by-piece. The Python stuck around for over a decade in some fashion.

There are exceptions depending on what your startup does - if your fundamental _product_ depends upon serving millions of concurrent requests quickly on a really frugal budget, you probably already know that.

It isn't just performance that you can throw more instances at perhaps. It is also about dev productivity, readability of code (in spite of writing clean code), not making silly errors that would be caught by static typing easily.

Building in Python feels like playing Jenga - easy enough at first but every change after a while is made with a silent prayer and anxiety.

Right, that is much more important than performance, as I said as well.

But I think that whether your Python will age well or your Go depends more on the team and their level of experience with either tool. Use something reasonable, and pretty familiar, and stick to it. Don’t do dumb stuff like going crazy with metaprogramming, and avoid excessive abstraction - but those are just always the required conditions for keeping your group functioning well. Any language can be abused; abstraction is not really a property of a programming language choice.

The best practice in my humble opinion is to chose your stack and stick with it.

If you start with Python, you will use Python. Major rewrites in another programming language are not worth the time, the effort, nor the risk.

You could eventually replace some parts with golang to improve the performances, but that's unlikely going to be cost effective.

I spent a couple of years working on a Haskell backend and honestly the safety and performance wasn't worth it, compared to the agility of python.

Judicious use of mypy, unit testing and leaning heavily on the framework can keep things well organised

If you're hitting performance limits you likely have enough revenue to get some extra computing power and this might even be a viable long-term solution. Otherwise you can: - Build a service in the performant language - Embed C, Rust or Fortran into python

A full rewrite in a performant language is an option but almost never the right one in my experience. In any case optimise for development agility right now, which includes writing good organised code. You can cross the performance bridge when you come to it.

Tooling is quite good with Go and IMHO an average developer can become quite productive with it.

when you got enough money/growth/customers to hire devs for maintainability (but i always started with golang anyway, statically typed language = easier to reason, good for long term)

Probably never. Python is plenty fast most apps. And bigger servers are cheaper than a huge rewrite.

Also, Guido and team are working full time on speeding up Python.

Scalability at YouTube: https://youtu.be/G-lGCC4KKok?t=610

The Python is the less likely think that will suffocate you.

What did you suffer from in past projects with each of these languages?

thing*

The lack of typing was a huge pain. It sucks to not be able to navigate to the underlying library in your IDE, or navigate upwards in the calling stack etc because it is (afaik) hard for the IDE to help you navigate through this without typing. The larger the project, the slower it makes you since reading is 99% of your work.

Django, Flask etc have a lot of magic annotation business which became untenable after 2-3 years. It is really hard to reason about what they do and in what order. Much easier to reason about it with Java and Golang.

>It sucks to not be able to navigate to the underlying library in your IDE

Which IDE is that? Those I've seen you hit a key, say F12, when your cursor is on a function or a class and it takes you right to where it's defined in whatever module, or shows you a list of objects with the same name in the project and you pick the one you're interested in.

>Django, Flask etc have a lot of magic annotation business which became untenable after 2-3 years.

Which ones? There is some kind of magic in g, and the application context. Are you talking about those? What did it prevent you from doing, and how did you get around these issues?

It has been over 1.5 years, but it was Pycharm. I am not sure if my IDE was borked, but I remember struggling with both finding the library and the list of usages. I am happy to concede it may be my poor IDE setup.

We used Django at a startup I was at in 2018, so my memory fails me on the exact issues since it has been so long. I will have to revisit Django and try to find what it was.

Never. Use PyPy if you need to speed up your servers (note the caveats regarding C extensions, if you have any being used).

When you reach Google level scale and income.

So, never.

Reply on news.ycombinator.com