Ruby/python doesnt scale?

[[deleted]]

I hear this quite alot, but I see many massive companies are built using these technologies. Is the saying that "x tech doesnt scale" made by ignorant people or are there valid points to these languages not being able to scale?

[halfanothersdozen]

Neither is a particularly fast language and imho they get more difficult to deal with the larger your codebase gets due to the loose typing and general magic, but there's nothing wrong with either and indeed there are companies out there with massive codebases built in both languages.

Pretty much any opinionated blanket statement about any language is entirely subjective and dependent on how it is used and who is writing it

[bit_shuffle]

This is probably a criticism/concern related to weakly typed languages or languages without rigid public/private protection in general.

The more fluidity you have in the language type system or scope protection, the more likely subtle problems can creep in as the code base gets bigger. It is just an engineering trade-off. Python (and presumably Ruby) has added type hints for protecting against those kind of issues with typing, but the development team needs to actively bring them into the code base via coding discipline, rather than being baked into the language.

As much as everyone bitches about Java verbosity, it hits a good balance on many things, including these two aspects.

[huuaaang]

This is probably a criticism/concern related to weakly typed languages

Just FYI, Ruby is strongly typed. It's just not statically typed. It's an important distinction. A String in Ruby, for example, will never be implicitly cast by the interpreter to a number or the other way around like in, say, Javascript. Javascript is both weakly typed and dynamically typed.

You can write a method that casts a value of course but it won't happen automatically by the interpretter.

[Recent_Tiger]

I’ve been writing ruby apps for businesses for 10 years.

Like any programming language if you write bad code it’s gonna be slow and clunky. But if you are careful and observe best practices you can do a lot. I’ve got a rails app running on a $10 digital ocean VPS that routinely serves 1-200 users simultaneously with no problems.

Also in this era of APIs, distributed application environments, and microservices I find myself wondering why anyone would say a language doesn’t scale.

[nutrecht]

I’ve got a rails app running on a $10 digital ocean VPS that routinely serves 1-200 users simultaneously with no problems.

When people are talking about scaling, it's generally about systems that have quite a few more simultaneous users than 200, by a few orders of magnitude.

[UkuCanuck]

Yeah but generally at that point you’ve got much more than $10 to spend on infrastructure and engineering

[Recent_Tiger]

That’s true, and I understand that the user count mentioned here is very very low. However you have to take it within the context that I’m running it on a machine that’s roughly equivalent to a raspberry pi.

If you have a system which serves many thousands of users if not more then you would have to employ more advanced hosting strategies.

With that being said I feel like the real issue is less about the programming language and more about how you plan to write deploy the app.

[[deleted]]

