Hacker News Reader

Comment by one-more-minute | Hacker News Reader

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...

View on HN

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