Julia vs Python: Which programming language will rule machine learning in 2019?
techrepublic.com/article/julia-vs-python-whic...Posted Dec 8, 2018, 12:53 AM UTC
022
techrepublic.com
Yikes you guys downvoted an article that actually spurred good discussion
1
Neither - because these machines do not "learn".
Wrong phrases are being propagated by the buzzword department.
As for the adoption rates of Julia versus Python - it does not take a genius to predict what will happen.
Python completely stomps Julia. Don't exist in the reddit hype bubble.
-21
Nice I've finally found an expert on learning. Can you help me? how would you define learning?
8
[deleted]
-3
Everyone can see the point, but it's a purely pedantic one coming from a known troll.
2
[deleted]
1
Neither - because these machines do not "learn".
Wrong phrases are being propagated by the buzzword department.
As for the adoption rates of Julia versus Python - it does not take a genius to predict what will happen.
Python completely stomps Julia. Don't exist in the reddit hype bubble.
-7
Python is the worst language for high performance computing which is why it's used the most often for this type of thing. This industry is horrible at choosing best products to solve our problems.
Sure it's got a GIL and is slow as balls but it can call C libs so let's use it because no other language in the world can call the same fucking C libs right?
I think there's more to it than just calling C libs. The actual work is done by C and C++ libraries, but at that bare metal level it's also hard to work with. Python is a nice wrapper around these libraries with easy syntax, performance penalty of the actual cross library call is negligible, and lets people get started right away.
Julia is nice but immature. Python already has wrappers for nearly everything. Even if Julia manages to catch up, there's not much that will get anyone to switch. The benefits of Julia over Python are minimal due to the GIL and other penalties being negligible. Why change your diet from bread to bread if you end up with the same nutrients and proportions, just a different looking loaf? Not to mention having to teach yourself how to fit that new loaf in your mouth.
Same could be said of many faster languages without a GIL.
Every non trivial scientific app in Python uses external processes to manage parallelism. It's a horrible language for scientific work.
Can you elaborate or are you just making a bare blanket statement with no true contextual basis?
What kind of elaboration are you looking for? Most python scientific projects make heavy use of celery because python is too slow and doesn't have true concurrency.
Is that what you are asking?
That is not true. As your Python code grows, things start to get slower due the overhead of Python itself, leaving you with no choice but use the CFFI, which defeats the "nice wrapper around these libraries with easy syntax" argument. Writing the "hot" parts in C is such a common thing in Python that even the standard library does that.
Performance is a pretty good reason to switch, specially in the ML field, where dealing with huge amounts of data and expensive algorithms is the norm. Never heard of Swift for Tensorflow? Following your analogy, it's like turning a plain white bread into a tuna sandwich. And since when the GIL is negligible?
I think you're heavily misunderstanding my point. Making a C call in Python is negligible due to the performance benefit that C brings. You can use CFFI and still have a nice wrapper around C libs, and you can not use CFFI just fine-- Python extension modules exist for a reason.
The performance of Julia can not be better than the performance of C. Python ML does not occur in Python, it occurs at the C level, and uses a Python wrapper for interaction. If you don't believe me feel free to look at Tenserflow or PyTorch or whatever else.
I have never heard of Swift for Tenserflow. I have never seen a single person talking about it before you. Compare the activity of stars and followers of that repo with the main tensorflow one. It has 1/40th the following at best. If that's what you call a tuna sandwich, the fish is rotting.
The GIL is negligible because it applies only at the Python level. There are mechanisms to release the GIl at the C level, which is what any sensible Python wrapper does whenever it can.
Just the fact that something like Swift for Tensorflow exists show that using Python for this task is not a good idea. And Github stars? Really? There are lots of outstanding projects with way less stars than Swift for Tensorflow has.
No no no, always there is a cost using FFI in a dynamic language. For example creating a numpy array results in allocating a PyObject, initializing method slots, etc. This paper, despite being quite old, gives a overview how Ruby, Python and Lua communicate with C.
Agree. But why Julia? Has anyone seen CLASP? It's a Common Lisp implementation able to directly integrate C++ libraries without need of an adapter layer. The implementation is 10 to 20 times faster than Python and successfully used in science.