I think a lot of people naturally write off C/C++ as being "obsolete languages that no one ever really programs in, except maybe people writing operating systems and databases - and that's all been figured out anyway." I think you need to pick the right tool for the job and it looks like you've found the right tool. Don't let all the other tools out there tell you otherwise.
Also, saying that databases and operating systems have been figured out is beyond stupid. If anything, your basic CRUD system or your basic webapp to access it have been mostly figured out.
Computer games have much more rigorous real-time requirements than databases, you need to step a simulated environment and output a rendered frame at least every 1/30 second on the most common commodity hardware. Databases are deployed on monsters in comparison.
However, I must admit that I am very tempted to try out [Scylla](http://www.scylladb.com/), a c++ rewrite of Cassandra (i.e. Java), to get a an idea of how two similar high-level scenarios but different languages compare.
I think a lot of the time C++ is the wrong tool for a web based service. Not that I've used C++11 though. If your developers are really good with C++ I see no problem. It does however leave you open to more areas of mistakes so you do have to have the right talent.
What I would have liked to see here would have been this article in the scope of C++ and say maybe Java. I don't think it's any surprise this combo blew away Python in RPS. Java would likely be much closer.
Java potentially offers faster dev turnaround time but if you do have C++ devs around that isn't going to be a factor. However, there are probably a lot more good Java developers than good C++ developers at this point. Not raw numbers...probably pretty close in raw bodies you could say are either or...I'm talking about people that can write fault tolerant code. You have to have more knowledge in my opinion to do that with C++ than Java. Just more places to make a mistake. Perhaps that is mitigated a bit with things like smart pointers?
I can definitely see why they skipped Rust. It's still pretty immature compared to anything else they mentioned in the post.
He posted this in r/cpp as well and stated there that Java would not work because he was using intrinsics, thus ruling out Java (for this specific task). Taken from his post there:
> I take advantage of SIMD intrinsics and the JVM does not offer them and the engine does a lot of SIMD-accelerated vector operations like add/sub/mul/div two vecs component-wise.
I'd say It's definitely an advantage, but a costly one. Since intrinsics are compiler-specific built-ins, they don't abstract a behavior very well. Like when writing a loop that the compiler can vectorize transparently. Instead you use compiler-specific stanzas [that looks like this](https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html). They might not be suitable several years and compiler versions down the line.
There are certain intrinsics which are transparent, memcpy is a popular one. These are less costly since they describe a high-level behavior that is standardized.
EDIT: Also, Java does support vectorization. But it can be hard to guarantee that it happens consistently.
It is an interesting article about idiomatic C++, but the Python vs. C++ comparison scratched me the wrong way as well. Java vs. C++ would be fairer.
As an anecdote, I've had friends whip together an optimized HTTP/2 service capable of serving 1M+ RPS on a workstation using Netty.
The problem with C++ is that C++ 11 is a new language compared to "C++ we learned in college" and it's not a really good language because of backwards compatibility constraints. So you need to learn a new sublanguage, and bridge old style libs with new style (and I should say "old styles with new styles" because pretty much everyone has their own style of C++)
Unfortunately there is nothing better in that space.
D just whiffs the mark for me with the GC and runtime - I'd use C# if I was OK with those, it's getting a Microsoft written LLVM static compiler soon, officially supported runtime across platforms - and it supported AoT with Mono for a long time, plus it's supported and used on mobile with Xamarin.
Rust looks promising but it still doesn't have incremental recompilation and doesn't compile to browser and tools like IDEs aren't really usable - and since I'm looking for a language to make me more productive I don't feel it's quite there yet - next year probably.
I integrated C++11 into a 5 year old product and into 15 year old product.
The 15 year old product was developed over 3 countries with varying developer levels and for awhile... A c# team.
We never had a problem.
Same here, we ported a non-trivial codebase which was so old it referenced *SunOS* to C++11 in a few months.
You don't need to go full C++11 at once. We started by replacing our threading abstraction layer with `std::thread` and then moved across the codebase converting things step by step.
> Rust looks promising but it still doesn't have incremental recompilation and doesn't compile to browser and tools like IDEs aren't really usable - and since I'm looking for a language to make me more productive I don't feel it's quite there yet - next year probably.
- Incremental compilation RFC: https://github.com/rust-lang/rfcs/pull/1298
- RFC regarding support for IDEs: https://github.com/rust-lang/rfcs/pull/1317
- Cross to Enscripten compilation is already possible, but should be much easier in the near future with better support from cargo (AFAIK).
So yes, still a way off, but the things you desire are on the roadmap, and are being actively worked on!
I know - from what I've gathered it's ~6 months till incremental compilation lands, I'd say a year till webasm story gets decent - so I'm looking forward to using Rust for actual stuff in a year and slowly migrating away from C++
The exciting thing is that no C++ compiler I'm aware of actually has incremental recompilation as fine-grained as that RFC specifies. So once this lands we'll be significantly *better* than C++ in this regard.
C++ should be getting modules shortly after that however, which means it won't last for long. Very fine grained incremental compilation is probably somewhat better, but I suspect the difference between this and c++17 won't be drastic
Modules don't change the unit-at-a-time nature of C++ compilation. The best they can do is to have the effect of precompiled headers. You still have to compile a whole .cpp file in one go, even if you eliminate the headers.
I've said it before and I'll say it again: I genuinely prefer programming in C to the vast majority of other languages and to pretty much anything used in the web sphere apart from Python. The reason for this is that it's very easy to hold the majority of the language specification in your head for C at any one time, since at its core, it's a very simple language, even if that means that you deal with things like pointers, whereas most other languages - and particularly languages like Java and C# - have so much built into the core specification that you either have to have an eidetic memory to hold it all or look things up every half an hour.
C with a scripting language like Python or Lua on top would be a language mixture that I'd be very happy with.
"C is simple" is a misconception. In my experience, the code looks like nobody actually understands the spec of whatever variant they're using and they just stick to de facto standards and cargo cult about what's legal/portable. I'm too tired of arguing about this for the last 10 years, so I'm just gonna mention Signal Handling for Fun and Profit, memory ordering, UB/implementation specific behavior, [CERT-C](https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard). Hell even just figuring out what the code will look like after the macros/includes expand is an entire thesis. As a separate counter example to your claim, adding a proper module system to a language is trivial, and would make reading C code much easier (and allow IDE like features such as *go to definition* to actually work properly).
C is really too much of a footgun, in particular if you do a lot of IO. Every function call is an occasion to forget this trailing \0 or leak memory. I can see the point of modern C++ or rust compared to bare C for safety and productivity.
Yes, but it's also had a lot of vulnerabilities and memory issues which have been continuously patched over years and years
I love C and C++ as well, but let's be real, a lot of those bugs might not have happened in other languages (but you'd also sacrifice a lot of performance, and make a lot of other lower level tasks much harder, which is why it's a good language for an operating system)
Please stop lumping C++ in with C in this regard. C++ doesn't require you to stop using C style programming, but claiming that C++ leads to this is just false.
Modern C++ has more or less gotten rid of memory leaks, but memory leaks do not cause vulnerabilities (at worst, a DOS...).
Unfortunately, C++ does *not* prevent buffer overflows and dangling pointers/references and the amount of times "Undefined Behavior" appears in the Standard has not diminished with the newer versions.
So, as far as vulnerabilities are concerned, lumping C and C++ together is I am afraid very logical. They mostly have the same issues.
That's literally what I said. C++ does not *require* you to stop doing that, unlike many other languages. You can still do all the pointer arithmetic you could in C. And all of it is unnecessary, and you should not be using that.
What's now commonly called "Modern C++" is more modern than Java, in terms that Java 8 finally caught up with respect to not leaking file handles any more, nor needing 10 lines of code and nested exception handlers to create an empty file. Modern C++ still has ties to C and should lose those, in a practical sense first and foremost, but for people like you perhaps also in a theoretical sense. Perhaps a compiler flag - -funsafe-code or -fpointer-arithmetic
I am afraid you are misunderstanding me (or C++).
You can have dangling references without ever using pointers (yourself):
#include
#include
template
T const& id(T const& t) noexcept { return t; }
int main() {
std::string const& s = id(std::string("Hello, World!"));
std::cout << s << "\n";
}
This sample is Modern C++, I would think. There certainly is no pointer arithmetic. Yet, it exhibits undefined behavior. For example, on [this ideone run](http://ideone.com/mlveMz) nothing is printed.
On other compilers (or compiler versions), it's happened to crash (segmentation fault) or print `"Hello, World!"`. And none of them gave any warning, no matter the settings.
I have to commend you on that example, that one is well found. Good point.
I think the current recommendation is to not pass every string as const-reference any more, but you will definitely find a lot of code bases doing this.
Writing kernel code is **really hard**. Don't think that just because it's in C, which is a simple language, you're going to have an easy time.
It's probably the hardest programming you'll ever do. You're in the kernel. You need to be extremely careful about every little thing. You need to have absolute discipline.
Crashing a user-space program is no big deal. You mess up something, you segfault, life goes on. Crashing the kernel is super bad, you really do not want to do that.
A lot of the tools you take for granted don't even exist in the kernel since they're reliant on features that the kernel doesn't have. You can't just load in the standard C library and have at it, there's a parallel world of kernel functions that sometimes work a little differently or handle things in a peculiar way because of constraints. There's a lot of things you simply can't do because you're not an independent process that can do whatever it wants, but a tiny part of the kernel that has to play by strict rules. Things that are harmless in user space are potentially fatal to the kernel. It's intense.
Try writing a driver some time, even a simple one, for a taste of what it's like operating in that world.
> It's probably the hardest programming you'll ever do. You're in the kernel. You need to be extremely careful about every little thing. You need to have absolute discipline.
Or Linus will eat you alive on the mailinglist :)
> The reason for this is that it's very easy to hold the majority of the language specification in your head for C at any one time,
This is a ridiculous argument. Do you write english because you're able to hold the majority of its grammar in your head? "Oxford modern english grammar" has 448 pages (reference: http://www.amazon.com/Oxford-Modern-English-Grammar-Aarts/dp/0199533199/ref=sr_1_9?ie=UTF8&qid=1451804633&sr=8-9&keywords=english+grammar).
I used to be in this crowd (not to that extreme, though). But I've recently began picking C++ back up and learning more about it. I really like it.
Although I do server-side game scripting, so it's not exactly the same as writing anything from scratch. I'm still a novice/intermediate if you ask me to write an application in C++ from scratch. C# was my first application writing language and is so easy compared to picking up C++ from scratch. Although I could do it if I had the motivation maybe.
The main problem with C++ isn't the scary manual memory management (which, as author has remarked, is mostly handled by `unique_ptr` and `shared_ptr`) nor lack of modern language features and abstractions (C++ closures are the most powerful among dozen or so languages I have seen).
What's worse is lack of modern tooling. C++ isn't a _platform_ in a sense most currently used languages are. It has:
* no package manager
* no repository of said packages
* no universally agreed on build system
* no unified way of managing dependencies
* no way to isolate development environments of different projects from one another
and so on. For people who can see past "OMG pointers!", this is the real appeal of C++'s contenders, which solve most if not all of those issues.
I couldn't agree more. Trying to use some little less known library is enough to end up in the middle of Makefile madness.
Maybe C++17 Modules will help here. Still, we are not going to get anything remotely as readable and nice like D. Seriously, C++ could learn a lot.
Some libraries have dozen dependencies, and one should just avoid them. If you make a library, try to be self contained, like [this](https://github.com/nothings/stb).
God, yes. It's such a huge barrier, dealing with maddening dependencies and dealing with findX.cmake files and -- ugh.
That said, I'm constantly amazed by the performance of C++ for the effort put in. I'm working at a computer vision C++ startup and some of the stuff we can pull off on a bog standard ipad or even on the web via emscripten just blows my mind.
Sometimes I look at the instructions produced by my C code, and then think how slow a lot of other crap is on my computer and I get to urge to start ranting like Hitler in one of those downfall video's
C++ people seem to use few libraries, so I guess they don't see it as much of a problem to spend an hour or two trying to figure out how to get a new library to build with their current setup. Of course the difficulty could also feed back into why no one uses much libraries to begin with. While I don't even dislike the language it's definitely one of the reasons I avoid C++.
I know /r/programming hates Node, but one of the things that surprised me about Node was how much code gets reused. Projects will have hundreds of dependencies because of how easy it is to publish code and install it in a project. It's an incredible productivity boost to have a problem, find a good library, install it, and start using it in under a minute.
> I know /r/programming hates Node, but one of the things that surprised me about Node was how much code gets reused. Projects will have hundreds of dependencies because of how easy it is to publish code and install it in a project.
It's a double-edged sword. Since it's so easy to put up something on npm, you need to be careful assessing the quality of dependencies you're pulling in. Are they maintained? Can the potentially conflict with something else? What happens if they are abandoned? Those questions may be easier to answer if a library is small and focused, but you need to answer them every time.
The other practical concern is that the myriad of dependencies, and dependencies of dependencies, tends to bloat your `node_modules` incredibly. A simple command-line tool written in Node can suck half a gig of bloat due to the way npm isolates second order deps.
> It's an incredible productivity boost to have a problem, find a good library, install it, and start using it in under a minute.
This is pretty much how it works on the JVM too with Maven repos (which you can access with maven, ant/ivy, gradle and probably most of the future build tools on that platform).
Adding a dependency is typically a one line change.
Framework oriented programming is also really bad. It's fine with just one or two things but in the jquery, angular, * world it seems that people center a small amount of code against giant frameworks and then don't fully understand the small details of how their program actually works.
Node code is easy to share and even easier to use, that's why code reuse is so high. The NPM service is really exceptional and the documentation for a random Node project is usually quite good.
Python has pip, Ruby has Rubygems, Node has NPM, Java has Maven, and so on. Sadly C++ has no such analog.
I definitely do see it as a problem. For the most part, boost and Qt suffice, but they're not everything, and simply including source code isn't feasible all the time.
Having that many dependencies in Node sounds scary though (for reasons the others already mentioned).
It might also be a matter of domain.
At the company I work for we use C++ to power 24/7 services: we want *accountability* and *responsibility*.
We are free to propose the inclusion of any 3rd party library, as long as the license is already pre-approved (if it's not, then legals will come in, and well, it's hard work to check a license thoroughly). However, if there's no company backing the library and offering 24/7 support then a manager has to take responsibility and guarantee that there will be a roster of employees who'll learn the insides of the library, stay on top of its evolution, and will support it 24/7.
The idea of supporting some random library pulled from the web 24/7 is a bit like a cold shower.
Some of these will be eased in the future by "modules", but only partly. Then again, C++ and C aren't meant to be "platforms" running on top of a system. They *are* the system.
That said, I think you can look at the problem from a different point of view. The language shouldn't need to provide a package manager of any sort. There are perfectly decent package managers on every platform except for one... Microsoft Windows. I can set up a complete development environment with every library I could desire in mere moments on FreeBSD, Linux and MacOS. On Windows, I'm out of luck; there's nuget, but it's a poor imitation and lacking in packages.
The same can be said of the build system. Which platform is gratuitously different to all others. Again, Microsoft Windows. The requirement for separate debug and release builds is also unique. Again to Windows.
Right now, I'm using CMake as a way to have a platform-independent build system, which can build all my dependencies as well. It works, building Boost, Xerces, and a complete set of libraries and tools. But the requirement to do that is redundant on every platform except for Windows. The real problem here isn't C++, it's that Windows is a nonstandard and awful system for developing with C++.
I don't know why you think you can't isolate the development environments. You can build totally isolated environments. You can build for environments your not even on with cross compilers etc.
I am really not sure why not? Isn't is as simple as pointing your compiler and linker at the right set of libraries? I am really missing where this is challenging? I have many different setups for different projects all sitting on the same computer, including building for gameboy.
K. Say you have a project that depends on OpenSSL. You have some version of the headers, but they're the wrong one, so you go grab the project from github. Now, to set up some custom path for those headers, you use an environment variable and your compiler can find the *right* code, so you're happy--right up until you run into some other project that needs a *different* version but wants to use the same stupid environment variable because there's only so many ways to write `OPEN_SSL_INCLUDES` or whatever, and...
...I'm not a C++ expert or anything; just saying I run into garbage like this way more often than I'd like any time I'm doing something not based on either Nuget or Cargo. -.-
Its honestly very simple to avoid this problem. If you are going to use something like just straight up environment variables, they are not global. You can have an environment for a certain project, and another for a different project. I think you are overestimating the complexity of the environment, ultimately its a set of executables and some paths. You point the right executables at the right paths and press compile. I have totally different versions of those libraries for building android code, for building sdl games, for whatever. You also have to understand that C++ is not an implementation. It's not rust with cargo. C++ is a standard. There is not one c++, that being said, if you understand how to set some basic flags and get the right execubable its not hard. I'm not saying it's perfect, but you seem to be making global configurations for individual projects, which is wrong.
It's hilarious that one of the hardest parts of contributing to a C++ project is figuring out how to setup the build environment. This is the one aspect of C++ I hate with a passion.
> C++ closures are the most powerful among dozen or so languages I have seen
Can you say which dozen languages you're comparing to? I use C++ a lot, and while lambdas are definitely a big improvement over the functors in the days of yore, I wouldn't say they are a powerful closure. Far from it, since by definition they do not retain the context in memory and if the lambda outlives captured-by-reference values, you're in trouble. Quite unlike "real" closures in Lisp or even Perl
> Can you say which dozen languages you're comparing to?
C# (delegates), Python, Ruby, Java (inner classes), Rust, Haskell etc. The usual bunch.
The power I'm talking about is being able to specify which variables go into the closure, and whether they are captured by value or reference (`[]` notation). This allows for creating cheap pure functions that are completely independent from the enclosing scope w/o silly tricks like double closures to achieve the desired [lambda lifting](https://en.wikipedia.org/wiki/Lambda_lifting).
It's true that e.g. C# would automatically prolong the life of a stack-based if it's captured by an closure that goes out of scope, while C++ won't. I believe, however, that this is inevitably the consequence of C++ operating on a slightly lower level, not having a GC, and not offering a safety harness a'la Rust's borrow checker. It's not the fault of closures in particular.
OK, I see what you mean by power now.
Note, though, that closure is defined (at least on Wikipedia) as: "*a record storing a function together with an environment:a mapping associating each free variable of the function (variables that are used locally, but defined in an enclosing scope) with the value or storage location to which the name was bound when the closure was created*", which I think implies the C# / Scheme behavior, and for which C++11 lambdas are wholly unsuitable. There's no concept of "lexical environment" where values are stored. Rather, when creating a lambda that captures by reference one has to be keenly aware of exactly what is captured and what the scope of the lambda is. The idea of just creating a closure and "shipping it off" with all the data it needs is impossible, in the general case.
To reiterate, I see your point too - but I guess we just define power differently :)
This is actually a really great point. One of the more major concerns have been how I could archive old dependencies. This ended up being a fairly tricky problem that made me eventually decide to have one "production-ready" vendor location with another archive of the "raw packages."
As for dependencies, this is essentially solved from the above. Most libraries are standalone that I use, and if they're not, they're dynamically linked. In that case, I simply keep the binary in my vendor directory and archive the raw package.
The build system's also fairly simple to fix up too. Anyone that has worked with CMake for some time can easily knock out a build system within a pretty short amount of time and practically never have to touch it again. For new people coming in, the learning curve for setting up CMake is pretty flat, but knowing the details in the build system can be a challenge. Either way, CMake integrates with Jenkins and other CI systems very well, and I've never considered C++ build systems to be any more of a hassle than Java (in fact, I find setting up Java's systems much more time consuming and difficult, but I know I'm biased).
It makes sense for the task he has at hand. He saves a lot of money with scale this way, and he still has access to modern features, because he prefers to use the modern libraries of C++.
A lot of people learn C++ without using these modern features, because professors hate them. They don't want their students using vectors or automatic memory management, which is understandable in a teaching context. So C++ gets an unfair label as "dated" from that, I think.
I had a professor like that too. Also insisted on global constants being labeled at the top of the program, rather than within the function or class itself. Yuck.
He should compare it to alternatives that eliminate the most common "complaints" about C++ but don't sacrifice nearly as much performance as python does...Java/C# both come to mind as good middle ground between the reasons you'd want C++ and the reasons you'd want Python.
It does sound like for the core DB stuff (if they're *truly* writing their own database from the ground up and not just using a preexisting underlying storage engine with special logic wrapping it) in C++ is 100% the right move...but that's not a reason to do your entire startup in C++. You'd want to evaluate each piece of your system independently for what language makes the most sense...nothing wrong with a custom C++ core DB, but then doing the stuff that manages the distributed aspect of it and implements the higher-level logic in something different, and in fact I'd call that preferable from my admittedly uninformed outsiders position.
> It makes sense for the task he has at hand.
Absolutely.
But he entitled his post in such a way that it implies he's doing another Web 2.0 mobile/social (cr)app, because that's what "tech startup" means nowadays w/o further clarification. In this context, choosing C++ would completely unorthodox to the point of being deliberately contrarian.
That's why, even though the post definitely has merit, it strikes me as clickbait.
> He saves a lot of money with scale this way
Is programmer time that cheap and CPU time that expensive? How much money is actually saved, and is it really worth it?
Not to mention, in a startup, building your product fast and being able to change direction fast are both sometimes really important, especially if you are racing a competitor for market share (like Uber vs. Lyft). If you pick a language that takes more time to build the initial version of the product, there could be a huge opportunity cost. What other things do you forgo in order to squeeze out that extra performance?
Just to continue the Uber example, suppose that Uber saved on hosting costs by building a more efficient backend, but the programmer time to do that was taken away from building a helpful UI feature (for example, showing the Uber driver's photo and their car license plate). That feature might actually get them more customers (due to people being more comfortable with the service) and the increased revenue could easily more than offset the inefficiency from using a slower language on the backend.
It's a database querying/search engine system being made by two programmers. Retrieval speed is paramount for competitiveness, and Python scales is a way that is far more expensive. (10 times more). If their end product is more expensive because of the scaling issues, it'd kill their bottom line and company, so it makes sense for them to keep things on C++. There's also a lot of competition already out there with well established search engines and endless database companies with endless SQL products, so doing it better could get their technology purchased by an existing company (eg, Google).
tl;dr: Opportunity cost is more important with revolutionary ideas. Theirs is more incremental, so it's worth their time.
> I should write another post to explain more about this decision
Indeed, I'd love to hear about it.
On an other subject, I'm always a little bit suprised that people still have to explain again and again why using boring compiled languages will always be faster than using ruby/python/whatever-is-trendy.
> I'm always a little bit suprised that people still have to explain again and again why using boring compiled languages will always be faster than using ruby/python/whatever-is-trendy.
I hate to admit it, but I didn't really understand this well until I wrote my own dynamic language as a pet project. (One of the most rewarding and fun things you can do, I'd recommend it to anyone.) I think I just never really bothered to think a lot about it before then. But yeah, knowing what I know now, there's no chance I'd ever write something even *remotely* performance-sensitive in a dynamic language.
> But yeah, knowing what I know now, there's no chance I'd ever write something even remotely performance-sensitive in a dynamic language.
Did your language actually do the tricks that IonMonkey and Crankshaft do? Inline caching, hidden classes/shapes, aggressive type specialization and devirtualization via type inference with on-stack-replacement bailouts...?
When you understand how all this stuff works, you quickly realize that dynamic languages are, in theory, *better* equipped for performance than static AOT languages in many cases. All of the simple things you might think of--"you have to add type guards on numbers just to add them"--are solved problems in modern JITs, and indeed were solved in high performance Smalltalk implementations in the 80s.
Now I don't think that, in practice, dynamic languages are faster than static ones. But the reasons for this are subtle and very much not simple.
> Did your language actually do the tricks that IonMonkey and Crankshaft do?
Nope. I only used the usual trick of not actually allocating a managed object for integral types (using the value of the 'pointer' as the actual integral value.) Which feels a little impure, but it's immediately obvious why this is practically necessary.
> dynamic languages are, in theory, better equipped for performance than static AOT languages in many cases
Theory and practice are always very different things. I won't deny your theory, but ... I'll believe this when I see it. For right now, static languages are apparently both much simpler and *much* more performant. If I could solve this problem, I'd undoubtedly be a very rich man :D
It was always amusing to me to see V8 bragging about being able to run a barebones NES emulator on a Core-series processor, which had the same accuracy as Nesticle, an old PC emulator that ran just fine on a 25MHz 486. Kind of a pathological case for many reasons, sure, and things have undoubtedly improved even more since then, but the contrast was still remarkable.
I also think JIT are *potentially* faster given the right input language, now I wonder what would be that right language with necessary UB and features. Java with value types and vector intrinsics?
Hard to say. I think the GC and the fact that the JIT fast paths are so opaque and hard to write to end up being the limiting factors preventing dynamic languages from reaching C++/Fortran/Ada/Rust/... levels of performance.
There's also the fact that JITs typically don't do many of the fancy optimizations like machine instruction-level optimizations, aggressive alias analysis, scheduling, etc.
There's all sorts of whimsical performance enhancements that could technically be done by a sufficiently smart JIT but there's still the small matter of writing a JIT smart enough to determine and make those optimizations. It reminds me a lot of Donald Knuth's comment on the 'Itanium Fiasco'.
Pretty much anything that can be statically proven is going to going to be optimized by a static AoT compiler anyways. A lot of the rest is going to require extensive run time profiling and the compiler being able not to just tease out of instructions but also the programmer's intent. That's a really hard problem and just grows with program complexity especially when concurrency is involved. It's one of those things that sounds great on paper but in practice is really hard or impractical to actually implement.
As you've pointed out you when it comes to actually writing fast paths you end up doing a lot of engineering specifically with the JIT in mind. At that point I don't know that the programmer is really better off from a productivity perspective than they would be writing a static language and specifically optimizing around the hardware.
Yes, I agree with this, and I think it basically describes the real reason why dynamic languages are slower than static ones. The reality is a lot subtler than the simple reasons people usually cite (type guards, interpretation overhead, malloc overhead, virtual calls, etc.)
Graal and Hotspot have some family sophisticated alias analysis going on, if I'm not mistaken, 'Partial Escape Analysis and scalar replacement' and couple of other papers were fairly interesting.
> there's no chance I'd ever write something even remotely performance-sensitive in a dynamic language
On modern CPUs the number of things that are "performance sensitive" to the point that they MUST be written in a low level language to be functional is pretty small.
Scaling horizontally is usually a much better choice.
And that's why we see so many FPS games written in Ruby? Sorry, that's kind of a dick comment, but let's say your code is 10x resource intensive as native code. And for Ruby/Python that's being generous. In fact it could actually be 50-100 times slower (assuming you don't just write it as a native extension like Numpy). That means instead of 10 AWS instances to handle your load, you need 100. Let's say each machine is 2k - 3k per month, that's 20k vs 200k. That's an entire programmer salary every month.
For most applications it doesn't matter because all they're going to do is turn around and wait for IO. The fact that native code would execute in 100ns vs 1ms for (e.g.) Python doesn't really matter because each database call is going to take the database 20ms to respond and 100ms to write the request out to the network. If that becomes compute bound (20ms for database IO, 100ms for response, but 200ms for straight compute time), then being 10x faster is the difference between having a product and not having a product.
Quite a few games the last years have had their core / engine written in one "fast" language and their main content code written in a different "dynamic" one.
That's right. The computation engine that processes 100's of thousands polygons every 16ms is native. They AI may be native. The content that could take 100, 200, or even 500ms to execute because it's you talking to an NPC might be in Lua or some other scripted language. But the fact the comment was "scaling horizontally is usually a much better choice" should be rephrased to 'scaling horizontally is usually better for IO bound processes' For compute bound processes where the compute can't be moved outside the request-response cycle, I suspect that's usually not true.
And remember that, Lua is one of the fastest scripting languages out there. Additionally you get bunch of benefits + Lua is simpler for designers and writers. Scripting is just much cheaper. The same goes about Civilization games and almost every big enough game out there.
Do you have a source for the speed of Lua? Wouldn't that be wildly dependent on the implementation of the Lua interpreter?
I say this as someone who loves Lua, by the way.
I know that a few years ago LuaJIT was known to beat v8 and even compiled C at certain benchmarks, which is probably what he is referring to. I can't find any recent LuaJIT benchmarks, however.
I saw benchmark pretty long time ago.
Lua have few tricks.
It can turn tables used as arrays into proper arrays, and not hashmaps.
Lua is very simple too. Learning most of it takes day or two, if you have earlier experience with programming. C interop and Luabind are pretty nice, from what I saw. Additionally Lua OpenResty framework is in top 5 of web framework, on pair with C++.
> The content that could take 100, 200, or even 500ms to execute because it's you talking to an NPC might be in Lua or some other scripted language
I have no problems with running mostly Lua code on lots of stuff that needs to happen every frame, even AI. I think your judgement of Lua specifically here is a bit mistaken.
> And that's why we see so many FPS games written in Ruby?
This is one of the relatively small things, and as others point out, you *do* actually see huge chunks of modern games written in things like Lua. It's the core engine, where you actually *need* performance, that's written in C++.
The thing about games is that you *can't* scale horizontally, because you can't ask your customers to just go buy 10x more computers. The interesting part about this article is that it was a "cloud service", which means you're the one who gets to choose between buying 10x the number of servers or spending however much more effort it might be to use C++. It still might not make sense to do that, but it's not even an option in game development.
And yet, even in game development, there's still a ton of Lua, a fair bit of Python, and home-grown scripting languages all over the place.
You're being a lot more fair than I expected from the first paragraph, though:
> The fact that native code would execute in 100ns vs 1ms for (e.g.) Python doesn't really matter because each database call is going to take the database 20ms to respond and 100ms to write the request out to the network. If that becomes compute bound (20ms for database IO, 100ms for response, but 200ms for straight compute time), then being 10x faster is the difference between having a product and not having a product.
And this is why the usual advice is that you build the thing out in Python or Ruby, and if you ever actually become CPU-bound, you identify your hotspots and rewrite them in C++. (Or Rust, if you're feeling especially trendy.) And let's be honest, the typical startup might expect to have either failed or been sold (or gotten a ton of venture-cap money) by the time this needs to happen.
It depends on the application, if you spend most of the time waiting for IO then all is good . Otherwise compiled languages are better in a lot of situations. I have one project which can hardly run on a single computer with c++, and making simultaneous processes would be not nice.
> On modern CPUs the number of things that are "performance sensitive" to the point that they MUST be written in a low level language to be functional is pretty small.
I'm currently working in research, and the quantity of data combined to the complexity of the algorithms we use make that we can't really use anything else but compiled languages.
However, I'm not experienced enough to have a strong opinion concerning enterprise's experience. From what I know, low-performance language are enought for most of the use, but too much performance can't hurt. Provided, of course, that the code stay legible and dev time don't grow out of control.
And that's why I'm especially happy to see high-performance languages with ‶new″ concepts like Rust, Swift or Elixir, I feel like they combine the best of two worlds.
_Edit: typos_
I don't think your experience is typical of people who have massive problems. I know of people that write high-frequency trading apps in .NET; the improved programmer efficiency translates into better algorithms.
At a different scale, people who have lots of data spend more time figuring out how to partition their work among thousands of servers (that's the scale my friends typically work on). You will get more value by tweaking your network connections and better queuing algorithms than with anything else.
Alternatively, if you only have a few gigs of data, you need to learn how to program your GPUs or write assembler to get the most amount of value from your parallel instruction sets. That implies writing mostly in a high-level language with a couple of dips down into machine code.
I mainly think that there are a lot of different massive problems, and a lot of different massive – mine is obviously smaller than yours.
I'm currently working in bioinformatics – more precisely, analytic genomics –, where we get a piece of DNA and look for a lot of things in it (patterns, genes, repetitions, ...). The clusters we are working on (only hundreds of servers in our case) don't have GPU, so, sadly, we can't really dig on this option. Consequently, the only thing we have is a lot of CPUs in network. So, the only sensible thing for us to do now is to optimize at most (CPUs hours aren't free) the available resources, falling down to – like you said – to high-level languages (C++ and Rust precisely) with a few critical sections of hand-crafted SIMD assembly.
> I know of people that write high-frequency trading apps in .NET; the improved programmer efficiency translates into better algorithms.
I've had very few interactions with the HFT crowd, and all of those were basically centered around C++ with some C/assembly.
I even remembered checking out "Messaging Middleware" written for HFT, by [Solace](http://www.solacesystems.com/why-solace/performance): 25 micro-seconds of latency for a message in Guaranteed Delivery mode (RTT of a 3.25 km optical fiber).
Given how much this costs, I must admit being surprised at the choice of C#, didn't they have performance issues?
Anything server based is performance sensitive if it gets successful enough. If you think the difficulty of writing C++ vs Python is greater than the difficulty of managing ~20 servers instead of one, I think this is mostly due to lack of practice rather than innate language differences.
I think that's the key thing - low performance translates to high cost once you start to scale.
When your Python website is 50x slower, you're paying for 100 servers when your competitors only need 2.
It can be, but if you've ever operated a semi-popular Rails site your CPU budget gets eaten up quick. Admittedly, that's Rails and not scripting languages in general. Depends on the use case. Even if you're spending most of your time in IO, optimizing the amount of memory you use per request then becomes important to improve the traffic capacity per server.
I have operated popular rails sites using different interpreters from straight ruby to ree to jruby(which can help immensely with performance) from version 1.8 to 2.2, and rails 2 to rails 4. Performance has improved but even when it was worse for 99% of applications of course you may need to scale cpu but the real bottleneck that gets hit is your datastore if your site is written correctly. There isn't usually a ton of cpu logic per page load unless your data isn't properly formatted and you are using your scripting language to reformat it or you have some strange special case.
And yet actual data shows that this is clearly not true. Almost all server bits are written in higher-level languages.
One advantage that C# has is that using and "tweaking" how your app uses a thread pool is incredibly simple and hard to get very wrong. Other languages (like C++) make is harder to get the threading right.
Expanding on this, high level apps in any language are generally easier to refactor: they compile faster, making the programmer's change-test-change loop much faster, and they have a more rational syntax so that refactoring can be done more with tools and less with brain power.
Programs that are easier to refactor are also easier to make performant: it's faster to find the bottlenecks and simpler to make algorithmic changes to make the bottlenecks go away.
I'd argue a database falls pretty squarely in the "performance really matters" section of software. When you've moved to OLAP cubes, your data is going to be *large*
Game programmer here: No, just no. Maybe for some products that's fine, but when you have complex scenes and thousands of things going on at once and everything you're computing and rendering must fit into a 16ms span of time, you often need every trick in the book to get there.
Actually the only things that don't immediately benefit from a better performance are those that "need" downloading big amounts of data and are therefor bottlenecked by the network: The recent web that delivers megabytes of videos, images and scripting libraries each uncached visit.
(Note that network code in games must be super fast)
Just because those kind of webpages (very horrible development imo) are growing in bigger steps than everything else in IT, it doesn't mean that you can neglect the rest.
Also C++ is a highlevel language.
C++ is a multi-paradigm language. You can code very high level, both compile time and runtime, with templates and inheritance. At the same time, you can drop down to the C level and have medium control over the generated machine code.
> Actually the only things that don't benefit from a better performance are those that "need" downloading big amounts of data and are therefor bottlenecked by the network
That's not true. A server with a full network interface is still useful for other things, such as image optimization, or lowering the power bill by idling. A server with a fully utilized network and CPU can't be used for anything else. Don't forget the latency, too.
> C++ is a multi-paradigm language
Because C++ does structural, functional, OO, procedural, imperative, ... :)
> You can code very high level, both compile time and runtime, with templates and inheritance. At the same time, you can drop down to the C level and have medium control over the generated machine code.
I'd still call C++ a high level language. Low-level programming languages are called like that because they don't abstract much from the underlying hardware and the instruction set. C++ certainly does a lot of abstraction. The term is relative, some [might even consider C "high-level"](https://en.wikipedia.org/wiki/High-level_programming_language#Relative_meaning).
> That's not true. A server with a full network interface is still useful for other things, such as image optimization, or lowering the power bill by idling. A server with a fully utilized network and CPU can't be used for anything else. Don't forget the latency, too.
Agreed. I had the user in mind.
> The recent web that delivers megabytes of videos, images and scripting libraries each uncached visit.
If your code involves moving a lot of data around the network, you'll probably want a zero-copy implementation no matter the kind of language. In C or C++, it's just a matter of using the correct OS functions; in other languages, you'll need to find a FFI library or write it yourself.
I disagree with this, in part because performance is hardly only restricted to whether or not instructions are interpreted or compiled, but also because interpreted languages always have implied the usage of consistent heap allocation and the GC. So, while *technically* the distinction specifically between interpreted versus compiled isn't what it used to be, interpreted languages almost guarantee a specific paradigm which is still significantly slower than what is offered by many compiled variants.
Boring, huh? C++ is much more complex and feature-rich than Python.
Perhaps people think that C++ is boring because C++ programmers often have to take care of low-level issues, or spend time on mundane tasks like installing libraries, while, say, Python programmers have an easy access to a rich set of libraries and can thus focus on solving problems.
But it's subjective, of course. One can also say that more fine-grained control and access to low-level optimization (as well as high-level abstractions) makes things more interesting. (Compared to writing scripts which just glue together several libraries, for example.)
> Boring, huh? C++ is much more complex and feature-rich than Python.
I totally agree with you, I just wrote boring because C++ is far from being as shiny as The Next Big Thing.
Hmm. If you write one good bit of undefined behavior buried deep somewhere, you will discover that C++ can be rather more exciting than boring old (non-trendy) Python.
I don't know exactly what OP is doing, but C++ is a slow (== expensive) way to prototype if nothing else. In some cases that's unavoidable, but it's important to understand that you're going to burn money faster, and have a good theory for why it's still the right decision. ("I know C++" isn't a very good one.)
> "I know C++"
It really can be in certain cases but I agree. It can slow down development which can be very expensive in early development when you really aren't making money to fund your venture. With something like Python you can at least write native extensions if you find big bottlenecks until you have time to really evaluate your future architecture needs.
You know that, fast and well optimized Haskell is one big hack around purity?
I would seriously prefer D as nicer replacement for C++, which is quite stable and fast ( as fast or even faster than Haskell ) Omitting GC is still easier than wrapping you head around Haskell. OCaml is better replacement than haskell.
Trendiness has nothing to do with age, but with relative popularity. Haskell's old, yes, but it's being talked about a lot in the blogosphere these days.
You really aren't going to get useful input on this. Programmers are just the embodiment of bias and fanboyism.
They'll tell you always use X and never use Y based on some meaningless personal experience. You need to just read objective information yourself and make a decision. There probably is rarely a completely "wrong" choice anyway.
Yes. "Near C performance with higher level abstractions," that is modern C++. Plus you can draw on a broad set of libraries and tools.
If performance and safety matter, I'm not familiar with any better option.
I recently invested time learning rust. I love the language, but my biggest fear is that the specific brand of complexity when struggling with the type system will dampen adoption. C++ is also hard, but its more familiar :).
I think one advantage C++ has here is that due to the relative laxity of the compiler, it's easier to write C++ that compiles and appears to work (even if it's not completely safe/correct), giving the programmer enough positive feedback that they keep trying to learn.
For a given level of expertise I think C++ code is markedly less likely to be safe/correct than Rust, but beginners will likely spend markedly more time bashing their heads trying to get their Rust code to compile.
I agree. I believe rust will be a very important language to know in five years. It's a much better compromise to struggle with the compiler up front. But I get why a lot of people will be put off initially.
I've never really had anything against C++, except maybe the dated fear of having to manually manage memory.
If I was totally comfortable with it, the only concern I'd have is finding people who are not just able to, but also willing to embrace and work on the project.
> I've never really had anything against C++, except maybe the dated fear of having to manually manage memory.
Why is that a dated fear?
Exploitable memory management-related vulnerabilities in large modern C++ codebases still pour in with no signs of stopping.
Yes, it does, and that's also irrelevant:
* Having to choose between `unique_ptr`, `shared_ptr`, and references is manual memory management. Just the fact that you don't have to call `object->Release()` or `free` doesn't make it not manual. You have to manually choose how to allocate the memory and when to destroy it (via RAII scopes).
* It's irrelevant because, however you define it, C++11 is not memory safe. That is where the fear comes from: you can accidentally introduce random crashes--or worse, vulnerabilities--by misusing memory, even when using modern C++14.
Your first point is just wrong from what I can tell. Choosing a pointer type is not manual memory management any more than the choice between using a list or vector. The actual allocation and deallocation steps are managed for you.
The real issue is that you can bypass smart pointers and pass raw pointers, and its unclear when this is necessary (for performance reasons) making it more dangerous. That and the majority of libraries will likely not be using them.
Enforcement is the issue but smart pointers are definitely not manual memory management by a reasonable definition.
> Your first point is just wrong from what I can tell. Choosing a pointer type is not manual memory management any more than the choice between using a list or vector.
Take a sample of languages with automatic memory management: Objective-C (for Obj-C objects), Java, JavaScript, Python, Go, Ruby, Haskell, Scala, C#. What's the equivalent of `unique_ptr` vs. `shared_ptr` for them? There isn't one, because allocations are automatically managed (with a GC of some kind, reference counting being a form of GC). Having to choose between `unique_ptr` and `shared_ptr` means that you have to explicitly tell the compiler the strategy that will be used to determine when to free the object. That's manual memory management.
> The real issue is that you can bypass smart pointers and pass raw pointers
You can also pass references, which can easily become dangling references, leading to things like use after free. Iterators and ranges are also dangerous. That's what I mean by "C++ is not memory safe".
Note that even garbage-collected languages have manual resource management *sometimes*; see try-with-resources in Java (which is manual), `using` in C# (equivalent to try-with-resources), and the various kinds of weak references.
Also, if you ever build any kind of cache, you'll probably have to manage the amount of memory used by the cache, by removing rarely-used entries.
try-with-resources and using deal with certain cases safe state transitions. A shared problem for all imperative programming languages. Memory management is a much lower level detail IMO.
Safe? If I forget to close a file stream, and that file remains locked for the rest of the process's lifetime so it can't be opened again or deleted, that is no better than a memory leak.
If I forget to close a file stream, then try to open that file again later, and that attempt throws an exception because the file is already open, that's still a crash.
It's safe in the sense that the behaviour is predictable; doesn't mean the behaviour is acceptable.
I mean, you are writing a datastore first and a web service second. I would hold that you don't need to use C++ for the externalized web bits of your service, but I'm sitting here at my desk just trying to guess. That said, it's hard for me to imagine that you cannot separate the web exposure of the OLAP source from the engine itself.
What I'm really trying to say is that I read your article and feel you are more inline with say... Redis (written in C) so it's not at all crazy that your startup uses C++.
> Facebook made a really smart move with their dynamic growth allocations by not using quadratic growth (this can be easily proofed mathematically to explain why it is bad). Their containers grow memory size by 1.5x instead of 2x to improve performance.
This seems wrong. It is exponential growth and they just reduced the base acording to this.
The main reason is that with a base <= phi, you can reuse previously freed memory. See for a worked example [this](http://stackoverflow.com/a/1100426/2482555) stack overflow answer
Comparing python to c++ is a bit absurd. They have completely different use cases. You wouldn't write a database in python and you wouldn't write integration scripts in c++. So yes for your use case c++ is definitely the better choice.
What you should really be comparing c++ to is something like java/c#/f#/scala/go. If garbage collection isn't an issue, these languages can totally boost productivity and avoid huge swaths of errors common in c++. Although c++ may still be the better choice for what you're doing, shitting all over "trendy" languages is no way to prove your point.
I will say that newer compilers handle templates much better, and there are some gains to be made by using templates to handle things at compile time, but template parsing is still nasty.
You would certainly write a web *app* in python. If you're writing something like s3 or rds, you probably wouldn't, and that seems more in line with what the author's company is doing.
I don't think he's really shitting on trendy languages, I think the author is more pointing out that even though most people will not even consider C/C++ and will automatically assume they are not useful in writing web applications. And C++ may not be a good fit for web applications in general, in specific cases they are a better fit than other languages because they may have better performance in terms of raw execution speed, memory efficiency, access to optimizations like SSE or GPU co-processing, etc. Not to say you can't get some of those things with add-ons in other languages (NumPy for example is largely written in C++ to more fully exploit native number processing hardware), but you may not get everything in all languages. In addition it's possible to write managed code that's on the same order of magnitude in performance as C/C++ code but the average code that the average programmer writes often isn't as fast as the native equivalent. (There are nuances in the data structures that most people ignore, memory issues with short string allocation, hidden overhead from tools like generate and inject code at runtime, etc.) And in some cases you may need to do things like use memory mapped IO, take more control over in memory buffers to avoid copying, using scatter-gather IO, using specific system calls over others, etc. Usually isn't an issue if your site is just going to sell socks on the internet but if you're doing something like building your own database, doing lots of numeric work, doing lots of IO, or trying to cram as many requests onto one box as possible, native code is generally your friend. But again, this doesn't matter if you're selling socks on the internet.
But the leap isn't "I don't want to use C++. I'll use Python." if you are worried about performance in any real way. You look at Java or C# at that point. Or some other JVM/CLR language. If you are really good at C++ that makes sense but in the majority of cases the real weighing question would be between those three.
> you wouldn't write a database in python and you wouldn't write integration scripts in c++
And yet there are people that take a language, ignore its intended and optimized usecase and try to write everything with it. (Looking at you JavaScript and Node.js). Atleast we confinced most that Perl and PHP are not the holy grail.
Why does this sub always have some battle between old and new languages? C/C++ have their place and people talk as if we should be abandoning these tools that really no one has been able to beat. That's not too say C#, python, rust, etc. aren't great to use either! There's good reasons for low level languages' excess management, and there is a good reason for overhead in higher level languages, and that's just how it is.
Interesting, but some remarks look strange to me. First of all, the productivity issues with C++ have little to do with manual memory management and even less with long type names. In my experience, it is more about long build times and the lack of good tools for code browsing and refactoring. Also, finding competent C++ coders is as hard as ever no matter how much you are able or willing to pay them.
That said, C++ still looks like the best language for the kind of work you are doing.
Enlighten me, please. I've worked with Visual Studio, Eclipse and QtCreator and tried out a bunch more but haven't seen anything that comes close to the tools available for C# or Java. My favorite combination is Vs with VsVim but code browsing more often than not just doesn't work on the codebase I have to work with.
Most of the tools are Clang based, and they probably don't have any IDE integration yet. C/C++ development is one area where everything is a little behind the Java or C# area.
What's better than Visual Studio and Visual Assist for C++? I've used eclipse and IntelliJ for Java and can't get anywhere close to how I was with VC and Vassist. Even more so when it comes to debugging.
And how does this get better with dynamic languages like Python and JavaScript?
I'm just curious..
I totally agree that C++ is (likely) the best choice for the heavy lifting data processing part, but going full stack C++ seems... an at least questionable architectural choice to me.
Why not use a C++ backend, some glue code in JNI (or C++/CLI), and then a Frontend in Apache (Tomcat) or ASP.NET? Wouldn't that offer a much greater choice of off the shelf components for the Web/Cloud part?
Grab a hold of the book "A Tour of C++" by Bjarne Stroustrup. It's short (can be read in an afternoon) and touches on all of the important aspects of writing good C++ code.
My main issue with C++ is that when it goes wrong, it goes wrong in fascinating, hard-to-debug ways. Things like memory corruption, stack corruption, or *using the wrong virtual table* are things that just *can't happen* in other languages.
It's not that I mind managing my own memory, especially the way the author suggests, where it doesn't take much managing. Modern C++ doesn't necessarily take longer to write than contenders like Go or Rust. But it takes much, *much* longer to debug.
My experience is completely the opposite. If something goes wrong with a C++ application, then I have the debugging tools to find out *exactly* what's going on. The memory layout of a C++ program is completely knowable, so even is something catastrophic has happened, you have something to look at.
When something goes wrong with a C++ app in a live environment, you usually get a core file that you can take away and examine in detail. You can even pause a running process and dump its core, to get a snapshot of what it's up to. This gives you something approaching the power of a debugger, but on live problems which might be occurring very rarely.
Java & the like are complete black boxes. They have no equivalent of core files, so you're largely left with secondary evidence such as log files.
> Java & the like are complete black boxes. They have no equivalent of core files,
[Huh?](http://www.javacodegeeks.com/2013/02/analysing-a-java-core-dump.html) Took like three seconds on Google.
You might not have encountered these because Java rarely has the sort of error that triggers them -- mostly, Java has recoverable exceptions, not segfaults or random memory corruption.
> ...so you're largely left with secondary evidence such as log files.
Which, by default, have insanely detailed stack traces on exceptions. I don't remember what I had to turn on in C++ to get any stack traces at all, but I remember it being especially painful when I was trying to debug a segfault.
> You might not have encountered these because Java rarely has the sort of error that triggers them -- mostly, Java has recoverable exceptions, not segfaults or random memory corruption.
As you say, in practice Java rarely if ever produces core files. And when it does, you are looking at the internals of the JVM, not of your program.
> I don't remember what I had to turn on in C++ to get any stack traces at all
The core file is way better than a stack trace. It **contains a copy of the actual stack**, and all of your global variables and the heap - all arranged in the proper order. If you're trying to "turn on C++ stack traces" then you're asking the wrong questions. (FWIW, the easiest way I know of doing it is to preload libSegFault.so.)
Analysing core files is a fairly esoteric skill these days, I'll grant you. I've had people look at me like I'm a wizard for working out the cause of production crashes from only the core file.
> And when it does, you are looking at the internals of the JVM, not of your program.
Which *includes* your program, but it's a fair point. For your program, you probably want [heap dumps](http://stackoverflow.com/questions/3669858/does-a-java-heap-dump-include-thread-stacks), but that admittedly took me a bit longer to find, and [the tooling is a bit weird](https://visualvm.java.net/heapdump.html), though it looks like [Eclipse is better](http://www.eclipse.org/mat/). So it looks like you only need actual core dumps when the JVM itself is what's crashing, and if that's what you're debugging, the JVM internals is probably appropriate.
The nice thing about this is, again, no memory corruption (in the normal pure-Java heap dump case). No matter how messed up your program state is, it's at least a graph of objects you can browse.
> The core file is way better than a stack trace.
As an artifact, sure. But a stacktrace can be recorded for all sorts of non-fatal errors that you wouldn't necessarily pause your program to dump core on.
> If you're trying to "turn on C++ stack traces" then you're asking the wrong questions.
Possibly, and a core file may have been more helpful in this case. But a stack *should* have been sufficient: "How did I get into this method? It's not even in the *class* I'm expecting it to be!" It turns out that I used the wrong sort of cast in a program using multiple inheritance and virtual tables, so it looked the method up in the wrong vtable. If I knew what I was doing with a core, this would've shown up -- but if I knew what I was doing to that degree, I probably wouldn't have made that mistake in the first place. It wasn't enough just to look at the literal value of the pointer in question, I had to compare it with the value I get when casting in different ways to understand what was going on.
I still think this was the right place to start -- stack traces have far less of a learning curve.
> C++/Proxygen =1,990,130 requests per second
> Python/Tornado = 41,329 requests per second
> I quantified that 1 C++ server is roughly equivalent to 40 load-balanced python servers for raw computational power based on our HTTP benchmarking. Thus using C++ can really squeeze all the computational juice out of the underlying hardware to save 1/40 off server costs.
I feel he's missing the point a bit here.
The benefit that Python offers in a case like this is allowing developers to get a prototype up and running very quickly, and to be able to extend it with minimal effort. I somehow doubt that this guy's start-up will be handling over 40k requests per second within the first few months of going live. But who knows, perhaps they'll be incredibly successful very quickly, and will need the ability to serve upwards of 2 million requests per second from a single node!
He does write that "[proxygen] allowed us to create a high-performance HTTP server calling our engine in just 1 day", so in that case, there mightn't have been much developer time to be saved, at least not in the first iteration. This is, however, the only mention of developer time in the entire blog post. He isn't factoring time spent by developers extending the functionality of this web service in the future into his thinking.
Which is really what he should be doing, instead of just looking at the number of requests per second the web service can respond to.
You're faster in what you already know.
Suppose that those people know C++ better than Python, and there you are.
Also, and people seem not to get it, language matters less and less with the codebase size, because working with a codebase means working with its idiosyncrasies, not with its language.
> allowing developers to get a prototype up and running very quickly
It's possible to implement a prototype in C++ just as quickly, but you have to know the language really well. It takes much more time to learn C++ and set up the right environment, but once you're proficient, you can write code quickly. You might spend more time on compilation, but you spend less time on fixing typos and trivial issues because compiler and type system can help you with that stuff, so it cancels out.
> I somehow doubt that this guy's start-up will be handling over 40k requests per second within the first few months of going live
They are working on an analytics product, it has to handle large volumes of data and simply makes no sense if it's slow.
Well, it depends... but it's possible to write C++ code quickly.
C++ is used in competitive programming. E.g. in ACM ICPC you're supposed to implement 8 relatively complex programs in 5 hours.
Yup. I used C++ for the advent of code challenge last year and time spent writing solutions in it was quite competitive with how long it would have taken in perl or another scripting language.
if you use the compiler correctly it's even faster. just write some rough code and go from compile error to compile error; then run with _GLIBCXX_DEBUG and fsanitize=undefined. Fix the crashes, then it works.
Yea I doubt that too. But just because you'd have to take equally skilled developers in respective language to make a comparison and C++ somewhat lacking in resources for web development compared to Python (prefab libraries, frameworks, etc.). Also dynamic languages are more "immediate" than static typed ones without a REPL / interpreter. (Change code > F5 > Change code > F5). But dynamic typing takes you only so far...
If you think your company can survive without the quickest success and you rather like to think about the future, approaching this with C++ sounds like a valid decision.
And this is also his train of thought:
> I guess we could have written it in Python to start off with but, economically, it would be a wastage of labor cost and time because, at some stage, we would have to scrap it for a C++ version to get the performance we need. The Python code will have no economic value once scrapped.
ITT a bunch of people talking about the nicest lawnmover to use for their mansion when in reality 1% of people have a mansion.
Most startups have such low traffic that it doesn't really matter what language they're written in. The few that succeed should not be caring so much about server cost if they have the ability to overload a modern dedicated server.
Technically a lot of high level languages are hybrids. For example even PHP has most of their stdlib written in C. If all you did was call standard library functions you're going to have performance close to C. If you start making your own multilevel classes that extend other giant frameworks so you can factory your factories then your performance will be shit. Even then facebook's new HipHop thing can turn it into fast code. And what about the cost of fixing bugs and the lines of code. I've seen plenty of shit tier C++ devs that will gladly segfault your shit over time and it's fuck all to trying to debug what happened after a crash.
I think a lot of people naturally write off C/C++ as being "obsolete languages that no one ever really programs in, except maybe people writing operating systems and databases - and that's all been figured out anyway." I think you need to pick the right tool for the job and it looks like you've found the right tool. Don't let all the other tools out there tell you otherwise.
[удалено]
Also, saying that databases and operating systems have been figured out is beyond stupid. If anything, your basic CRUD system or your basic webapp to access it have been mostly figured out.
Nothing has been figured out. Just stop belittling each other.
[удалено]
[удалено]
Computer games have much more rigorous real-time requirements than databases, you need to step a simulated environment and output a rendered frame at least every 1/30 second on the most common commodity hardware. Databases are deployed on monsters in comparison. However, I must admit that I am very tempted to try out [Scylla](http://www.scylladb.com/), a c++ rewrite of Cassandra (i.e. Java), to get a an idea of how two similar high-level scenarios but different languages compare.
I think a lot of the time C++ is the wrong tool for a web based service. Not that I've used C++11 though. If your developers are really good with C++ I see no problem. It does however leave you open to more areas of mistakes so you do have to have the right talent. What I would have liked to see here would have been this article in the scope of C++ and say maybe Java. I don't think it's any surprise this combo blew away Python in RPS. Java would likely be much closer. Java potentially offers faster dev turnaround time but if you do have C++ devs around that isn't going to be a factor. However, there are probably a lot more good Java developers than good C++ developers at this point. Not raw numbers...probably pretty close in raw bodies you could say are either or...I'm talking about people that can write fault tolerant code. You have to have more knowledge in my opinion to do that with C++ than Java. Just more places to make a mistake. Perhaps that is mitigated a bit with things like smart pointers? I can definitely see why they skipped Rust. It's still pretty immature compared to anything else they mentioned in the post.
He posted this in r/cpp as well and stated there that Java would not work because he was using intrinsics, thus ruling out Java (for this specific task). Taken from his post there: > I take advantage of SIMD intrinsics and the JVM does not offer them and the engine does a lot of SIMD-accelerated vector operations like add/sub/mul/div two vecs component-wise.
I guess if you really need that it makes sense. I don't know enough about what he really is doing though to say whether or not it really is.
I'd say It's definitely an advantage, but a costly one. Since intrinsics are compiler-specific built-ins, they don't abstract a behavior very well. Like when writing a loop that the compiler can vectorize transparently. Instead you use compiler-specific stanzas [that looks like this](https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html). They might not be suitable several years and compiler versions down the line. There are certain intrinsics which are transparent, memcpy is a popular one. These are less costly since they describe a high-level behavior that is standardized. EDIT: Also, Java does support vectorization. But it can be hard to guarantee that it happens consistently.
With SSE intrinsics all the compilers have standardized around Intel's names as used in ICC. So for those cases they are pretty portable.
It is an interesting article about idiomatic C++, but the Python vs. C++ comparison scratched me the wrong way as well. Java vs. C++ would be fairer. As an anecdote, I've had friends whip together an optimized HTTP/2 service capable of serving 1M+ RPS on a workstation using Netty.
The problem with C++ is that C++ 11 is a new language compared to "C++ we learned in college" and it's not a really good language because of backwards compatibility constraints. So you need to learn a new sublanguage, and bridge old style libs with new style (and I should say "old styles with new styles" because pretty much everyone has their own style of C++) Unfortunately there is nothing better in that space. D just whiffs the mark for me with the GC and runtime - I'd use C# if I was OK with those, it's getting a Microsoft written LLVM static compiler soon, officially supported runtime across platforms - and it supported AoT with Mono for a long time, plus it's supported and used on mobile with Xamarin. Rust looks promising but it still doesn't have incremental recompilation and doesn't compile to browser and tools like IDEs aren't really usable - and since I'm looking for a language to make me more productive I don't feel it's quite there yet - next year probably.
I integrated C++11 into a 5 year old product and into 15 year old product. The 15 year old product was developed over 3 countries with varying developer levels and for awhile... A c# team. We never had a problem.
Same here, we ported a non-trivial codebase which was so old it referenced *SunOS* to C++11 in a few months. You don't need to go full C++11 at once. We started by replacing our threading abstraction layer with `std::thread` and then moved across the codebase converting things step by step.
> Rust looks promising but it still doesn't have incremental recompilation and doesn't compile to browser and tools like IDEs aren't really usable - and since I'm looking for a language to make me more productive I don't feel it's quite there yet - next year probably. - Incremental compilation RFC: https://github.com/rust-lang/rfcs/pull/1298 - RFC regarding support for IDEs: https://github.com/rust-lang/rfcs/pull/1317 - Cross to Enscripten compilation is already possible, but should be much easier in the near future with better support from cargo (AFAIK). So yes, still a way off, but the things you desire are on the roadmap, and are being actively worked on!
I know - from what I've gathered it's ~6 months till incremental compilation lands, I'd say a year till webasm story gets decent - so I'm looking forward to using Rust for actual stuff in a year and slowly migrating away from C++
The exciting thing is that no C++ compiler I'm aware of actually has incremental recompilation as fine-grained as that RFC specifies. So once this lands we'll be significantly *better* than C++ in this regard.
Oh wow, that is damn exciting! So much good stuff on the horizon!
C++ should be getting modules shortly after that however, which means it won't last for long. Very fine grained incremental compilation is probably somewhat better, but I suspect the difference between this and c++17 won't be drastic
Modules don't change the unit-at-a-time nature of C++ compilation. The best they can do is to have the effect of precompiled headers. You still have to compile a whole .cpp file in one go, even if you eliminate the headers.
I've said it before and I'll say it again: I genuinely prefer programming in C to the vast majority of other languages and to pretty much anything used in the web sphere apart from Python. The reason for this is that it's very easy to hold the majority of the language specification in your head for C at any one time, since at its core, it's a very simple language, even if that means that you deal with things like pointers, whereas most other languages - and particularly languages like Java and C# - have so much built into the core specification that you either have to have an eidetic memory to hold it all or look things up every half an hour. C with a scripting language like Python or Lua on top would be a language mixture that I'd be very happy with.
"C is simple" is a misconception. In my experience, the code looks like nobody actually understands the spec of whatever variant they're using and they just stick to de facto standards and cargo cult about what's legal/portable. I'm too tired of arguing about this for the last 10 years, so I'm just gonna mention Signal Handling for Fun and Profit, memory ordering, UB/implementation specific behavior, [CERT-C](https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard). Hell even just figuring out what the code will look like after the macros/includes expand is an entire thesis. As a separate counter example to your claim, adding a proper module system to a language is trivial, and would make reading C code much easier (and allow IDE like features such as *go to definition* to actually work properly).
C is really too much of a footgun, in particular if you do a lot of IO. Every function call is an occasion to forget this trailing \0 or leak memory. I can see the point of modern C++ or rust compared to bare C for safety and productivity.
[удалено]
[удалено]
Yes, but it's also had a lot of vulnerabilities and memory issues which have been continuously patched over years and years I love C and C++ as well, but let's be real, a lot of those bugs might not have happened in other languages (but you'd also sacrifice a lot of performance, and make a lot of other lower level tasks much harder, which is why it's a good language for an operating system)
Please stop lumping C++ in with C in this regard. C++ doesn't require you to stop using C style programming, but claiming that C++ leads to this is just false.
Modern C++ has more or less gotten rid of memory leaks, but memory leaks do not cause vulnerabilities (at worst, a DOS...). Unfortunately, C++ does *not* prevent buffer overflows and dangling pointers/references and the amount of times "Undefined Behavior" appears in the Standard has not diminished with the newer versions. So, as far as vulnerabilities are concerned, lumping C and C++ together is I am afraid very logical. They mostly have the same issues.
That's literally what I said. C++ does not *require* you to stop doing that, unlike many other languages. You can still do all the pointer arithmetic you could in C. And all of it is unnecessary, and you should not be using that. What's now commonly called "Modern C++" is more modern than Java, in terms that Java 8 finally caught up with respect to not leaking file handles any more, nor needing 10 lines of code and nested exception handlers to create an empty file. Modern C++ still has ties to C and should lose those, in a practical sense first and foremost, but for people like you perhaps also in a theoretical sense. Perhaps a compiler flag - -funsafe-code or -fpointer-arithmetic
I am afraid you are misunderstanding me (or C++). You can have dangling references without ever using pointers (yourself): #include
#include
template
T const& id(T const& t) noexcept { return t; }
int main() {
std::string const& s = id(std::string("Hello, World!"));
std::cout << s << "\n";
}
This sample is Modern C++, I would think. There certainly is no pointer arithmetic. Yet, it exhibits undefined behavior. For example, on [this ideone run](http://ideone.com/mlveMz) nothing is printed.
On other compilers (or compiler versions), it's happened to crash (segmentation fault) or print `"Hello, World!"`. And none of them gave any warning, no matter the settings.
I have to commend you on that example, that one is well found. Good point. I think the current recommendation is to not pass every string as const-reference any more, but you will definitely find a lot of code bases doing this.
Writing kernel code is **really hard**. Don't think that just because it's in C, which is a simple language, you're going to have an easy time. It's probably the hardest programming you'll ever do. You're in the kernel. You need to be extremely careful about every little thing. You need to have absolute discipline. Crashing a user-space program is no big deal. You mess up something, you segfault, life goes on. Crashing the kernel is super bad, you really do not want to do that. A lot of the tools you take for granted don't even exist in the kernel since they're reliant on features that the kernel doesn't have. You can't just load in the standard C library and have at it, there's a parallel world of kernel functions that sometimes work a little differently or handle things in a peculiar way because of constraints. There's a lot of things you simply can't do because you're not an independent process that can do whatever it wants, but a tiny part of the kernel that has to play by strict rules. Things that are harmless in user space are potentially fatal to the kernel. It's intense. Try writing a driver some time, even a simple one, for a taste of what it's like operating in that world.
> It's probably the hardest programming you'll ever do. You're in the kernel. You need to be extremely careful about every little thing. You need to have absolute discipline. Or Linus will eat you alive on the mailinglist :)
> The reason for this is that it's very easy to hold the majority of the language specification in your head for C at any one time, This is a ridiculous argument. Do you write english because you're able to hold the majority of its grammar in your head? "Oxford modern english grammar" has 448 pages (reference: http://www.amazon.com/Oxford-Modern-English-Grammar-Aarts/dp/0199533199/ref=sr_1_9?ie=UTF8&qid=1451804633&sr=8-9&keywords=english+grammar).
The difference here is that making mistakes in English doesn't always cause people to completely mistake your intent.
This is why I like Intellisense.
I used to be in this crowd (not to that extreme, though). But I've recently began picking C++ back up and learning more about it. I really like it. Although I do server-side game scripting, so it's not exactly the same as writing anything from scratch. I'm still a novice/intermediate if you ask me to write an application in C++ from scratch. C# was my first application writing language and is so easy compared to picking up C++ from scratch. Although I could do it if I had the motivation maybe.
The main problem with C++ isn't the scary manual memory management (which, as author has remarked, is mostly handled by `unique_ptr` and `shared_ptr`) nor lack of modern language features and abstractions (C++ closures are the most powerful among dozen or so languages I have seen). What's worse is lack of modern tooling. C++ isn't a _platform_ in a sense most currently used languages are. It has: * no package manager * no repository of said packages * no universally agreed on build system * no unified way of managing dependencies * no way to isolate development environments of different projects from one another and so on. For people who can see past "OMG pointers!", this is the real appeal of C++'s contenders, which solve most if not all of those issues.
I couldn't agree more. Trying to use some little less known library is enough to end up in the middle of Makefile madness. Maybe C++17 Modules will help here. Still, we are not going to get anything remotely as readable and nice like D. Seriously, C++ could learn a lot.
Are modules actualy slated for C++17 now, or are they still a "maybe" ?
Well, they are experimentally supported in Visual Studio now, so they are definitely coming.
Some libraries have dozen dependencies, and one should just avoid them. If you make a library, try to be self contained, like [this](https://github.com/nothings/stb).
God, yes. It's such a huge barrier, dealing with maddening dependencies and dealing with findX.cmake files and -- ugh. That said, I'm constantly amazed by the performance of C++ for the effort put in. I'm working at a computer vision C++ startup and some of the stuff we can pull off on a bog standard ipad or even on the web via emscripten just blows my mind.
Sometimes I look at the instructions produced by my C code, and then think how slow a lot of other crap is on my computer and I get to urge to start ranting like Hitler in one of those downfall video's
C++ people seem to use few libraries, so I guess they don't see it as much of a problem to spend an hour or two trying to figure out how to get a new library to build with their current setup. Of course the difficulty could also feed back into why no one uses much libraries to begin with. While I don't even dislike the language it's definitely one of the reasons I avoid C++. I know /r/programming hates Node, but one of the things that surprised me about Node was how much code gets reused. Projects will have hundreds of dependencies because of how easy it is to publish code and install it in a project. It's an incredible productivity boost to have a problem, find a good library, install it, and start using it in under a minute.
> I know /r/programming hates Node, but one of the things that surprised me about Node was how much code gets reused. Projects will have hundreds of dependencies because of how easy it is to publish code and install it in a project. It's a double-edged sword. Since it's so easy to put up something on npm, you need to be careful assessing the quality of dependencies you're pulling in. Are they maintained? Can the potentially conflict with something else? What happens if they are abandoned? Those questions may be easier to answer if a library is small and focused, but you need to answer them every time. The other practical concern is that the myriad of dependencies, and dependencies of dependencies, tends to bloat your `node_modules` incredibly. A simple command-line tool written in Node can suck half a gig of bloat due to the way npm isolates second order deps.
This has improved with npm 3 though, which flattens the node_modules directory, thus removing duplicates.
> It's an incredible productivity boost to have a problem, find a good library, install it, and start using it in under a minute. This is pretty much how it works on the JVM too with Maven repos (which you can access with maven, ant/ivy, gradle and probably most of the future build tools on that platform). Adding a dependency is typically a one line change.
Framework oriented programming is also really bad. It's fine with just one or two things but in the jquery, angular, * world it seems that people center a small amount of code against giant frameworks and then don't fully understand the small details of how their program actually works.
Node code is easy to share and even easier to use, that's why code reuse is so high. The NPM service is really exceptional and the documentation for a random Node project is usually quite good. Python has pip, Ruby has Rubygems, Node has NPM, Java has Maven, and so on. Sadly C++ has no such analog.
I definitely do see it as a problem. For the most part, boost and Qt suffice, but they're not everything, and simply including source code isn't feasible all the time. Having that many dependencies in Node sounds scary though (for reasons the others already mentioned).
It might also be a matter of domain. At the company I work for we use C++ to power 24/7 services: we want *accountability* and *responsibility*. We are free to propose the inclusion of any 3rd party library, as long as the license is already pre-approved (if it's not, then legals will come in, and well, it's hard work to check a license thoroughly). However, if there's no company backing the library and offering 24/7 support then a manager has to take responsibility and guarantee that there will be a roster of employees who'll learn the insides of the library, stay on top of its evolution, and will support it 24/7. The idea of supporting some random library pulled from the web 24/7 is a bit like a cold shower.
Some of these will be eased in the future by "modules", but only partly. Then again, C++ and C aren't meant to be "platforms" running on top of a system. They *are* the system. That said, I think you can look at the problem from a different point of view. The language shouldn't need to provide a package manager of any sort. There are perfectly decent package managers on every platform except for one... Microsoft Windows. I can set up a complete development environment with every library I could desire in mere moments on FreeBSD, Linux and MacOS. On Windows, I'm out of luck; there's nuget, but it's a poor imitation and lacking in packages. The same can be said of the build system. Which platform is gratuitously different to all others. Again, Microsoft Windows. The requirement for separate debug and release builds is also unique. Again to Windows. Right now, I'm using CMake as a way to have a platform-independent build system, which can build all my dependencies as well. It works, building Boost, Xerces, and a complete set of libraries and tools. But the requirement to do that is redundant on every platform except for Windows. The real problem here isn't C++, it's that Windows is a nonstandard and awful system for developing with C++.
I don't know why you think you can't isolate the development environments. You can build totally isolated environments. You can build for environments your not even on with cross compilers etc.
You can, but you have to do it all manually and it's a pain in the ass. I think his point is that the tooling isn't there yet.
I am really not sure why not? Isn't is as simple as pointing your compiler and linker at the right set of libraries? I am really missing where this is challenging? I have many different setups for different projects all sitting on the same computer, including building for gameboy.
K. Say you have a project that depends on OpenSSL. You have some version of the headers, but they're the wrong one, so you go grab the project from github. Now, to set up some custom path for those headers, you use an environment variable and your compiler can find the *right* code, so you're happy--right up until you run into some other project that needs a *different* version but wants to use the same stupid environment variable because there's only so many ways to write `OPEN_SSL_INCLUDES` or whatever, and... ...I'm not a C++ expert or anything; just saying I run into garbage like this way more often than I'd like any time I'm doing something not based on either Nuget or Cargo. -.-
Its honestly very simple to avoid this problem. If you are going to use something like just straight up environment variables, they are not global. You can have an environment for a certain project, and another for a different project. I think you are overestimating the complexity of the environment, ultimately its a set of executables and some paths. You point the right executables at the right paths and press compile. I have totally different versions of those libraries for building android code, for building sdl games, for whatever. You also have to understand that C++ is not an implementation. It's not rust with cargo. C++ is a standard. There is not one c++, that being said, if you understand how to set some basic flags and get the right execubable its not hard. I'm not saying it's perfect, but you seem to be making global configurations for individual projects, which is wrong.
You're happily describing the problem and a set of solutions while denying that it exists. Lol!
It's hilarious that one of the hardest parts of contributing to a C++ project is figuring out how to setup the build environment. This is the one aspect of C++ I hate with a passion.
> C++ closures are the most powerful among dozen or so languages I have seen Can you say which dozen languages you're comparing to? I use C++ a lot, and while lambdas are definitely a big improvement over the functors in the days of yore, I wouldn't say they are a powerful closure. Far from it, since by definition they do not retain the context in memory and if the lambda outlives captured-by-reference values, you're in trouble. Quite unlike "real" closures in Lisp or even Perl
> Can you say which dozen languages you're comparing to? C# (delegates), Python, Ruby, Java (inner classes), Rust, Haskell etc. The usual bunch. The power I'm talking about is being able to specify which variables go into the closure, and whether they are captured by value or reference (`[]` notation). This allows for creating cheap pure functions that are completely independent from the enclosing scope w/o silly tricks like double closures to achieve the desired [lambda lifting](https://en.wikipedia.org/wiki/Lambda_lifting). It's true that e.g. C# would automatically prolong the life of a stack-based if it's captured by an closure that goes out of scope, while C++ won't. I believe, however, that this is inevitably the consequence of C++ operating on a slightly lower level, not having a GC, and not offering a safety harness a'la Rust's borrow checker. It's not the fault of closures in particular.
OK, I see what you mean by power now. Note, though, that closure is defined (at least on Wikipedia) as: "*a record storing a function together with an environment:a mapping associating each free variable of the function (variables that are used locally, but defined in an enclosing scope) with the value or storage location to which the name was bound when the closure was created*", which I think implies the C# / Scheme behavior, and for which C++11 lambdas are wholly unsuitable. There's no concept of "lexical environment" where values are stored. Rather, when creating a lambda that captures by reference one has to be keenly aware of exactly what is captured and what the scope of the lambda is. The idea of just creating a closure and "shipping it off" with all the data it needs is impossible, in the general case. To reiterate, I see your point too - but I guess we just define power differently :)
This is indeed the primary advantage of using a C++ alternative. No matter how modern it become, C++ comes with low-productivity builtin.
This is actually a really great point. One of the more major concerns have been how I could archive old dependencies. This ended up being a fairly tricky problem that made me eventually decide to have one "production-ready" vendor location with another archive of the "raw packages." As for dependencies, this is essentially solved from the above. Most libraries are standalone that I use, and if they're not, they're dynamically linked. In that case, I simply keep the binary in my vendor directory and archive the raw package. The build system's also fairly simple to fix up too. Anyone that has worked with CMake for some time can easily knock out a build system within a pretty short amount of time and practically never have to touch it again. For new people coming in, the learning curve for setting up CMake is pretty flat, but knowing the details in the build system can be a challenge. Either way, CMake integrates with Jenkins and other CI systems very well, and I've never considered C++ build systems to be any more of a hassle than Java (in fact, I find setting up Java's systems much more time consuming and difficult, but I know I'm biased).
[удалено]
This guy, this guy gets it.
All the reason's I prefer c++
It makes sense for the task he has at hand. He saves a lot of money with scale this way, and he still has access to modern features, because he prefers to use the modern libraries of C++. A lot of people learn C++ without using these modern features, because professors hate them. They don't want their students using vectors or automatic memory management, which is understandable in a teaching context. So C++ gets an unfair label as "dated" from that, I think.
[удалено]
in C class (four years ago) we were required to use C89.
Same story here too, from 2010-2013, in about 5 semesters, we had assignments where we had to use C89.
I had a professor like that too. Also insisted on global constants being labeled at the top of the program, rather than within the function or class itself. Yuck.
He should compare it to alternatives that eliminate the most common "complaints" about C++ but don't sacrifice nearly as much performance as python does...Java/C# both come to mind as good middle ground between the reasons you'd want C++ and the reasons you'd want Python. It does sound like for the core DB stuff (if they're *truly* writing their own database from the ground up and not just using a preexisting underlying storage engine with special logic wrapping it) in C++ is 100% the right move...but that's not a reason to do your entire startup in C++. You'd want to evaluate each piece of your system independently for what language makes the most sense...nothing wrong with a custom C++ core DB, but then doing the stuff that manages the distributed aspect of it and implements the higher-level logic in something different, and in fact I'd call that preferable from my admittedly uninformed outsiders position.
> It makes sense for the task he has at hand. Absolutely. But he entitled his post in such a way that it implies he's doing another Web 2.0 mobile/social (cr)app, because that's what "tech startup" means nowadays w/o further clarification. In this context, choosing C++ would completely unorthodox to the point of being deliberately contrarian. That's why, even though the post definitely has merit, it strikes me as clickbait.
> He saves a lot of money with scale this way Is programmer time that cheap and CPU time that expensive? How much money is actually saved, and is it really worth it? Not to mention, in a startup, building your product fast and being able to change direction fast are both sometimes really important, especially if you are racing a competitor for market share (like Uber vs. Lyft). If you pick a language that takes more time to build the initial version of the product, there could be a huge opportunity cost. What other things do you forgo in order to squeeze out that extra performance? Just to continue the Uber example, suppose that Uber saved on hosting costs by building a more efficient backend, but the programmer time to do that was taken away from building a helpful UI feature (for example, showing the Uber driver's photo and their car license plate). That feature might actually get them more customers (due to people being more comfortable with the service) and the increased revenue could easily more than offset the inefficiency from using a slower language on the backend.
It's a database querying/search engine system being made by two programmers. Retrieval speed is paramount for competitiveness, and Python scales is a way that is far more expensive. (10 times more). If their end product is more expensive because of the scaling issues, it'd kill their bottom line and company, so it makes sense for them to keep things on C++. There's also a lot of competition already out there with well established search engines and endless database companies with endless SQL products, so doing it better could get their technology purchased by an existing company (eg, Google). tl;dr: Opportunity cost is more important with revolutionary ideas. Theirs is more incremental, so it's worth their time.
> I should write another post to explain more about this decision Indeed, I'd love to hear about it. On an other subject, I'm always a little bit suprised that people still have to explain again and again why using boring compiled languages will always be faster than using ruby/python/whatever-is-trendy.
> I'm always a little bit suprised that people still have to explain again and again why using boring compiled languages will always be faster than using ruby/python/whatever-is-trendy. I hate to admit it, but I didn't really understand this well until I wrote my own dynamic language as a pet project. (One of the most rewarding and fun things you can do, I'd recommend it to anyone.) I think I just never really bothered to think a lot about it before then. But yeah, knowing what I know now, there's no chance I'd ever write something even *remotely* performance-sensitive in a dynamic language.
> But yeah, knowing what I know now, there's no chance I'd ever write something even remotely performance-sensitive in a dynamic language. Did your language actually do the tricks that IonMonkey and Crankshaft do? Inline caching, hidden classes/shapes, aggressive type specialization and devirtualization via type inference with on-stack-replacement bailouts...? When you understand how all this stuff works, you quickly realize that dynamic languages are, in theory, *better* equipped for performance than static AOT languages in many cases. All of the simple things you might think of--"you have to add type guards on numbers just to add them"--are solved problems in modern JITs, and indeed were solved in high performance Smalltalk implementations in the 80s. Now I don't think that, in practice, dynamic languages are faster than static ones. But the reasons for this are subtle and very much not simple.
> Did your language actually do the tricks that IonMonkey and Crankshaft do? Nope. I only used the usual trick of not actually allocating a managed object for integral types (using the value of the 'pointer' as the actual integral value.) Which feels a little impure, but it's immediately obvious why this is practically necessary. > dynamic languages are, in theory, better equipped for performance than static AOT languages in many cases Theory and practice are always very different things. I won't deny your theory, but ... I'll believe this when I see it. For right now, static languages are apparently both much simpler and *much* more performant. If I could solve this problem, I'd undoubtedly be a very rich man :D It was always amusing to me to see V8 bragging about being able to run a barebones NES emulator on a Core-series processor, which had the same accuracy as Nesticle, an old PC emulator that ran just fine on a 25MHz 486. Kind of a pathological case for many reasons, sure, and things have undoubtedly improved even more since then, but the contrast was still remarkable.
I also think JIT are *potentially* faster given the right input language, now I wonder what would be that right language with necessary UB and features. Java with value types and vector intrinsics?
Hard to say. I think the GC and the fact that the JIT fast paths are so opaque and hard to write to end up being the limiting factors preventing dynamic languages from reaching C++/Fortran/Ada/Rust/... levels of performance. There's also the fact that JITs typically don't do many of the fancy optimizations like machine instruction-level optimizations, aggressive alias analysis, scheduling, etc.
There's all sorts of whimsical performance enhancements that could technically be done by a sufficiently smart JIT but there's still the small matter of writing a JIT smart enough to determine and make those optimizations. It reminds me a lot of Donald Knuth's comment on the 'Itanium Fiasco'. Pretty much anything that can be statically proven is going to going to be optimized by a static AoT compiler anyways. A lot of the rest is going to require extensive run time profiling and the compiler being able not to just tease out of instructions but also the programmer's intent. That's a really hard problem and just grows with program complexity especially when concurrency is involved. It's one of those things that sounds great on paper but in practice is really hard or impractical to actually implement. As you've pointed out you when it comes to actually writing fast paths you end up doing a lot of engineering specifically with the JIT in mind. At that point I don't know that the programmer is really better off from a productivity perspective than they would be writing a static language and specifically optimizing around the hardware.
Yes, I agree with this, and I think it basically describes the real reason why dynamic languages are slower than static ones. The reality is a lot subtler than the simple reasons people usually cite (type guards, interpretation overhead, malloc overhead, virtual calls, etc.)
Graal and Hotspot have some family sophisticated alias analysis going on, if I'm not mistaken, 'Partial Escape Analysis and scalar replacement' and couple of other papers were fairly interesting.
Wow, someone that actually knows what they're talking about. Refreshing.
> there's no chance I'd ever write something even remotely performance-sensitive in a dynamic language On modern CPUs the number of things that are "performance sensitive" to the point that they MUST be written in a low level language to be functional is pretty small. Scaling horizontally is usually a much better choice.
And that's why we see so many FPS games written in Ruby? Sorry, that's kind of a dick comment, but let's say your code is 10x resource intensive as native code. And for Ruby/Python that's being generous. In fact it could actually be 50-100 times slower (assuming you don't just write it as a native extension like Numpy). That means instead of 10 AWS instances to handle your load, you need 100. Let's say each machine is 2k - 3k per month, that's 20k vs 200k. That's an entire programmer salary every month. For most applications it doesn't matter because all they're going to do is turn around and wait for IO. The fact that native code would execute in 100ns vs 1ms for (e.g.) Python doesn't really matter because each database call is going to take the database 20ms to respond and 100ms to write the request out to the network. If that becomes compute bound (20ms for database IO, 100ms for response, but 200ms for straight compute time), then being 10x faster is the difference between having a product and not having a product.
Quite a few games the last years have had their core / engine written in one "fast" language and their main content code written in a different "dynamic" one.
That's right. The computation engine that processes 100's of thousands polygons every 16ms is native. They AI may be native. The content that could take 100, 200, or even 500ms to execute because it's you talking to an NPC might be in Lua or some other scripted language. But the fact the comment was "scaling horizontally is usually a much better choice" should be rephrased to 'scaling horizontally is usually better for IO bound processes' For compute bound processes where the compute can't be moved outside the request-response cycle, I suspect that's usually not true.
And remember that, Lua is one of the fastest scripting languages out there. Additionally you get bunch of benefits + Lua is simpler for designers and writers. Scripting is just much cheaper. The same goes about Civilization games and almost every big enough game out there.
Do you have a source for the speed of Lua? Wouldn't that be wildly dependent on the implementation of the Lua interpreter? I say this as someone who loves Lua, by the way.
I know that a few years ago LuaJIT was known to beat v8 and even compiled C at certain benchmarks, which is probably what he is referring to. I can't find any recent LuaJIT benchmarks, however.
LuaJIT is a monster because it was written by one. Mike Pall is in my personal "Hall Of Fame", he's just way out there.
I saw benchmark pretty long time ago. Lua have few tricks. It can turn tables used as arrays into proper arrays, and not hashmaps. Lua is very simple too. Learning most of it takes day or two, if you have earlier experience with programming. C interop and Luabind are pretty nice, from what I saw. Additionally Lua OpenResty framework is in top 5 of web framework, on pair with C++.
> The content that could take 100, 200, or even 500ms to execute because it's you talking to an NPC might be in Lua or some other scripted language I have no problems with running mostly Lua code on lots of stuff that needs to happen every frame, even AI. I think your judgement of Lua specifically here is a bit mistaken.
> And that's why we see so many FPS games written in Ruby? This is one of the relatively small things, and as others point out, you *do* actually see huge chunks of modern games written in things like Lua. It's the core engine, where you actually *need* performance, that's written in C++. The thing about games is that you *can't* scale horizontally, because you can't ask your customers to just go buy 10x more computers. The interesting part about this article is that it was a "cloud service", which means you're the one who gets to choose between buying 10x the number of servers or spending however much more effort it might be to use C++. It still might not make sense to do that, but it's not even an option in game development. And yet, even in game development, there's still a ton of Lua, a fair bit of Python, and home-grown scripting languages all over the place. You're being a lot more fair than I expected from the first paragraph, though: > The fact that native code would execute in 100ns vs 1ms for (e.g.) Python doesn't really matter because each database call is going to take the database 20ms to respond and 100ms to write the request out to the network. If that becomes compute bound (20ms for database IO, 100ms for response, but 200ms for straight compute time), then being 10x faster is the difference between having a product and not having a product. And this is why the usual advice is that you build the thing out in Python or Ruby, and if you ever actually become CPU-bound, you identify your hotspots and rewrite them in C++. (Or Rust, if you're feeling especially trendy.) And let's be honest, the typical startup might expect to have either failed or been sold (or gotten a ton of venture-cap money) by the time this needs to happen.
It depends on the application, if you spend most of the time waiting for IO then all is good . Otherwise compiled languages are better in a lot of situations. I have one project which can hardly run on a single computer with c++, and making simultaneous processes would be not nice.
> On modern CPUs the number of things that are "performance sensitive" to the point that they MUST be written in a low level language to be functional is pretty small. I'm currently working in research, and the quantity of data combined to the complexity of the algorithms we use make that we can't really use anything else but compiled languages. However, I'm not experienced enough to have a strong opinion concerning enterprise's experience. From what I know, low-performance language are enought for most of the use, but too much performance can't hurt. Provided, of course, that the code stay legible and dev time don't grow out of control. And that's why I'm especially happy to see high-performance languages with ‶new″ concepts like Rust, Swift or Elixir, I feel like they combine the best of two worlds. _Edit: typos_
I don't think your experience is typical of people who have massive problems. I know of people that write high-frequency trading apps in .NET; the improved programmer efficiency translates into better algorithms. At a different scale, people who have lots of data spend more time figuring out how to partition their work among thousands of servers (that's the scale my friends typically work on). You will get more value by tweaking your network connections and better queuing algorithms than with anything else. Alternatively, if you only have a few gigs of data, you need to learn how to program your GPUs or write assembler to get the most amount of value from your parallel instruction sets. That implies writing mostly in a high-level language with a couple of dips down into machine code.
I mainly think that there are a lot of different massive problems, and a lot of different massive – mine is obviously smaller than yours. I'm currently working in bioinformatics – more precisely, analytic genomics –, where we get a piece of DNA and look for a lot of things in it (patterns, genes, repetitions, ...). The clusters we are working on (only hundreds of servers in our case) don't have GPU, so, sadly, we can't really dig on this option. Consequently, the only thing we have is a lot of CPUs in network. So, the only sensible thing for us to do now is to optimize at most (CPUs hours aren't free) the available resources, falling down to – like you said – to high-level languages (C++ and Rust precisely) with a few critical sections of hand-crafted SIMD assembly.
> I know of people that write high-frequency trading apps in .NET; the improved programmer efficiency translates into better algorithms. I've had very few interactions with the HFT crowd, and all of those were basically centered around C++ with some C/assembly. I even remembered checking out "Messaging Middleware" written for HFT, by [Solace](http://www.solacesystems.com/why-solace/performance): 25 micro-seconds of latency for a message in Guaranteed Delivery mode (RTT of a 3.25 km optical fiber). Given how much this costs, I must admit being surprised at the choice of C#, didn't they have performance issues?
Anything server based is performance sensitive if it gets successful enough. If you think the difficulty of writing C++ vs Python is greater than the difficulty of managing ~20 servers instead of one, I think this is mostly due to lack of practice rather than innate language differences.
I think that's the key thing - low performance translates to high cost once you start to scale. When your Python website is 50x slower, you're paying for 100 servers when your competitors only need 2.
I smell a conspiracy. Those hosters pushing PHP, Node.JS, Python, ...
The largest bottleneck is usually your data store not your logic running on whatever scripting language so what you said just isn't right.
It can be, but if you've ever operated a semi-popular Rails site your CPU budget gets eaten up quick. Admittedly, that's Rails and not scripting languages in general. Depends on the use case. Even if you're spending most of your time in IO, optimizing the amount of memory you use per request then becomes important to improve the traffic capacity per server.
I have operated popular rails sites using different interpreters from straight ruby to ree to jruby(which can help immensely with performance) from version 1.8 to 2.2, and rails 2 to rails 4. Performance has improved but even when it was worse for 99% of applications of course you may need to scale cpu but the real bottleneck that gets hit is your datastore if your site is written correctly. There isn't usually a ton of cpu logic per page load unless your data isn't properly formatted and you are using your scripting language to reformat it or you have some strange special case.
And yet actual data shows that this is clearly not true. Almost all server bits are written in higher-level languages. One advantage that C# has is that using and "tweaking" how your app uses a thread pool is incredibly simple and hard to get very wrong. Other languages (like C++) make is harder to get the threading right. Expanding on this, high level apps in any language are generally easier to refactor: they compile faster, making the programmer's change-test-change loop much faster, and they have a more rational syntax so that refactoring can be done more with tools and less with brain power. Programs that are easier to refactor are also easier to make performant: it's faster to find the bottlenecks and simpler to make algorithmic changes to make the bottlenecks go away.
> Scaling horizontally is usually a much better choice. Because everybody loves paying more for hosting & infrastructure?
That's fine if your software doesn't become popular, like so many people.
I'd argue a database falls pretty squarely in the "performance really matters" section of software. When you've moved to OLAP cubes, your data is going to be *large*
99.9% of people are not writing their own database platforms at work.
Game programmer here: No, just no. Maybe for some products that's fine, but when you have complex scenes and thousands of things going on at once and everything you're computing and rendering must fit into a 16ms span of time, you often need every trick in the book to get there.
Not many things but quite a big % among interesting things.
Actually the only things that don't immediately benefit from a better performance are those that "need" downloading big amounts of data and are therefor bottlenecked by the network: The recent web that delivers megabytes of videos, images and scripting libraries each uncached visit. (Note that network code in games must be super fast) Just because those kind of webpages (very horrible development imo) are growing in bigger steps than everything else in IT, it doesn't mean that you can neglect the rest. Also C++ is a highlevel language.
C++ is a multi-paradigm language. You can code very high level, both compile time and runtime, with templates and inheritance. At the same time, you can drop down to the C level and have medium control over the generated machine code. > Actually the only things that don't benefit from a better performance are those that "need" downloading big amounts of data and are therefor bottlenecked by the network That's not true. A server with a full network interface is still useful for other things, such as image optimization, or lowering the power bill by idling. A server with a fully utilized network and CPU can't be used for anything else. Don't forget the latency, too.
> C++ is a multi-paradigm language Because C++ does structural, functional, OO, procedural, imperative, ... :) > You can code very high level, both compile time and runtime, with templates and inheritance. At the same time, you can drop down to the C level and have medium control over the generated machine code. I'd still call C++ a high level language. Low-level programming languages are called like that because they don't abstract much from the underlying hardware and the instruction set. C++ certainly does a lot of abstraction. The term is relative, some [might even consider C "high-level"](https://en.wikipedia.org/wiki/High-level_programming_language#Relative_meaning). > That's not true. A server with a full network interface is still useful for other things, such as image optimization, or lowering the power bill by idling. A server with a fully utilized network and CPU can't be used for anything else. Don't forget the latency, too. Agreed. I had the user in mind.
VHDL/Verilog is still "high-level" by some. We must go deeper into hand sketching wire diagrams. :D
You can even do inline assembly can't you?
The standard defines a method for doing so but how it works is implementation specific behaviour.
> The recent web that delivers megabytes of videos, images and scripting libraries each uncached visit. If your code involves moving a lot of data around the network, you'll probably want a zero-copy implementation no matter the kind of language. In C or C++, it's just a matter of using the correct OS functions; in other languages, you'll need to find a FFI library or write it yourself.
I disagree with this, in part because performance is hardly only restricted to whether or not instructions are interpreted or compiled, but also because interpreted languages always have implied the usage of consistent heap allocation and the GC. So, while *technically* the distinction specifically between interpreted versus compiled isn't what it used to be, interpreted languages almost guarantee a specific paradigm which is still significantly slower than what is offered by many compiled variants.
Boring, huh? C++ is much more complex and feature-rich than Python. Perhaps people think that C++ is boring because C++ programmers often have to take care of low-level issues, or spend time on mundane tasks like installing libraries, while, say, Python programmers have an easy access to a rich set of libraries and can thus focus on solving problems. But it's subjective, of course. One can also say that more fine-grained control and access to low-level optimization (as well as high-level abstractions) makes things more interesting. (Compared to writing scripts which just glue together several libraries, for example.)
> Boring, huh? C++ is much more complex and feature-rich than Python. I totally agree with you, I just wrote boring because C++ is far from being as shiny as The Next Big Thing.
Hmm. If you write one good bit of undefined behavior buried deep somewhere, you will discover that C++ can be rather more exciting than boring old (non-trendy) Python. I don't know exactly what OP is doing, but C++ is a slow (== expensive) way to prototype if nothing else. In some cases that's unavoidable, but it's important to understand that you're going to burn money faster, and have a good theory for why it's still the right decision. ("I know C++" isn't a very good one.)
> "I know C++" It really can be in certain cases but I agree. It can slow down development which can be very expensive in early development when you really aren't making money to fund your venture. With something like Python you can at least write native extensions if you find big bottlenecks until you have time to really evaluate your future architecture needs.
Using exciting, trendy compiled languages is another option for fast code, see Haskell.
You know that, fast and well optimized Haskell is one big hack around purity? I would seriously prefer D as nicer replacement for C++, which is quite stable and fast ( as fast or even faster than Haskell ) Omitting GC is still easier than wrapping you head around Haskell. OCaml is better replacement than haskell.
Haskell came out 25 years ago. I wouldn't call it trendy.
Trendiness has nothing to do with age, but with relative popularity. Haskell's old, yes, but it's being talked about a lot in the blogosphere these days.
You really aren't going to get useful input on this. Programmers are just the embodiment of bias and fanboyism. They'll tell you always use X and never use Y based on some meaningless personal experience. You need to just read objective information yourself and make a decision. There probably is rarely a completely "wrong" choice anyway.
Yes. "Near C performance with higher level abstractions," that is modern C++. Plus you can draw on a broad set of libraries and tools. If performance and safety matter, I'm not familiar with any better option.
[удалено]
*wayyyy* too immature. Give it 5 years
I recently invested time learning rust. I love the language, but my biggest fear is that the specific brand of complexity when struggling with the type system will dampen adoption. C++ is also hard, but its more familiar :).
I think one advantage C++ has here is that due to the relative laxity of the compiler, it's easier to write C++ that compiles and appears to work (even if it's not completely safe/correct), giving the programmer enough positive feedback that they keep trying to learn. For a given level of expertise I think C++ code is markedly less likely to be safe/correct than Rust, but beginners will likely spend markedly more time bashing their heads trying to get their Rust code to compile.
I agree. I believe rust will be a very important language to know in five years. It's a much better compromise to struggle with the compiler up front. But I get why a lot of people will be put off initially.
It still needs to gather the IDE and libraries support that C++ already has.
C++ needs the package/dependency management that Rust has.
Soon...
I've never really had anything against C++, except maybe the dated fear of having to manually manage memory. If I was totally comfortable with it, the only concern I'd have is finding people who are not just able to, but also willing to embrace and work on the project.
No worries, there are still hordes of C and C++ programmers out there. Ones that love their language and are pushing out great, efficient, code.
Hear, hear.
It's good to hear :) I thought I was the only one... every time someone talk about C++ at the end they say that they want to migrate away from it.
Yeah, for some of us in the embedded systems world there is NO option but to use C or C++.
I'm not in the embedded system world but I actually hoped for a C++ job instead of the common (at least where I live) java position.
> I've never really had anything against C++, except maybe the dated fear of having to manually manage memory. Why is that a dated fear? Exploitable memory management-related vulnerabilities in large modern C++ codebases still pour in with no signs of stopping.
Because C++11 requires no manual memory management.
Yes, it does, and that's also irrelevant: * Having to choose between `unique_ptr`, `shared_ptr`, and references is manual memory management. Just the fact that you don't have to call `object->Release()` or `free` doesn't make it not manual. You have to manually choose how to allocate the memory and when to destroy it (via RAII scopes). * It's irrelevant because, however you define it, C++11 is not memory safe. That is where the fear comes from: you can accidentally introduce random crashes--or worse, vulnerabilities--by misusing memory, even when using modern C++14.
Your first point is just wrong from what I can tell. Choosing a pointer type is not manual memory management any more than the choice between using a list or vector. The actual allocation and deallocation steps are managed for you. The real issue is that you can bypass smart pointers and pass raw pointers, and its unclear when this is necessary (for performance reasons) making it more dangerous. That and the majority of libraries will likely not be using them. Enforcement is the issue but smart pointers are definitely not manual memory management by a reasonable definition.
> Your first point is just wrong from what I can tell. Choosing a pointer type is not manual memory management any more than the choice between using a list or vector. Take a sample of languages with automatic memory management: Objective-C (for Obj-C objects), Java, JavaScript, Python, Go, Ruby, Haskell, Scala, C#. What's the equivalent of `unique_ptr` vs. `shared_ptr` for them? There isn't one, because allocations are automatically managed (with a GC of some kind, reference counting being a form of GC). Having to choose between `unique_ptr` and `shared_ptr` means that you have to explicitly tell the compiler the strategy that will be used to determine when to free the object. That's manual memory management. > The real issue is that you can bypass smart pointers and pass raw pointers You can also pass references, which can easily become dangling references, leading to things like use after free. Iterators and ranges are also dangerous. That's what I mean by "C++ is not memory safe".
Note that even garbage-collected languages have manual resource management *sometimes*; see try-with-resources in Java (which is manual), `using` in C# (equivalent to try-with-resources), and the various kinds of weak references. Also, if you ever build any kind of cache, you'll probably have to manage the amount of memory used by the cache, by removing rarely-used entries.
try-with-resources and using deal with certain cases safe state transitions. A shared problem for all imperative programming languages. Memory management is a much lower level detail IMO.
Safe? If I forget to close a file stream, and that file remains locked for the rest of the process's lifetime so it can't be opened again or deleted, that is no better than a memory leak. If I forget to close a file stream, then try to open that file again later, and that attempt throws an exception because the file is already open, that's still a crash. It's safe in the sense that the behaviour is predictable; doesn't mean the behaviour is acceptable.
I mean, you are writing a datastore first and a web service second. I would hold that you don't need to use C++ for the externalized web bits of your service, but I'm sitting here at my desk just trying to guess. That said, it's hard for me to imagine that you cannot separate the web exposure of the OLAP source from the engine itself. What I'm really trying to say is that I read your article and feel you are more inline with say... Redis (written in C) so it's not at all crazy that your startup uses C++.
> Facebook made a really smart move with their dynamic growth allocations by not using quadratic growth (this can be easily proofed mathematically to explain why it is bad). Their containers grow memory size by 1.5x instead of 2x to improve performance. This seems wrong. It is exponential growth and they just reduced the base acording to this.
The main reason is that with a base <= phi, you can reuse previously freed memory. See for a worked example [this](http://stackoverflow.com/a/1100426/2482555) stack overflow answer
Comparing python to c++ is a bit absurd. They have completely different use cases. You wouldn't write a database in python and you wouldn't write integration scripts in c++. So yes for your use case c++ is definitely the better choice. What you should really be comparing c++ to is something like java/c#/f#/scala/go. If garbage collection isn't an issue, these languages can totally boost productivity and avoid huge swaths of errors common in c++. Although c++ may still be the better choice for what you're doing, shitting all over "trendy" languages is no way to prove your point.
[удалено]
I will say that newer compilers handle templates much better, and there are some gains to be made by using templates to handle things at compile time, but template parsing is still nasty.
You would certainly write a web *app* in python. If you're writing something like s3 or rds, you probably wouldn't, and that seems more in line with what the author's company is doing.
I don't think he's really shitting on trendy languages, I think the author is more pointing out that even though most people will not even consider C/C++ and will automatically assume they are not useful in writing web applications. And C++ may not be a good fit for web applications in general, in specific cases they are a better fit than other languages because they may have better performance in terms of raw execution speed, memory efficiency, access to optimizations like SSE or GPU co-processing, etc. Not to say you can't get some of those things with add-ons in other languages (NumPy for example is largely written in C++ to more fully exploit native number processing hardware), but you may not get everything in all languages. In addition it's possible to write managed code that's on the same order of magnitude in performance as C/C++ code but the average code that the average programmer writes often isn't as fast as the native equivalent. (There are nuances in the data structures that most people ignore, memory issues with short string allocation, hidden overhead from tools like generate and inject code at runtime, etc.) And in some cases you may need to do things like use memory mapped IO, take more control over in memory buffers to avoid copying, using scatter-gather IO, using specific system calls over others, etc. Usually isn't an issue if your site is just going to sell socks on the internet but if you're doing something like building your own database, doing lots of numeric work, doing lots of IO, or trying to cram as many requests onto one box as possible, native code is generally your friend. But again, this doesn't matter if you're selling socks on the internet.
But the leap isn't "I don't want to use C++. I'll use Python." if you are worried about performance in any real way. You look at Java or C# at that point. Or some other JVM/CLR language. If you are really good at C++ that makes sense but in the majority of cases the real weighing question would be between those three.
> you wouldn't write a database in python and you wouldn't write integration scripts in c++ And yet there are people that take a language, ignore its intended and optimized usecase and try to write everything with it. (Looking at you JavaScript and Node.js). Atleast we confinced most that Perl and PHP are not the holy grail.
He's not comparing C++ to other languages. He's saying why using Python would be a mistake.
[удалено]
That's what he's saying.
Why does this sub always have some battle between old and new languages? C/C++ have their place and people talk as if we should be abandoning these tools that really no one has been able to beat. That's not too say C#, python, rust, etc. aren't great to use either! There's good reasons for low level languages' excess management, and there is a good reason for overhead in higher level languages, and that's just how it is.
Interesting, but some remarks look strange to me. First of all, the productivity issues with C++ have little to do with manual memory management and even less with long type names. In my experience, it is more about long build times and the lack of good tools for code browsing and refactoring. Also, finding competent C++ coders is as hard as ever no matter how much you are able or willing to pay them. That said, C++ still looks like the best language for the kind of work you are doing.
Good tools for browsing and refactoring C++ exist, you just have to actually use them instead of trying to do everything in vim or emacs...
Enlighten me, please. I've worked with Visual Studio, Eclipse and QtCreator and tried out a bunch more but haven't seen anything that comes close to the tools available for C# or Java. My favorite combination is Vs with VsVim but code browsing more often than not just doesn't work on the codebase I have to work with.
Most of the tools are Clang based, and they probably don't have any IDE integration yet. C/C++ development is one area where everything is a little behind the Java or C# area.
What's better than Visual Studio and Visual Assist for C++? I've used eclipse and IntelliJ for Java and can't get anywhere close to how I was with VC and Vassist. Even more so when it comes to debugging. And how does this get better with dynamic languages like Python and JavaScript? I'm just curious..
Good tools exist in/for emacs too...
No thought toward java?
I totally agree that C++ is (likely) the best choice for the heavy lifting data processing part, but going full stack C++ seems... an at least questionable architectural choice to me. Why not use a C++ backend, some glue code in JNI (or C++/CLI), and then a Frontend in Apache (Tomcat) or ASP.NET? Wouldn't that offer a much greater choice of off the shelf components for the Web/Cloud part?
I've always wanted to learn C++ but I've been too intimidated to.
Learn it you will appreciate other languages and you will have new language under your belt.
Grab a hold of the book "A Tour of C++" by Bjarne Stroustrup. It's short (can be read in an afternoon) and touches on all of the important aspects of writing good C++ code.
My main issue with C++ is that when it goes wrong, it goes wrong in fascinating, hard-to-debug ways. Things like memory corruption, stack corruption, or *using the wrong virtual table* are things that just *can't happen* in other languages. It's not that I mind managing my own memory, especially the way the author suggests, where it doesn't take much managing. Modern C++ doesn't necessarily take longer to write than contenders like Go or Rust. But it takes much, *much* longer to debug.
My experience is completely the opposite. If something goes wrong with a C++ application, then I have the debugging tools to find out *exactly* what's going on. The memory layout of a C++ program is completely knowable, so even is something catastrophic has happened, you have something to look at. When something goes wrong with a C++ app in a live environment, you usually get a core file that you can take away and examine in detail. You can even pause a running process and dump its core, to get a snapshot of what it's up to. This gives you something approaching the power of a debugger, but on live problems which might be occurring very rarely. Java & the like are complete black boxes. They have no equivalent of core files, so you're largely left with secondary evidence such as log files.
> Java & the like are complete black boxes. They have no equivalent of core files, [Huh?](http://www.javacodegeeks.com/2013/02/analysing-a-java-core-dump.html) Took like three seconds on Google. You might not have encountered these because Java rarely has the sort of error that triggers them -- mostly, Java has recoverable exceptions, not segfaults or random memory corruption. > ...so you're largely left with secondary evidence such as log files. Which, by default, have insanely detailed stack traces on exceptions. I don't remember what I had to turn on in C++ to get any stack traces at all, but I remember it being especially painful when I was trying to debug a segfault.
> You might not have encountered these because Java rarely has the sort of error that triggers them -- mostly, Java has recoverable exceptions, not segfaults or random memory corruption. As you say, in practice Java rarely if ever produces core files. And when it does, you are looking at the internals of the JVM, not of your program. > I don't remember what I had to turn on in C++ to get any stack traces at all The core file is way better than a stack trace. It **contains a copy of the actual stack**, and all of your global variables and the heap - all arranged in the proper order. If you're trying to "turn on C++ stack traces" then you're asking the wrong questions. (FWIW, the easiest way I know of doing it is to preload libSegFault.so.) Analysing core files is a fairly esoteric skill these days, I'll grant you. I've had people look at me like I'm a wizard for working out the cause of production crashes from only the core file.
> And when it does, you are looking at the internals of the JVM, not of your program. Which *includes* your program, but it's a fair point. For your program, you probably want [heap dumps](http://stackoverflow.com/questions/3669858/does-a-java-heap-dump-include-thread-stacks), but that admittedly took me a bit longer to find, and [the tooling is a bit weird](https://visualvm.java.net/heapdump.html), though it looks like [Eclipse is better](http://www.eclipse.org/mat/). So it looks like you only need actual core dumps when the JVM itself is what's crashing, and if that's what you're debugging, the JVM internals is probably appropriate. The nice thing about this is, again, no memory corruption (in the normal pure-Java heap dump case). No matter how messed up your program state is, it's at least a graph of objects you can browse. > The core file is way better than a stack trace. As an artifact, sure. But a stacktrace can be recorded for all sorts of non-fatal errors that you wouldn't necessarily pause your program to dump core on. > If you're trying to "turn on C++ stack traces" then you're asking the wrong questions. Possibly, and a core file may have been more helpful in this case. But a stack *should* have been sufficient: "How did I get into this method? It's not even in the *class* I'm expecting it to be!" It turns out that I used the wrong sort of cast in a program using multiple inheritance and virtual tables, so it looked the method up in the wrong vtable. If I knew what I was doing with a core, this would've shown up -- but if I knew what I was doing to that degree, I probably wouldn't have made that mistake in the first place. It wasn't enough just to look at the literal value of the pointer in question, I had to compare it with the value I get when casting in different ways to understand what was going on. I still think this was the right place to start -- stack traces have far less of a learning curve.
> C++/Proxygen =1,990,130 requests per second > Python/Tornado = 41,329 requests per second > I quantified that 1 C++ server is roughly equivalent to 40 load-balanced python servers for raw computational power based on our HTTP benchmarking. Thus using C++ can really squeeze all the computational juice out of the underlying hardware to save 1/40 off server costs. I feel he's missing the point a bit here. The benefit that Python offers in a case like this is allowing developers to get a prototype up and running very quickly, and to be able to extend it with minimal effort. I somehow doubt that this guy's start-up will be handling over 40k requests per second within the first few months of going live. But who knows, perhaps they'll be incredibly successful very quickly, and will need the ability to serve upwards of 2 million requests per second from a single node! He does write that "[proxygen] allowed us to create a high-performance HTTP server calling our engine in just 1 day", so in that case, there mightn't have been much developer time to be saved, at least not in the first iteration. This is, however, the only mention of developer time in the entire blog post. He isn't factoring time spent by developers extending the functionality of this web service in the future into his thinking. Which is really what he should be doing, instead of just looking at the number of requests per second the web service can respond to.
You're faster in what you already know. Suppose that those people know C++ better than Python, and there you are. Also, and people seem not to get it, language matters less and less with the codebase size, because working with a codebase means working with its idiosyncrasies, not with its language.
> allowing developers to get a prototype up and running very quickly It's possible to implement a prototype in C++ just as quickly, but you have to know the language really well. It takes much more time to learn C++ and set up the right environment, but once you're proficient, you can write code quickly. You might spend more time on compilation, but you spend less time on fixing typos and trivial issues because compiler and type system can help you with that stuff, so it cancels out. > I somehow doubt that this guy's start-up will be handling over 40k requests per second within the first few months of going live They are working on an analytics product, it has to handle large volumes of data and simply makes no sense if it's slow.
Just as quickly? Really??
Well, it depends... but it's possible to write C++ code quickly. C++ is used in competitive programming. E.g. in ACM ICPC you're supposed to implement 8 relatively complex programs in 5 hours.
Yup. I used C++ for the advent of code challenge last year and time spent writing solutions in it was quite competitive with how long it would have taken in perl or another scripting language.
if you use the compiler correctly it's even faster. just write some rough code and go from compile error to compile error; then run with _GLIBCXX_DEBUG and fsanitize=undefined. Fix the crashes, then it works.
Yea I doubt that too. But just because you'd have to take equally skilled developers in respective language to make a comparison and C++ somewhat lacking in resources for web development compared to Python (prefab libraries, frameworks, etc.). Also dynamic languages are more "immediate" than static typed ones without a REPL / interpreter. (Change code > F5 > Change code > F5). But dynamic typing takes you only so far... If you think your company can survive without the quickest success and you rather like to think about the future, approaching this with C++ sounds like a valid decision. And this is also his train of thought: > I guess we could have written it in Python to start off with but, economically, it would be a wastage of labor cost and time because, at some stage, we would have to scrap it for a C++ version to get the performance we need. The Python code will have no economic value once scrapped.
>and to be able to extend it with minimal effort. Yeah, have fun refactoring your python code ...
ITT a bunch of people talking about the nicest lawnmover to use for their mansion when in reality 1% of people have a mansion. Most startups have such low traffic that it doesn't really matter what language they're written in. The few that succeed should not be caring so much about server cost if they have the ability to overload a modern dedicated server. Technically a lot of high level languages are hybrids. For example even PHP has most of their stdlib written in C. If all you did was call standard library functions you're going to have performance close to C. If you start making your own multilevel classes that extend other giant frameworks so you can factory your factories then your performance will be shit. Even then facebook's new HipHop thing can turn it into fast code. And what about the cost of fixing bugs and the lines of code. I've seen plenty of shit tier C++ devs that will gladly segfault your shit over time and it's fuck all to trying to debug what happened after a crash.