Live data from Hacker News

Does it scale? Who cares (2011)

jacquesmattheij.com

211–220 of 285 posts

Re: Does it scale? Who cares (2011)

#211

Earlier quoted context omitted.

Probably more like 99/100 or 999/1000 but yeah. Also, you can get pretty damn far with PHP and MySQL. Just look at Facebook. Just don't rely on Drupal or Wordpress to get you there and it'll be fine. KISS and solve the scaling issues as they come up. Far too many projects focus way too much on infrastructure and architecture and micro services instead of building something that solves a real problem for users. Focus…

An alternative view on history: Facebook succeeded because the competitors failed to scale. Do you remember MySpace? The big social network with hundreds of million of users that came before facebook. They had massive scaling and performance issues. At the peak when everyone was moving to social media (almost a decade ago) the site could take an entire minute to load (if loading at all). They lost a lot of users, who…

I was a big MySpace user and late FB user, and I can tell you that it had nothing to do with [tech] scale. Back then I didn't know about programming (my first lines of code were some CSS in MySpace!) and the real reason is that users were becoming more hostile in a site that was a niche on its own. You had to start filtering out and removing SPAM all the time from your public wall. The fact that people could personalize their site and the community (heavy on music and alternative people) put most of the people away.

You can say that it failed to scale, but I wouldn't say that it failed to scale technically; it failed to scale the community. Then at some point when it was already dying they started to change the layout big time I guess to attract more people, alienating the initial community.

Re: Does it scale? Who cares (2011)

#212

Earlier quoted context omitted.

Having worked on corporate Python platform with tens of thousands of developers and thousands of applications running on thousands of instances on millions of lines common core code base, I beg to differ. It is easy to ship any proof of concept. Is it hard to maintain, it is rigged with performance issues and it is almost impossible to refactor because python has zero refactoring support and no compiler to help you c…

But that is basically the point of the whole article and this thread, that it's great for proof of concept that morphs into production when needed. If you can deploy in one day that means you can test 5 ideas/week until one catches on (hopefully not that long). Once one catches on, you can actually put more effort into it and optimize it as needed and not the other way around.

You can't try 5 products or features a week on real users. They don't keep up.

Re: Does it scale? Who cares (2011)

#213
post #65

Earlier quoted context omitted.

> I know of absolutely no service which failed because it couldn't scale. First focus on building what people love. If people love your product, they will put up with the growing pains (e.g. Twitter used to be down a lot!). They haven't failed (yet), but I think gitlab.com would be a lot bigger if they scaled faster. Lots of people have been rejected using it because it was too slow.

gitlab.com is not their core business. It's mostly a demo.

In 2015 we saw it as our demo. In 2017 we see it as one of our two main products and are improving performance accordingly. 95%+ of our revenue is still coming from licenses instead of GitLab.com. But over time this week change.

Re: Does it scale? Who cares (2011)

#214
post #72
post #65

Earlier quoted context omitted.

> I know of absolutely no service which failed because it couldn't scale. First focus on building what people love. If people love your product, they will put up with the growing pains (e.g. Twitter used to be down a lot!). They haven't failed (yet), but I think gitlab.com would be a lot bigger if they scaled faster. Lots of people have been rejected using it because it was too slow.

Would it be as big if they had stopped to consider all scaling issues at the beginning?

In 2015 we only had the people to focus on one thing. We opted to focus on the downloadable product. This grew our revenue much faster than GitLab.com. We started to focus on .Com in 2016 but in hindsight not aggressive enough. Now it is one of our top three priorities.

Re: Does it scale? Who cares (2011)

#215
post #180

Earlier quoted context omitted.

> That's why I now develop in ruby. I'll take developer productivity over performance any day. In my experience, dynamically typed languages don't do well for developer productivity.

And in my experience the exact opposite is true. That's why it's called an anecdote; not data.

Exactly, I never understand the static vs dynamic flamewars. Most of the issues usually presented stem from poor developers or poor development processes/environments/tools.

Poor code written in JavaScript won't become pretty just by translating to Java, and vice versa. That I've seen anyway.

Re: Does it scale? Who cares (2011)

#216
post #180
post #154

Earlier quoted context omitted.

