Hacker News Reader

Comment by ferdowsi | Hacker News Reader

My understanding is that Dropbox has been building performance-critical parts of their services in Go since 2014 at the least. https://twitter.com/jamwt/status/629727590782099456

Like many companies, they had initial scaling successes with Python,hit performance bottlenecks and looked for a way out with faster languages.

View on HN

Sure, Rust too for some of the desktop app components. But the takeaway is you only need to do that when you're operating at mega scale and actually hit these bottlenecks.

In a ton of cases you'll be completely fine serving a few million monthly page views of your SAAS app on a single $20-40 a month server using Flask, Django or whatever Python web framework you prefer. Performance will be really good too. Just talking about most apps where it's mainly reading and writing data to a DB.

You may be better off using rails instead to fully capitalize on rapid development through automagic.

I mean, yes, if you know Ruby. If you as a founder know Python, just use Django. They're sister frameworks.

I'm a solo dev.

I write all my backend code in Go (used Python before Go existed) because I can deploy Go executable on the cheapest render.com server and it runs using fraction of the available resources (~50 MB out of 512 MB available and literally 0.01% CPU use).

If I used Python (or Ruby, node or even Java) I would likely have to go higher (and pay more) because those languages are not only slow, they are also memory hogs.

I'm as productive in Go as I used to be in Python, I see no reason not to use Go.

I gave Go a try recently and it was a quite pleasant experience. I don't see why I wouldn't use it for greenfield work over Python.

Microscopic cost optimization is frequently not a problem, but it's great if you can get it for low effort with Go. It's highly contextual whether it'll matter that much in both the short and long-term. You're situation as a solo dev is special and can't be easily extrapolated to efforts involving many people. The things that make solo dev great are hinderances to collaborative work efforts (by design in many cases.)

As a frame of reference, ASP.NET services in C# can exceed the throughput and performance of an equivalent Django app, but Django (and Python) may be the best choice for some people. What's not considered here is the experience of the developer and whether they can avail of the platform capabilities fast. Do they need to rewrite libraries? How much work is needed to be as proficient as you are with Go? The language and platform choice is rarely a differentiator here.

Over the long-term you can see some patterns. Python companies are able to scale up their teams more quickly and cheaply in some markets than Go ones. You choose to optimize hosting cost while they optimize other costs. They may need to avail of libs like Pandas and these are readily available. I don't know what the situation is with Go today, but similar libs weren't available originally and the Go community didn't have a big foothold in data science.

That you can incrementally build performance-critical parts of your system in other languages is a huge success story for Python. I don't understand in what world you can view that as a negative.

If you were NOT able to do that, that would have actually been a reason to not build your app in Python.

"That you can incrementally build performance-critical parts of your system in other languages is a huge success story for Python."

Even 5-10 years ago, that's not a "huge success story"; that's table stakes for any serious language.

Sure, but that is the feature that enables people to build apps in slow, interpreted languages like Python in the first place. The parent comment had somehow made it sound like that was a negative.

I did not mean "huge win" as in it is something unique to Python. I meant it in the sense that it greatly adds to the value proposition of the language.

So? If they started with those faster languages they'd have slowed down their rolling of features initially. They might not even be here now.

i find this pattern utterly funny

it's always the same

prototype in an easy language

tighten the bolts closer to the metal after some time

Reply on news.ycombinator.com