Hacker News Reader

Comment by CuriouslyC | Hacker News Reader

I think this your mis-characterizes things a bit. The benefit of frameworks and highly dynamic languages are is that for early stage products, they allow you to rapidly iterate while you're finding a product-market fit. There is absolutely no reason to worry about performance when you are still counting active users in some multiple of thousands, and a large part of the product could potentially be rewritten at any time.

Once you have found a product-market fit and what you're offering has stabilized to a large degree, then it makes total sense to go back and rewrite things to improve performance and eliminate technical debt.

View on HN

The advice above is seductive, but wrong. Obviously one should look at performance requirements when developing the software architecture and check if various stacks fulfill them.

Ignoring performance is a gamble and in the worst case one might find that improving performance means rewriting everything.

The sorts of performance issues that will require a complete application rewrite aren't the result of the software stack used, but algorithms/data structures/etc. If you are working in polynomial or exponential time/space it doesn't matter what language/framework/etc you use, your scaling capability will be limited.

In my experience, if you set things up properly the only part of the server side stack that is unavoidably difficult to transition is the underlying data management layer.

If you have good examples (outside of latency constrained applications like multi-player gaming and finance) where a decoupled micro-service architecture would need to be completely rewritten (rather than just rewriting hot services/aggressively caching), I'd love to hear them.

I don't see how that would work. Picking the wrong algorithm will almost never result in a rewrite of the whole app, unless the entire app consists of just one algorithm or someone has consistently failed to pick efficient algorithms.

What do you do if you wrote your app in Python and you need high-performance multi-threading? What do you do if you chose Java and your heap is way too big? Get ready for a lot of pain, that's what.

Games are an easy example where bad choices can ripple up through the entire application. Specifically, the method you use to store and index geometry impacts the codebase in a lot of places. Likewise, the way you design the main world update loop, or the way you communicate events to clients in multiplayer tend to have a similar effect.

As for the problems you specified, usually only a portion of your application work flow will require multi-threading or big mem support, in most non-latency constrained applications those portions of the work flow can easily be split off into independent services, which can be rewritten to be performant.

Obviously there are client-only applications (for example, a 3D modelling package) where it makes sense to go straight to the high-performance solution, but even in that case there are exceptions (for example, PyMol).

Reply on news.ycombinator.com