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
