5 ms·

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 ful

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 the next step? How do you get there? How much more work would it be? Always be one step ahead with technology, but not two. Most markets are surprisingly small. Most use cases scale surprisingly well. You can probably push your solution by an order of one magnitude if you need it quickly. In order to answer the questions you need people who know the product, the (potential) technologies and the market. When you start you probably won't know any of that. See the first prototype you deploy to the customers as a means of collecting data for the first production version. Your first product is not your first product. Your funding should respect that. Get it done quickly with the aim of answering the critical questions. Then go back and design the next version "good-enough" for the second scaling step with the upgrade path in mind.

user5994461 9y ago
> 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).
- luord 9y ago
  > 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.
  - manquer 9y ago
    Langauge is rarely the first bottle neck . This also doesn't apply in the same away for data stores and when your app is stateful. Scaling rdbms is not the simple. Query fine tunning and performance optimisation for single slow queries cannot be solved by just more resources. Just from a database pov Handling replication , multi master caching , backup and fail over especially can fuck you over . In b2b a single data loss event can kill your business, same with security .
  - user5994461 9y ago
    Java or Go are easily 10 times faster than Python/Rail on the same hardware. (Potentially much more, especially when you have non trivial logic to process in the code). That's a recurrent issue with API code (that usually has to be somewhat fast). Not so much for frontend generation. P.S. Sorry but hundreds of customer is nothing. That's served by a pair of boxes (DB + webserver) irrelevant of the language.
    - luord 9y ago
      > Java or Go are easily 10 times faster than Python/Rail on the same hardware. (Potentially much more, especially when you have non trivial logic to process in the code). ... I know that, everyone here knows that; saying it is little more than stating the obvious. Evidently, you missed my point so I fold; but once more, JIC: if an application is slow, one of the last things one should look into to improve performance is the language; it rarely is the bottleneck. P.S.: I know it's nothing, all anecdotal evidence is nothing. For every anecdote one could give, anyone could give counterexamples. That was another point I tried to make. Cheers.
      - shadowmint 9y ago
        > it rarely is the bottleneck. If you're using python, it can be the bottle neck quite easily. I don't endorse change language as an optimisation; that's just ridiculous. ...but you might look at splitting your application up into parts, and doing some service in a more suitable language; or, up front realizing that you have a heavy data processing workload you need to do in parallel, and python isn't a good choice for it. Maybe you're right; you can look at optimisations that patch over the problem with queries and so forth as a first pass; but in some cases your choice of language (specifically node and python in my experience) are actually fundamentally the performance problem (but to be fair, not always). ...but basically, if you don't address the root cause of your perf issues (whatever they are), you're going to be patching and firefighting forever.

user5994461 9y ago

> 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).

luord 9y ago
> 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.
- manquer 9y ago
  Langauge is rarely the first bottle neck . This also doesn't apply in the same away for data stores and when your app is stateful. Scaling rdbms is not the simple. Query fine tunning and performance optimisation for single slow queries cannot be solved by just more resources. Just from a database pov Handling replication , multi master caching , backup and fail over especially can fuck you over . In b2b a single data loss event can kill your business, same with security .
- user5994461 9y ago
  Java or Go are easily 10 times faster than Python/Rail on the same hardware. (Potentially much more, especially when you have non trivial logic to process in the code). That's a recurrent issue with API code (that usually has to be somewhat fast). Not so much for frontend generation. P.S. Sorry but hundreds of customer is nothing. That's served by a pair of boxes (DB + webserver) irrelevant of the language.
  - luord 9y ago
    > Java or Go are easily 10 times faster than Python/Rail on the same hardware. (Potentially much more, especially when you have non trivial logic to process in the code). ... I know that, everyone here knows that; saying it is little more than stating the obvious. Evidently, you missed my point so I fold; but once more, JIC: if an application is slow, one of the last things one should look into to improve performance is the language; it rarely is the bottleneck. P.S.: I know it's nothing, all anecdotal evidence is nothing. For every anecdote one could give, anyone could give counterexamples. That was another point I tried to make. Cheers.
    - shadowmint 9y ago
      > it rarely is the bottleneck. If you're using python, it can be the bottle neck quite easily. I don't endorse change language as an optimisation; that's just ridiculous. ...but you might look at splitting your application up into parts, and doing some service in a more suitable language; or, up front realizing that you have a heavy data processing workload you need to do in parallel, and python isn't a good choice for it. Maybe you're right; you can look at optimisations that patch over the problem with queries and so forth as a first pass; but in some cases your choice of language (specifically node and python in my experience) are actually fundamentally the performance problem (but to be fair, not always). ...but basically, if you don't address the root cause of your perf issues (whatever they are), you're going to be patching and firefighting forever.