So? This whole argument over which programming language is the best all seems a bit tools-first to me. I used to program in R and was a package owner, but switched to python because it had stuff I needed (TF before it ever got ported to R).
Nowadays I program in python because it has all I need. If something comes out in Julia that makes the cost of picking up another language worth it then I'll do it without a second thought. Until then, why bother? The don't waste your time argument can cut both ways, you know.
To clarify: I see no inherent reason to not program in Julia or any other language. But you work with whatever gets your job done efficiently and right now that's neither of those languages for a lot of people.
Uh, adoption by the community at large? The best program is the one you didn't have to write because a package existed for it already. Just because a language has a foreign function interface doesn't mean it's easy to interact with other libraries.
R, Python, Matlab, and C++ are the big dogs in scientific programming, and the inertia behind having a large community behind than will continue to drive adoption.
It's a matter of ecosystem of packages. R has a huge number of packages for many fields. Python has fewer, but might work for particular use cases. I was excited for Julia, and played around with it since 0.2, but it really hasn't generated very many packages of note in my particular field (bioinformatics).
I mean fewer (and less developed) in the context of data analysis and statistics where it is a competitor to R. Every time I consider using Python after getting frustrated with the more ugly features of R as a language, I take a look at what's available in Python, as from a language point of view it is a bit nicer (as is Julia). But then I see what I would have to reimplement myself if I switched, so I don't.
It would really still depend on the support libraries around the task you want to write, if you really need more performance for the parts that those support libraries don't cover (and beyond what you get with PyPy or Numba) and which language you have more experience with.
If you're really going down to the FFI, it's hard to think it wouldn't be more productive, but that's not what a true beginner like the target of this book would do. Though it's quite nice to quickly extend some tool for your purpose without compromising anything or to understand how something works thanks to being written in high level code.
Syntax-wise, Julia's Common Lisp-like feature set gives the language a lot of power, but normal use will probably be just on par with Python in terms of productivity.
I love Julia, but feel the interop story could use some work. If I want to have my python package depend on some Julia code, how easy is that? Last time I checked (a few months ago), it was pretty difficult.
That's an opinion my friend, not a fact. If you want to be taken seriously, be sure to be careful in your assertions and always have hard data to back them up
I whole heartedly agree. Python is garbage for data science. If an industrial grade NN library was written for it, plus some quant libraries, I think most people would switch.
I work in finance doing data science-y things and have yet to meet anyone who doesn’t think that Python is a pile of garbage.
People used to make the easy to learn argument, but Julia is even easier. And more elegant, extensible, and faster.
> If an industrial grade NN library was written for it
Can you give tell us which language and industrial grade NN library you're using?
Because from where I'm sitting I see that Python is the only language that gets first grade support for both Tensorflow and Pytorch. It's so ahead for working with NN that it's not even close.
Whenever I see the “I’ve never met x” argument, I’m always looking out for the catch. Because it’s a bad argument to begin with. But the catch is almost always in a situation where x is everywhere, and you would have to have your head willfully stuck in a hole in the ground to not see it.
Not sure how that's relevant. Everything is written in something else.
Python itself is written in C. The Julia github repo shows Julia 68.2%, C 16.3%, C++ 10.4%, Scheme 3.2%. R is a mix of C, C++, R and some Fortran I think...
It is relevant from the point of view of what a developer is able to achieve without being forced to drop down to a 2nd programming language, aka "2 language syndrome".
And how many Python libraries are just plain wrappers, not really written in Python.
are you suggesting that data scientists use C++ for day to day work? those libraries have first-class wrappers in Python (there is R support, but not at the same level).
