Can you please suggest me which language is more suited for web development? Go or Julia?
On Saturday, 22 February 2014 03:19:49 UTC+5:30, Stefan Karpinski 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 > >