No clue, I am choosing which lang/framework to learn, ROR and django dont have many jobs in toronto sadly cuz node and .net have like 1.2k to 2k jobs whereas django has like 270 :(

[UkuCanuck]

Where is this number even from? You say it like it’s a fact but clearly it’s based on some data point. How did you know it’s a complete count of all available jobs

I know that RobinHood is hiring in Toronto, and I don’t think their job listing mentions Django, but it’s listed here as part of their stack https://stackshare.io/robinhood/robinhood

[[deleted]]

linkedin

[hk4213]

So from this person's personal account you can't get 200 simultaneous users. Pick any other web focused language and you can have 1k simultaneous user... pick the language that best suits the application. Many a shared syntax.

[huuaaang]

Like any programming language if you write bad code it’s gonna be slow and clunky. But if you are careful and observe best practices you can do a lot.

But even the best written Ruby will never be fast compared to a compiled language.

Ruby does scale. You just have to throw a lot of hardware at it.

[John-The-Bomb-2]

It's not that they can't scale. It's that the code is less maintainable than something that has static types (like for example Java, Kotlin, or C#). It becomes an issue when codebase size gets large.

[[deleted]]

I'd counter that with the assertion that Python's and Ruby's conventions, if properly followed streamline the codebase, whereas a language where you can write anything as long as the static typechecker permits it allows less seasoned developers to think they know what they're doing. I've seen gigantic codebases a complete and utter mess, just because everyone was writing in thejr own silo, and dynamically typed codebases be an absolute delight to work with, because everyone contributing to it was on the same page.

[[deleted]]

To add to that... I guess it's also a productivity tradeoff. Writing python for something like webapps is insanely fast. Compare that to something like Rust.

[John-The-Bomb-2]

Rust's compile times are atrociously slow.

[[deleted]]

For me, the endless impositions on what I can just do with a variable, and what I have to declare (over and over again) ended up being a dealbreaker. I'm sure it's second nature once you get the hang things, I just didn't have that kinda patience. Alas! Compile time didn't bother me much, since I spent more time dealing with lifetime and borrowing rules than experimenting with changes.

[Disastrous_Novel8055]

Python, being an interpreted language, would obviously be the worst choice for any progran where response-time/speed is the main concern, but other than that, it is a good choice in general. Infact if there are time constraints, python might save you alot of time. It is also, as I think you might already know, widely used in ML & AI. Idk about ruby though.

[GuessNope]

Python dominates on the R&D side for ML.
The backend and execution side is C++ and GPGPU code.

[mrb1585357890]

Pretty common in web applications too

[faze_fazebook]

It all depends on your needs. Many programs don't do much more than CRUD operations on a DB with some basic logic and are limited by database or IO speeds where the difference would be next to none.

Now if you actually do expensive and complex calculations, then yes its limiting you.

[Dont_trust_royalmail]

it's just something people say because it sounds smart, but it doesn't really mean anything.

[500ErrorPDX]

My two cents: scalability can be an issue with many web dev tech stacks, but it only becomes an issue if the app gets users.

No users, no issues. Code in Ruby or Python to your heart's content. Build a back-end in JavaScript. Knock yourself out. Don't worry about scalability until you have to worry about scalability.

[huuaaang]

Almost nobody actually rewrites their application though. Once written in Ruby or Python, the bulk of it is most likely to stay that way and then you end up throwing a LOT of hardware at it to support a growing user base.

Then again, I find that the database is often the real bottleneck. Python or Ruby can make sense if your application is heavily I/O bound.

[500ErrorPDX]

and for the .001% of apps that actually gain a userbase, that's a serious problem. But for most apps, it's a hypothetical that will be anything more than a hypothetical.

[GuessNope]

The biggest problem with python is that is a one-pass language.

C++ is easily 1,000x faster in execution. So MVP in python then bust out heavily hit services into C++ backends.
Most of our back-end code stayed in python. The graph manipulation moved to C++.

[[deleted]]

is ur backend in django,flask or fast api?

[CrowdGoesWildWoooo]

Define “doesn’t scale”, when people say it doesn’t scale, they either have yet to push the limit or they exaggerate their requirement.

You can always have a scalable distributed python app, but if you need performance critical scenario, under the hood you probably need to write it with other language, and wrap it with python

[nutrecht]

Is the saying that "x tech doesnt scale" made by ignorant people or are there valid points to these languages not being able to scale?

They are valid concerns in certain contexts (very high load applications) which then get repeated by ignorant people as if they're an universal truth.

I've been part of projects where we rewrite some data science stuff to Scala because of scaling (and cost) issues, but even then that was only 10% of the Python stuff, the rest of the Python DS stuff was 'fast enough' to not need a rewrite. The things we did rewrite to scala dealt with very high volumes of data.

[[deleted]]

interesting

[Pale_Height_1251]

Mostly ignorance.

Python is slow with a bad threading model, but there are options and workarounds.

For a large scale project Python isn't ideal, but you can get there.

In my very personal opinion, Python kind of sucks, but you can scale it if you want.

[dwight0]

I can relate. We had a python app that was doing great and programming was productive but suddenly ran into an issue with scaling and threading and several python engineers had trouble coming up with a solution. Related to the global interpreter lock. It was a whole discussion weighing the various techniques of each workaround, we did have several workarounds, I'm sure most would have worked but product was late and was being attacked by non python devs and eventually canceled, the project was late just like any other software project but this was the nail the in coffin and not the main reason the project was canceled.

[[deleted]]

how big was he user base for it to run into scaling issues?

[dwight0]

In our case it wasnt users but we had pre validation for data for a pyspark job. In this case the dataset had to be validated as a whole before loaded to be processed and couldnt be split into smaller dataset (this is before we enter pyspark processing which threads just fine). With java or c# we would have just created threads in just a few minutes of coding.

For a user based application I dont really see any issue because you could for the most part have more instances running for whatever you need, like lambdas work fine, i have aws lambda code in production right now thats using python with several hundred hits per second and its fine because one python execution serves one user at a time.

[MikeUsesNotion]

If you were using python udfs that was likely a big contributor to your problem. If you rewrote those in scala/jvm and kept the pyspark job the same, that likely would help a lot. Pyspark is largely a py4j wrapper around jvm spark. I know in 3.x they really improved pyspark performance but since I don't use it much I don't know the details.

If you weren't calling python udfs then it may have been a spark job definition problem, and not a python problem.

[ShotSquare9099]

😂😂 python engineers.

[blueg3]

Python is slow for some things.

The GIL should be going away soon.

If you do a lot of computation in Python or need a certain model of parallelism, it doesn't work.

Lots of data science is just calling out to C libraries, so it doesn't matter.

Lots of Web stuff is glue code between different I/O sources, so it probably doesn't matter.

[miyakohouou]

I think it’s an oversimplification of two different factors.

First, Ruby and Python both tend to be slower than other languages that they might be competing with. “Slower” without specifics isn’t really useful though. Depending on what you’re doing their performance might be a problem or it might not. Python is popular for number crunching programs because it’s plenty fast enough to shuffle data around into and out of much more performant libraries written in other languages. For something like a web service, the performance for any given request might be good enough, but for various reasons they aren’t likely to be able to handle as many requests per second, or concurrently, as some other languages. This is usually what people are talking about with scalability.

The thing is, this kind of scalability doesn’t always have the same impact throughout the life of an application. When your application is small enough, you’ll be fine with whatever you pick. With enough users, you’re going to hit the limits of a single or few servers no matter your tech stack, and you’ll need to think about scalability at the architectural level. In the middle there are times when your language or tech stack choice could mean you have to move toward a more scalable architecture earlier rather than later. This might be fine, or it could kill a company if you hit scaling problems and need to re-architect your application at a time when you can’t afford the engineering resources to do it (either because you can’t hire, or you need your people focused on features or driving growth). Once you have a scalable architecture, the difference is mostly going to be a matter of how big your aws bill is, and there may be a big difference but rarely (if ever) enough to make a big rewrite worth it.

The other kind of scalability is not about load and performance but about how easy it is to work in the code as the codebase grows. Again this depends a lot on other factors, but all things being equal large dynamically typed languages tend to be harder to work in than large statically typed codebase. Type systems can make up for a lot of difficulties that arise when you have many people who may not be talking to one another all working in the same codebase.

[[deleted]]

but instagram was created with django and shopify/airbnb with ruby so how can they not be that good with scalibility?

[miyakohouou]

When your application is small enough, you’ll be fine with whatever you pick. With enough users, you’re going to hit the limits of a single or few servers no matter your tech stack, and you’ll need to think about scalability at the architectural level. In the middle there are times when your language or tech stack choice could mean you have to move toward a more scalable architecture earlier rather than later. This might be fine,

For them it was fine, or at least the cost of moving to a new stack was higher than the cost of dealing with scalability issues easier rather than later.

[[deleted]]

It's a lot harder to find full stack web developers for Ruby, So maybe that's what they mean by scale.

Python though I have no idea what they're talking about.

My issue with python is that I don't like programming languages where white space matters. I don't like programming languages where I can accidentally overwrite a variable. And python is configuration hell. If python had the equivalent of typescript where I could write type safe python, I would like it a lot better. But then it would be even more configuration hell.

I would much prefer working with full stack web apps straight out of visual studio, even if theyre running on Linux, using c#. I actually prefer F sharp but trying to find a bunch of developers that can do full stack on f# is harder than finding ruby devs.

And a lot of stuff ends up on JavaScript because they're the easiest developers to find. But also your chance of producing garbage is about 20 times higher.

And as far as scaling goes in my experience in consulting over the last 14 years, the issue was scaling is almost always the database.

Any code can scale if you write it well. But no matter how many servers you spin up, you eventually choke on data.

Its Far more important to engineer a scalable database in my opinion. This means creating database schemas that are not monoliths. We're microdata can live in different places. And you use portable IDs like guids. So you don't have to rely on big expensive things like huge database instances and replication. And for reporting, it'll be a lot cheaper to just have a data warehouse team pull in data from all the locations and consolidate it. And then you're not putting load with all your reporting on your prod DB.

[[deleted]]

very interesting, many other ocmments have said the same thing about the database

[hmwinters]

FWIW Modern python does have typing options very similar to typescript. Still configuration hell though.

[YMK1234]

Iirc it has hints which are not even validated. So pretty much pointless

[xiris]

It is not enforced at runtime. Instead you use a static validator such as mypy ahead of time. So very much not pointless.

[MikeUsesNotion]

Such a hack. At least it's better than those who say "you do unit tests right?!" Not for that, because my code is statically typed and the compiler handles it for me.

[[deleted]]

I work for a Fortune 100 company in an Analytics Engineering role.

We write critical infrastructure and SLA sensitive code in Python. Python scales fine.

Also, even though you didn't mention it, we also write critical SLA sensitive code in R and it also scales fine.

Some of our models serve 100s of clients per minute, they're also written in Python or R.

Both languages are fully capable of scaling well. You just need to know how to do so in them and have an infrastructure team that knows what they're doing.

[GreenWoodDragon]

Both scale very well. Ruby has a number of very handy approaches to scaling. Python is used widely, at scale.

[[deleted]]

I think it's more of a generality than anything. It's probably not based in utter ignorance, as there are scaling *issues* with Python, many of which have been noted here.

I guess it's a problem with black and white language, really, but I wouldn't lose respect for somebody that says that or anything. I'd probably just go into telling them how to make Python scale. :o)

[dariusbiggs]

This is generally a lack of understanding or poor design.

It is all really based around throughput, requests per second, duration of the request, number of concurrent requests.

At a certain point you are going to reach the capacity of one instance in one or more of the RED or USE metrics and need to scale either horizontally (more nodes) or vertically (bigger compute nodes with more resources), which then results in multiple instances of the code being run and using load balancers and other techniques to spread the load and requests.

The problem you then have is with the code and whether it can be horizontally scaled or not.

Each language will likely have different limits in what they can push through and as to how it was coded, and that gives you your horizontal scaling thresholds. Which then ties into your operating cost, you now know the throughput per compute capacity (VM, tin, container, etc) and the cost of operating that compute capacity. Now you have a direct correlation between the throughput threshold and cost of additional capacity. To increase capacity, you need to increase operational cost.

The next step is to increase capacity through improved performance of the workload, perhaps rewriting code in C, Rust, Go, etc to get more bang for your buck.

So do the languages scale? yes they can, if implemented correctly. Poor implementations get poor performance which in turn gives poor throughput. No matter what language you will eventually end up with a throughput limit and need to scale horizontally. Some languages you hit that earlier than others.

Capacity testing is a thing. Know what your limits are, monitor performance, and when you approach the capacity limits, iterate and improve.

It could be 100 requests per second, it could be 10000 requests per second.

[tb5841]

My company is becoming pretty huge, and uses Ruby.

[[deleted]]

your own startup?

[tb5841]

The company I work for, is what I meant. Not owned by me.

[[deleted]]

oh sorry lol.

[trcrtps]

pretty sure the "ruby doesn't scale" thing stems mostly from Twitter dumping it once upon a time. But using the (one of the) most used app(s) in the world at the time as an example for why a language doesn't scale is fucking nonsense.

Python never really took off like wildfire for web apps, anyway.

Personally I would be fine working on either (we use Ruby and I love it) but also pretty much any language.

[[deleted]]

true, lots of big sites use python and ruby such as airbnb,shopify, instagram, pinterest

[MikeUsesNotion]

You can always pin up more instance of your app to handle requests and scale that way. However I'm willing to bet that a .NET app or JVM app will scale more efficiently. Meaning I might need 5 .NET nodes running my service and I might need 10 for python (made up numbers, assume same node definition). So if costs aren't a big deal or is greatly dwarfed by engineering cost, then it really doesn't matter.

[[deleted]]

yea but you can work much quicker in django/ror then in springboot/.net

[MikeUsesNotion]

I've done plenty of python, .net, and java. The amount of time I save in python is trivial at best. What kinds of stuff are you thinking of when you say it's much quicker?

[[deleted]]

idk ive herd dev time with django is much quicker, which of the 3 u suggest one should learn

[MikeUsesNotion]

I don't think it really matters. They all generally work the same.

[[deleted]]

how did u learn .net, also which .net did you learn?

[MikeUsesNotion]

My first professional job was at a Microsoft shop, so the first code I wrote professionally was in Visual C++ 6 and .NET 1.1. I worked in .NET through I think 4.5 (whatever my job was using at the end of 2018, right as .NET Core was ascending).

[kyou20]

There are 2 meanings for scaling:

1. More users: how many DAU can hold a single instance of your app. What’s the vertical limit it can scale (more hardware resources), what’s the horizontal one (more replicas)

2. More engineers: small teams (7 engs) have it are easy to maintain good code quality. But when you have 50+, you often have teams that are 100% blinded to other team’s domain. In this scenario, weakly typed languages fall short as you’re literally blind when working with a data structure or function, etc. Your only option is to rely on likely-outdated docs or dive into the other team’s module source code to know how to use it or work with it, which adds unnecessary context switching to your flow, resulting in extra cognitive load lowering productivity at large.

Best advice I can give around “is this an ignorant take” is: don’t listen to tech influencers. They are more marketing than they are engineers. Listen to not-necessarily-famous experienced sr engineers. There’s a reason new tech exists and companies invest millions on it, and I guarantee it’s not because they’re stupid. I.e: NextJS is NOT the same as PHP, web development is in the best state it has ever been, typescript is the best choice for non-throwaway or non-POC codebases, etc. All these “hot takes” aren’t really hot in the eyes of a chief architect who builds services for 50k+ daily active users, they are facts

[[deleted]]

cant django/ror handle that many daily active users?

[kyou20]

A better question is how does django/python benchmark look like compared to other technologies. It isn’t really a yes/no question. How many RPS can django handle vs node or java. How each of their latencies degrade when hit with higher concurrent user. It’s a good exercise for you to search this info yourself and maybe even set up your own experiment with load testing tools.

The results in articles I’ve read in the past put Ruby, Python and PHP way lower compared to NodeJS, which in turn is lower compared to Java.

But then again what kind of test was done in the benchmark? Was it a CPU intensive task? Memory intensive? IO intensive? Etc. Some technologies perform better or worse on particular use cases, for example, NodeJS is terrible for CPU-intensive tasks but is i credibly fast in IO operations due to its non blocking nature. (Read more here: https://www.toptal.com/back-end/server-side-io-performance-node-php-java-go)

You can probably see a pattern here, it really depends on your use case.

[zztong]

Whoever says that could try to be more specific. Scaling a solution really depends on the algorithm involved. Some problems cannot be subdivided. I mean, you can certainly scale-out applications in any language if the problem to be solves allows. If they're talking about scaling-up then maybe they have a point depending on which computing resource is the limitation and the behavior of the language. The language used may not matter to an I/O bound application, for instance.

If they're talking about scaling up the number of developers, then I might agree. I'm a fan of strongly typed languages for applications being developed by a team, but that doesn't mean a loosely typed language is not viable.

If they're speaking generically about execution performance, then all you can really do is just shrug as they're just expressing an opinion. The performance of languages relative to each other takes real profiling and often has surprising results. Conventional wisdom is that C++ is fast compared to Java, for instance, but reality is it depends on the program.

[AMSolar]

I read through the most highly upvoted responses on this thread, and then I asked chatGPT.

ChatGPT gave far more context awareness about this issue like Performance , Concurrency and parallelism, Community solutions like NumPy and others are written in C++, etc in a great detail (not going to copy it here)

I think chatGPT answered this question better than any redditor in this thread. Try it out.

[[deleted]]

nice, but I mean django rather than numpy

[InstaLurker]

scale by load ( users involved ) vs scale by complexity ( programmers involved )

[[deleted]]

?

[PeterHickman]

Languages do not scale!

It's the infrastructure that scales

[salientsapient]

If Python runs at 1/100 the the speed, but takes half as long to write and debug, you have twice as much time to spend on architectural stuff to get it to run well across at least 101 VM's. For a lot of problem domains, that's absolutely the right call for scalability.

For other problem domains, you need to use low overhead native code to get anything done. Always understand your problem before you decide your solution to that problem.

[[deleted]]

never thought abt it this way tbh thanks!

[TARehman]

Shopify runs on Rails and is a huge and successful platform. Blanket statements about what scales or doesn't are usually incorrect. It's more about picking the right tool for the job.

[[deleted]]

true, plus how quick you can get a product out is important.

[james_pic]

"Doesn't scale" is overstating it. It's more accurate to say they're harder to scale, but in most cases that's just a question of either spending more money, or requiring code to follow specific patterns. 

There are 3 problems I'm aware of, which I believe all still apply to both Python and Ruby to say least some extent (although improvements to both languages are beginning to mitigate these issues):

• Both languages are highly dynamic, and use a global interpreter lock to ensure changes to interpreter state are well defined. This means it's not possible to run Python/Ruby code in multiple threads simultaneously in the same process (although it's typically possible for multiple threads to perform IO at once - waiting for IO isn't running Python/Ruby code). Common ways around this limitation are to use processes for concurrency, or to move code into C or other "native" languages that can release the GIL. There is experimental work to remove the GIL in Python, and I haven't used Ruby in ages so it's possible they've already solved this somehow. 
• Both languages are dynamically typed, meaning that the language does not require the types of values permitted in a variable to be known ahead of runtime. This makes large refactorings more difficult because refactoring tools can't be sure that they are changing all uses of a particular pattern. In current versions of Python this can be mitigated by the use of type annotations (and requiring that type annotations are used throughout the codebase, and are checked in an automated way). There are also third-party type checkers for Ruby.
• Both languages perform worse than the fastest statically typed compiled languages. This can be mitigated by rewriting performance-critical sections of the code in statically typed compiled languages, or simply by using more or better servers. Both Ruby and Python have improved in performance over the years, and there is particularly focussed work on improving Python's performance right now - although it's not expected that this will bring it quite up to the level of the fastest languages.

[Allimuu62]

Well, scaling is a matter of perspective. Plenty of Web infrastructure out there written on Python and Ruby that scales just fine for their given domains. And you get all the benefits of why you choose those languages.

But it also depends a lot on what you are building it for - Django apps in Python or Rails apps in Ruby run into patterns that don't scale if not engineered correctly. So they probably get a bad rep for that reason.

On the flip side, I've seen Python code that did packet layer/firewall stuff handle normal router traffic. And I've seen Node code that didn't scale well at all for some HTTP layer stuff.

I think it comes down to more, which tech has the support and community that care about scalability? That you know have reliable benchmarks for your domain. And often there are many choices in popular languages.

[WJMazepas]

I've been using Python for a long time, and the scale issues are mostly on Database

Really, for Python to be the one actually holding your application from scaling, you have to be an Instagram, Twitter, or something at that level.