Hacker News Reader

Comment by askyourmother | Hacker News Reader

Two recent startups I worked with in London are using C++14 as a main part of their architecture, in addition to Python, JS and Erlang. Its 2016 and performance is back in vogue.

For years we have been told, Developers are expensive, embrace frameworks, ignore the bloat, just ship quick, even if it needs a billion servers to run.

Both firms are building amazing products on very conservative hardware requirements, so they can scale if required, but they actually know and understand their full stack, and it shows.

One had started with too much Python and Go, before realising the error, the other took a detour into JVM country, before getting back onto the main roads with C++.

View on HN

I'm not so sure, that sounds like blaming outside flaws on a programming language. What would anyone be doing that Go, written properly, wouldn't be fast? As another poster has said, the JVM is also plenty fast when used properly.

Sounds like they went from Java with heavy frameworks to C++ with no frameworks.

C++ used properly will be always faster than Go or Java used properly.

In many applications the point is not to be "fast" but "as fast as possible".

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.

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

Go and Java aren't slow. The JVM is highly optimized and is competitive with C++ . I thought that was settled a decade ago.

With regard to speed and pure portability, neither are comparable to C++. Also, C++ is not a corporate controlled language like the others. It's an ISO standard. So there's no comparison to be made there either.

Corporate controlled languages do not allow developers to fully control the software that they produce. C++ allows this and it's very fast and safe (even safer since C++11).

Microsoft has C#. Google has Go. Apple has Swift. Oracle has Java. Which would you want to lock your software into? Also, most all of those languages (or at least the critical parts) are implemented in C++ (hotspot).

> C++ allows this and it's very fast and safe (even safer since C++11).

The security track records of large-scale security-sensitive software written in C++ support the opposite conclusion.

> Also, most all of those languages (or at least the critical parts) are implemented in C++ (hotspot).

Go is not, and never was, implemented in C++.

So does the security track record of large-scale java software ...

The only conclusion I've ever really drawn from software analysis is that large scale software written by armies of programmers is full of security problems. As soon as the organisation stops investing in being the one that knows the most about the security problems of their own software ... shit hits the fan. Since security tends to be one of the first things to get "financially optimized" ...

Go is (less and less over time but still not 0%) implemented in C, with macros. Let's not pretend this is an improvement over C++, because it isn't. The only advantage C has over C++ is that most C programs are far smaller than most C++ programs (on average, of course, there are exceptions). Oh, and if you think C++'s security track record is bad, you will find C's track record horrendous.

Are you sure you're not thinking of C?

At any rate I'm not sure that you can say much more than C is a popular language, and thus has a larger share of poorly written code. It _would_ be nice to see the number of security flaws in a given language graphed against language popularity, but I don't buy that code written in one language or another is necessarily more or less secure.

> Are you sure you're not thinking of C?

Yes. Modern C++ is neither memory safe in theory nor memory safe in practice.

> I don't buy that code written in one language or another is necessarily more or less secure.

The entire security industry, more or less, disagrees with you.

Though I should qualify this with the obvious statements that (a) dynamic languages admit classes of security bugs that static ones don't; (b) no language will magically eliminate all security bugs. But it's just an empirical fact that C and C++ admit lots of memory safety bugs that result in security problems way, way more often than memory-safe languages do.

That's a red herring. Java only appears as fast as C++ for workloads that don't require speed, e.g. human time vs. computer time.

Depending on the performance requirements of the problem domain and the definition of "slow" and "competitive" your comment could either be true or false, which makes it rather meaningless.

The matter has not been settled and will become more important if the industry decides that gaining developer productivity at the cost of software inefficiency is no longer worth it.

For regular business problems JVM is good enough. If you want compute or memory efficiency applications you can't beat low level, which is why OSs, databases, and big widely used user applications like Chrome/Excel/Photoshop are written in C/C++.

What field of business - finance?

Reply on news.ycombinator.com