5 ms·

The author wrote: > My hot take about most dynamic languages is that they are a poor fit for startups who have intentions of being long-term businesses I don'

by nickjj 5y ago

The author wrote: > My hot take about most dynamic languages is that they are a poor fit for startups who have intentions of being long-term businesses I don't think that's fair to say. There's plenty of long term businesses running at scale using dynamic languages. That's employee and load scale too. Dropbox is ~13 years old, has ~4 million lines of Python and operate at crazy scale. I ended up talking to one of their ex-engineers last month about how they build and deploy their set up at: https://runninginproduction.com/podcast/82-dropbox-gives-you-secure-access-to-all-of-your-files https://runninginproduction.com/podcast/82-dropbox-gives-you... Then there's Basecamp which is one of the oldest SAAS apps around using Rails and GitHub too which isn't quite as old but definitely falls into the long term business category.

yen223 5y ago
Unless something has changed, I believe Instagram is still on Django
- danpalmer 5y ago
  They are a heavily custom fork from a very old version of Django, but apparently much is still "recognisably Django".
danpalmer 5y ago
> My hot take about most dynamic languages is that they are a poor fit for startups who have intentions of being long-term businesses The classic rebuttal to this is that the company needs the best chance of surviving today, and can fix it tomorrow. There are problems with this approach, it's definitely harder to fix these problems later, but "at scale" is that really a problem? The big problem is getting to the scale, surviving long enough.
JeremyNT 5y ago
I think it really does depend on the domain. When it comes to web, "move fast and break things" is the norm, and the expectation. This is exactly where dynamic languages are great - so what if you don't have the cleanest code, so what if you throw exceptions due to mismatched data types, if you can get the MVP out there then you're already half way there. Let future generations deal with the tech debt, using the warchest you amass from all the funding you can get by showing off your successful launch. For lower level / systems programming, though, I think that's somewhat less true. Think about database plugins like timescale, or VPN solutions, etc - stuff that, if it breaks, somebody's having a really bad day. It's probably worth spending more time on robustness and then a statically typed compiled language can really help eliminate many classes of errors off the bat.
busterarm 5y ago
My career specialty is deployment at the 10^5 scale and I'd argue that Python has no business on Production systems. Heck, I'm a former career Rubyist and I'd say the same there too. At a certain point statically linked binaries are going to make several classes of hard problems to solve disappear entirely and is IMO baseline criteria for operating at this level. BEAM at least has some compelling features working in its favor that make it worth exploring operationally, but also it doesn't really operate at that very large scale. It's well-adapted for smaller scale systems.
- joelbluminator 5y ago
  > I'd argue that Python has no business on Production systems Well yes you would argue, you did. That doesn't make your argument true or important.
  - busterarm 5y ago
    Sorry, but at this scale of systems and how often you're replacing hosts, it's absolutely critical that you always have a deployable. That's not provably true in the Python ecosystem (unless you're insane and vendoring all of your dependencies separately for every single application you deploy). At the end of the day what you need is a statically linked binary. There are tools like cx_freeze and Nuitka that try and get you there but ultimately aren't worth the effort and give you other problems to solve as well. Or you could use cython, but again, more problems. You're simply better off using a language that reduces your (business) risks from the onset. I'm sorry that that makes you feel bad, but that's facts and anyone working at this scale will tell you so. We pretty much only deal with Python where we have to (in the ML space). If a company is really stubborn about it though it's often better to just not take those jobs.
- strzibny 5y ago
  > It's well-adapted for smaller scale systems. I wonder what they switch to at WhatsApp when they become medium scale.
  - 5y ago

by nickjj 5y ago

yen223 5y ago

Unless something has changed, I believe Instagram is still on Django

danpalmer 5y ago
They are a heavily custom fork from a very old version of Django, but apparently much is still "recognisably Django".

danpalmer 5y ago

> My hot take about most dynamic languages is that they are a poor fit for startups who have intentions of being long-term businesses The classic rebuttal to this is that the company needs the best chance of surviving today, and can fix it tomorrow. There are problems with this approach, it's definitely harder to fix these problems later, but "at scale" is that really a problem? The big problem is getting to the scale, surviving long enough.

JeremyNT 5y ago

I think it really does depend on the domain. When it comes to web, "move fast and break things" is the norm, and the expectation. This is exactly where dynamic languages are great - so what if you don't have the cleanest code, so what if you throw exceptions due to mismatched data types, if you can get the MVP out there then you're already half way there. Let future generations deal with the tech debt, using the warchest you amass from all the funding you can get by showing off your successful launch. For lower level / systems programming, though, I think that's somewhat less true. Think about database plugins like timescale, or VPN solutions, etc - stuff that, if it breaks, somebody's having a really bad day. It's probably worth spending more time on robustness and then a statically typed compiled language can really help eliminate many classes of errors off the bat.

busterarm 5y ago

My career specialty is deployment at the 10^5 scale and I'd argue that Python has no business on Production systems. Heck, I'm a former career Rubyist and I'd say the same there too. At a certain point statically linked binaries are going to make several classes of hard problems to solve disappear entirely and is IMO baseline criteria for operating at this level. BEAM at least has some compelling features working in its favor that make it worth exploring operationally, but also it doesn't really operate at that very large scale. It's well-adapted for smaller scale systems.

joelbluminator 5y ago
> I'd argue that Python has no business on Production systems Well yes you would argue, you did. That doesn't make your argument true or important.
- busterarm 5y ago
  Sorry, but at this scale of systems and how often you're replacing hosts, it's absolutely critical that you always have a deployable. That's not provably true in the Python ecosystem (unless you're insane and vendoring all of your dependencies separately for every single application you deploy). At the end of the day what you need is a statically linked binary. There are tools like cx_freeze and Nuitka that try and get you there but ultimately aren't worth the effort and give you other problems to solve as well. Or you could use cython, but again, more problems. You're simply better off using a language that reduces your (business) risks from the onset. I'm sorry that that makes you feel bad, but that's facts and anyone working at this scale will tell you so. We pretty much only deal with Python where we have to (in the ML space). If a company is really stubborn about it though it's often better to just not take those jobs.
strzibny 5y ago
> It's well-adapted for smaller scale systems. I wonder what they switch to at WhatsApp when they become medium scale.
- 5y ago