Comment by vegabook | Hacker News Reader

Comment by vegabook | Hacker News Reader

I am a little weary of the hype around a language whose unique selling point is speed. Where else in Julia is there significant innovation versus Python? The latter seriously has it all when it comes to scientific computing, and if anybody is not already running vectorized numpy code, or trivially compiling critical for loops to c-like speed using Numba/Cython, then they're missing out on performance which has nothing to be ashamed of versus any of the newer kids on the block.

I have been weary of the Julia pitch which was basically "lets brew R, Python, and Matlab (all >20 years old with massive and unrivalled ecosystems and all serving their purposes very well, thank you) into one "new" language and put a nice logo on it". How is this language seriously the leap forward that one needs to abandon the current awesome toolsets, with all their battle tested libraries, other than a nebulous "speed" argument which in many cases, judging by the comments and my own experience in financial data matrix operations, is not even fully accurate? Ready to be persuaded otherwise if I can be shown that other than "speed" there are hefty reasons to move from Python and abandon the almost endless choice of richly varied tools that I have at my disposal already.

You should read the paper, but Julia's also a really nicely designed language in general. It's hard to communicate how great multiple dispatch + a powerful type system is without trying it out (though, again, the paper does a good job), but yeah, it really helps you get a lot of generality as well as performance. When you use Cython, you immediately lose that generality.

Then there's the really powerful metaprogramming capabilities, which are absent from the languages you've mentioned. I can't emphasise it enough: the paper this comment thread is about does a great job of explaining why these things are compelling.

Also, you may be interested in [1], an argument that language performance is valuable even if you don't need it yourself.

[1]: https://medium.com/the-julia-language/performance-matters-mo...

Compelling argument in your link about how performance for others allows for better libraries for everyone. I am still concerned that Julia does not go far enough in breaking the imperative programming mould, but I think it's disingenuous not to give it a serious try in more than trivial exercises. I have to say though that I have learned R, Python and Golang in the past 8 years and all of them are basically imperative (though R's vectorisation-everywhere is impressive - wish it was all just faster); I hope Julia will give me something dramatically more interesting. I say that because the LLVM has ushered in a period of radically easier language development, so we are likely to be spoiled for choice in the next 5 years. I hope Julia has done enough to put itself way out there in in terms of innovation to make the sizeable investment of time for myself and library developers, worthwhile. Altogether however I cannot be anything other than impressed with the dogged and convincing pitch that you and others are making for it, which somewhat lowers the risk of investing time in a dead end. And even if it doesn't work out all hunky, at least I'll know that Python will face serious competition, and that can only be good, even for Python.

How does the upcoming and even current numba+blaze power duo not allow library designers to easily write fast code?

Well that was the point of my original message. I am using numbapro and easily getting to c-speed with R-like vectorized convenience right now. It's why I question the "speed" argument as a non-argument when compared with Python. And I haven't even started using the cuda approach... You allude to another point though: Python is not standing still. Python and its environment is a mighty high mountain for Julia to climb if it's not going to move the game forward significantly so that its big ecosystem disadvantage is compensated. Julia cannot just do incremental improvement - it doesn't have enough momentum to make that a winning strategy. It needs to leapfrog to take on Python.

I should add one more point though. The post mentions Matlab 15 times and Python only 7. It's possible this whole Julia effort will be successful with the Matlab crowd which, up to now, has been watching with horrified fascination from the sidelines as open source ate its lunch.

Nice. Do you find yourself having to contort code to work with numbapro?

Reply on news.ycombinator.com