It seems that threading isn't nearly so simple in C++ either; at least, not if you want to get it right. From
https://akrzemi1.wordpress.com... and
http://www.open-std.org/jtc1/s... it would seem that while initiating a thread as you've discussed within a C++ program is easy, the nuances of C++ threading are uglier than C pthreads threading. Quotes like these make C++11 threading seem a lot less trivial than your initially impressive example suggests:
"If a thread is cancelled no destructors of automatic objects are called; or at least, it is up to the implementation if they are called or not. This would cause too much resource leaks. Therefore, it is not possible to cancel a thread in C++. There is a similar mechanism though: thread interruption. Interruption is coöperative: to-be-cancelled thread must acknowledge the interruption. If interrupted, a special exception is thrown that unwinds child thread’s stack until it reaches the outermost scope. However, interruption mechanism is not available in C++11 either."
"But all those threads computing fib1 are still running! And as they finish, they will write to all those instances of fib1. Which are no longer there, since the stack has been unwound. In its place will be the stack corresponding to the continuing computation that was initiated when the exception was caught. Thus we now have a large number of threads writing to various locations on the user's stack. By the time the user tries to debug the resulting mess, there is a good chance they will all be gone, leaving him/her with nothing but a stack with mysteriously smashed values. Or those might no longer be visible either because a return address may have been overwritten, causing the main program to take a wild branch."
As I am not well-versed in C++, I'm interested in knowing about these things. Perhaps it will give me a reason to seriously look at the language.