I built a service (~10mm users at peak) which was designed from the ground up to scale, around 2002. When the numbers did grow we just sat back and watched it pretty much. Even given this, I completely agree with you. That's why I now develop in ruby. I'll take developer productivity over performance any day. It's the old saying - 'nice problem to have'.

> That's why I now develop in ruby. I'll take developer productivity over performance any day. In my experience, dynamically typed languages don't do well for developer productivity.

> In my experience, dynamically typed languages don't do well for developer productivity.

At least one empirical study suggests static typing does not improve programmer productivity. Source: http://courses.cs.washington.edu/courses/cse590n/10au/hanenb...

This is just one of the many common industry "wisdoms" that collapse under scientific scrutiny.

Re: Does it scale? Who cares (2011)

#217
post #180
post #154

Earlier quoted context omitted.

I built a service (~10mm users at peak) which was designed from the ground up to scale, around 2002. When the numbers did grow we just sat back and watched it pretty much. Even given this, I completely agree with you. That's why I now develop in ruby. I'll take developer productivity over performance any day. It's the old saying - 'nice problem to have'.

> That's why I now develop in ruby. I'll take developer productivity over performance any day. In my experience, dynamically typed languages don't do well for developer productivity.

I have the opposite experience and I did a lot of back and forth between statically typed and dynamically typed languages over the past decade so I'm not biased in either direction.

Re: Does it scale? Who cares (2011)

#218

Earlier quoted context omitted.

I don't like opinionated pieces like the one presented here because while they are right about some things they miss other things and present half-truths as full-truths. In my experience (and I have little of that) it's important to know the upgrade path and adjust your planning accordingly. How many users can you serve with your solution? How big do you expect the market to be in that stage? What technology would be…

> You can probably push your solution by an order of one magnitude if you need it quickly. You can always push a python/ruby app an order of magnitude by putting an order of magnitude more AWS instances. It will almost always bankrupt you in the medium term. The only place I've seen it sustainable is a place that was generating a $100 per user, and there weren't many active users either (thousands, not millions).

> You can always push a python/ruby app an order of magnitude by putting an order of magnitude more AWS instances.

Or a Java app or a Go app. Really, if one's working in a domain where the language would become the bottleneck, one deliberately screwed up by going against the grain because that language is little used in that domain.

For almost everything else or with very specific exceptions, something else is the bottleneck.

Everyone here is giving anecdotal "evidence" of their claims so I'll follow suit:

In the first company I worked in, the backend was entirely in Java and the application was internal (in-house CMS), meaning only ten users tops; everything about it was horribly slow. It was a sea of poor code, there was no such thing as a deployment pipeline and the servers it was hosted in were inadequate. There was also no relational schema to speak of in the database (basically MySQL used as a dumb document store).

The next place I worked at, my team's job was to build an actual customer-facing application. We did it in python and, while it only has a few hundred users so far, there haven't been complaints about poor performance that I know of.

Really, for every Twitter replacing Ruby, there's a Facebook written in PHP. Don't understand why so many people use one side to support their claim but forget the other.

Re: Does it scale? Who cares (2011)

#219
post #154

Couldn't agree with this article more. I built the biggest social network to come out of India from 2006-2009. It was like Twitter but over text messaging. At it's peak it had 50M+ users and sent 1B+ text messages in a day. When I started, the app was on a single machine. I didn't know a lot about databases and scaling. Didn't even know what database indexes are and what are their benefits. Just built the basic produ…

I built a service (~10mm users at peak) which was designed from the ground up to scale, around 2002. When the numbers did grow we just sat back and watched it pretty much. Even given this, I completely agree with you. That's why I now develop in ruby. I'll take developer productivity over performance any day. It's the old saying - 'nice problem to have'.

In many situations these days, I'd argue you don't have to trade one for the other.

Re: Does it scale? Who cares (2011)

#220

Earlier quoted context omitted.

Microsoft Access. Works fine for something one team uses, works... not fine for something the entire corporation uses.

Does Access actually work well for 20 users?

Last time I built something in Access was on Access 1997. I believe it had about 100 concurrent users and over a gig of data. Those both exceed the hard limits of access at the time so I had a single read/write database on a share and multiple read only databases on shares. I had to split tables among multiple database files as well.

My direct boss was the CFO and he was cheap as hell. It's amazing the things we can come up with when we have to.

Post reply on HN