Because Julia has no support for user-level threading at the moment.
On Fri, Feb 21, 2014 at 5:19 PM, Dave Bettin <[email protected]> wrote: > I am not a C++ dev, but I am curious, why does Julia not satisfy the C++ > multi-threading capability? > > > On Fri, Feb 21, 2014 at 1:49 PM, Stefan Karpinski <[email protected]>wrote: > >> On Wed, Feb 19, 2014 at 3:50 AM, Gour >> <[email protected]<https://mail.google.com/mail/?view=cm&fs=1&tf=1&[email protected]> >> > wrote: >> >>> >>> I understand your focus is technical computing, but still believe, >>> as Dave has written: "However, there is this beautiful general >>> purpose language waiting to be unleashed onto the masses." because we do >>> not consider that e.g. 'writing desktop applications' is solved problem >>> when programmer can choose between C(++) or Python. :-) >>> >>> Iow. there are applications which involve computations not >>> maybe strictly following within the scope of 'technical computing', but >>> for which Python is not quick-enough. >>> >>> Then, we're left with C(++) and that's why I believe Julia is >>> perfectly suited to fill that not-so-small gap! >>> >> >> Yes, I think that we can take challenges in any form – from technical >> computing or elsewhere, including desktop apps with high demands on >> performance. However, I still believe that scientific computing has many of >> the hardest challenges around, so focusing on it and really killing it in >> that area still makes sense. >> >> Julia does fit nicely into the gap between C++ and Python. We were >> initially surprised by the number of people who started coming to Julia >> from C++, but it makes sense when you think about it. Both languages >> allow you more abstraction than C without losing much performance – and you >> can consciously trade off a higher-level programming style in exchange for >> efficiency, all the way down to writing C-like code and getting C-like >> performance. Julia's parametric types and "everything is a template" >> approach has a very similar effect to C++ templates, but with far less >> brittleness and hassle. And of course, C++ uses operator overloading >> rampantly, and Julia's generic functions are basically overloading "done >> right" – including operators, which are just functions with special syntax. >> So if the main things you liked about C++ were: >> >> 1. performance >> 2. generics and templates >> 3. operator and method overloading >> >> then Julia is a phenomenal C++ replacement. If the things you need from >> C++ extend to manual memory management, pointer arithmetic, and >> multithreading – which are very legitimate needs for some applications – >> then Julia is not a great C++ replacement. >> >> Interestingly, I think this analysis sheds some light on why Go has not >> made as much headway as a C++ replacement as the creators expected [1]. >> Consider how Go stacks up on the six C++ features mentioned above: >> >> 1. performance: ok. >> 2. generics and templates: no. >> 3. operator and method overloading: no. >> 4. manual memory management: no. >> 5. pointer arithmetic: no. >> 6. multithreading: yes. >> >> Regarding performance, Go is still often 5-10x slower than C and unlike >> C++ and Julia, when you're in one of the slow cases, there usually >> isn't a path to give up abstraction in exchange for performance. If your >> Go code is slow, your only recourse is usually to wait until the Go compiler >> gets faster – which, to be sure, it has been doing. Go's performance is >> really impressive if you're coming from Python or Ruby, but not if you've >> been using C++ for its abstraction/speed sweet spot. >> >> Go provides 1.5 of the six major features C++ programmers might want – >> and only 0.5 of the three most popular features (performance, generics, >> overloading). I think this analysis is a better explanation of why C++ >> programmers are not flocking to Go than Rob Pike's theory [1] that C++ >> programmers love complexity and features and therefore hate Go because >> it is so beautiful and simple. Go is a great language and its design >> choices make a lot of sense for many applications – but it's just not a >> good replacement for C++ in many ways. Instead, it's an excellent >> high-performance, concurrent replacement for Python or Ruby. >> >> [1] >> http://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html >> >> >
