5 ms·
This feels like a very strongly worded title for a fairly lacklustre article. There’s Python the language and “Python the dsl for tensor frameworks”, the forme
by FridgeSeal 6y ago
This feels like a very strongly worded title for a fairly lacklustre article.
There’s Python the language and “Python the dsl for tensor frameworks”, the former has arguably lost some ground/mindshare to newer, less “hobbled” languages, and the latter exists not by virtue of its own strengths but as the convenient vehicle for frameworks written by 2 enormous corporations.
Julia hasn’t overtaken Pythons ecosystem yet, but how far its come in relatively little time is the real testament to its community-that which the author decries as lacking.
Using weird outdated rankings and citing “that one package that kind of works in very specific circumstances” (Numba) as proof that all Pythons issues are solved and Julia is over is a weak argument at best, and deceptive at worst.
What Julia could really, really benefit from though is some vocal commercial backing-had google chosen to rewrite Tensorflow in Julia I think 2 things would have happened:
1. the project would have actually succeeded and been finished (in a “this is the tensorflow engine now” sense)
2. It would have done absolute wonders for the Julia ecosystem and mindshare and we wouldn’t be having this taudry discussion.
That didn’t happen (unless some tensorflow product managers want a promotion by re-launching a tensorflow rewrite? ;) ) so they need another source of major support IMO.
- apples2apples 6y agoI'm sorry but deep learning is only a very small part of why Python is preferred by data scientists. The fact that Python was the the preferred language is why the enormous corporations wrote bindings to them. Both of these frameworks exist in the Julia ecosystem.
- FridgeSeal 6y agoAs someone who does data science, I roll my eyes every time I have to touch Python. It’s ubiquitous, but it actually sucks once you get used to better languages. It is somewhat circular: it was preferred because your earlier alternatives were Java or C(++) both of which had their shortcomings. SKLearn is still one of the most feature-complete and powerful libraries and it was Python only and thus drew a crowd. A lot of people who write data science code, I would be confident to bet that if you taught them Julia first, they’d prefer that.
- agumonkey 6y agoI have a few questions since you have a broader view. What other languages do you prefer ? What python traits do you think are weak ? (I'm no python fanatic but I like it as a tiny swiss army knife)
- pjmlp 6y agoNot the OP, the community approach to performance, that rather rewrites code into C, still calling it Python (?), instead of being more supportive of ongoing JIT endeavours. Yes Python is very dynamic, not more than Smalltalk, SELF or Common Lisp, all with quite good JIT engines.
- agumonkey 6y agoThat's my opinion, and coming from you (from what I get you're seasoned in many area of the computing field) it's not surprising. But the current mainstream is not really aware of all this. There's tiny python cult due to scipy et al.
- pjmlp 6y agoYep same wavelength here. There is another thing, most of the major libraries where Python is used as DSL, written in a mix of C, C++ and Fortran, can be used in other languages just as well, nothing special about Python there other than lack of awareness of what everyone else is doing.
- johnnycerberus 6y agoIn the ML, DL world or in the physical simulators, people just compose a task and throw it to a CPU/GPU/TPU or a cluster of these and let it run for a long time. I don't see how Julia will be different for this kind of tasks. I understand that in Julia you solve the 2-language problem and all the goodies that multiple dispatch brings but the Python ecosystem progressed a lot in the past 2 years, now you have Numba JIT, Jax JIT, PyTorch JIT, XLA JIT and many other proprietary JITs that are not open-sourced. Since JAX (as an example) is mostly numpy and Python, you can leverage your existing knowledge instead of having to learn a fundamentally new paradigm. I would say that Python has many "specialised" JIT engines and it seems to work great for the community. Don't get me wrong, Julia is interesting, I can't deny that but I expect a huge adoption period for it. It can find its niche as C++ did for extremely high performance computing or Scala for Big Data (though Java is starting to replace many use cases). If you ask me now, I would say that the world converges around Java, C++ and Python when it comes to data, the old trio and it will remain this way for at least another decade.
- pjmlp 6y agoSome companies I did consulting for, the data scientists would rather use a mix of Excel, Tableau, VBA and VB.NET. So neither Python not Julia.
- galangalalgol 6y agoI get the first 3, they are surprisingly powerful for data. But why VB.NET? Its many times alower than VBA.
- pjmlp 6y agoSince when is a compiled language with JIT/AOT toolchain slower than an interpreter? They reach for VB.NET when there is nothing left for VBA.
- tharne 6y agoExcel has proved itself shockingly resilient. We all make fun of it, but man, with smaller data sets it gets the job done. A lot of people would be horrified to see how many business critical processes depend on a bunch of hacked together excel workbooks.
- sjkelly 6y agoI think even since 2014 there have been many niche technical computing companies supporting development quite successfully. Bigger players definitely would help, but I think most of that at this time is more public/private research money for scientific computing. Hence Julia has many academic contributors (grad students and post docs a likely majority), many of which are now becoming professors and industry leaders. The post 1.0 world in Julia has been spectacular for development stability. In the early days it was somewhat tiring trying to develop basic foundational libraries, and keep pace with language changes. 1.0 has stabilized things quite a bit, and the forthcoming LTS (sometime this year maybe) I think will really start to button up some of the major issues people have with package load times and installation.
- veddox 6y agoYes, writing pre-1.0 Julia code was like balancing on a log in the water - the platform kept moving under you :D I'm glad it's gotten a lot stabler now. And I agree about academics as a key user base. I think Julia's growth is far from over, there's a lot of organic spread yet to come. It may never replace Python in terms of global popularity, but then, why should it have to?
- dgellow 6y ago> What Julia could really, really benefit from though is some vocal commercial backing-had google chosen to rewrite Tensorflow in Julia I think 2 things would have happened We have the example of "Swift for Tensorflow", which was pitched by Google as the "next-generation platform for machine learning" (that's from their own website) and didn't result in anything meaningful and is now dead as far as I understand. I'm not that convinced that would work better with Julia.
- dunefox 6y agoThe project was pushed by Swifts creator and it failed supposedly because he left Google AFAIK, so for Julia it would most likely have worked out much better.
- FridgeSeal 6y agoAt the time they were “picking” candidates for the Tensorflow rewrite, Julia already had Flux with an early version of Zygote and was doing auto differentiation at the language level. This was literally the killer feature they wanted, and were prepared to re-wore how significant portions of the swift language and compiler functioned to get it. Had they chosen the language based on actual suitability and not because one of them was Chris Lattners pet-project, they could have automatically been significantly further ahead in far less time and energy.
- yahyaheee 6y agoYeah Google really messed this up, they had a golden opportunity and they went the wrong direction. Julia would have been better but IMO they should have just created a new language from scratch
- square_usual 6y agoYou've used "former" twice in your second paragraph, and I believe you might've intended to use "latter" the second (latter ;)) time.
- FridgeSeal 6y agoAaahh good catch, thank you! :)
- prionassembly 6y agoI like the idea of Julia but had a poor time making it work (circa october-november 2020) on my Ubuntu laptop. It also refuses to work in environments like repl.it. I feel like it's quite imature still, and that I'll try to pick it up later when it's better.
- make3 6y agothere have been Julia bindings to Tensorflow for a long time, and you can just use the Python ones in Julia with PyCall anyways. People haven't been doing that.
- make3 6y agoI'd be very curious to see a source about your claim that Python is slowing down for uses outside of deep learning, I'm pretty sure you just made that up and it's false, not to be blunt
- yahyaheee 6y agoIt’s pretty ubiquitous among new developers but for working software engineers I think it’s uses are becoming limited. If you need a web server there are much better choices. Data analysis and scripting are about the only places I see it used successfully nowadays
- rademacher 6y agoJulia only hit v1.0 in 2018. It's doing pretty well for being so young in my opinion. All the arguments against Julia are basically that python has a lot of momentum and it takes time and effort to switch to a new language. I think Julia should really seek to displace MATLAB as a near term goal .
- machinelabo 6y ago> I think Julia should really seek to displace MATLAB as a near term goal . Have you studied MATLAB and its ecosystem? It ranges from real time control to image recognition to sophisticated engineering-specific toolboxes (RF, 5G, LTE, etc.). They also have proprietary algorithms that do things no Julia package can do. Sure, there is PDE solvers and the ecosystem is growing for Julia, but it is at-least an order of magnitude smaller than MATLAB if not more. I urge you to explore the documentation, APIs and toolbox details on MATLAB: https://www.mathworks.com/products.html https://www.mathworks.com/products.html Take a look at the LIDAR toolbox for example: https://www.mathworks.com/products/lidar.html https://www.mathworks.com/products/lidar.html or LTE: https://www.mathworks.com/products/lte.html https://www.mathworks.com/products/lte.html and I've used DSP toolbox the most: https://www.mathworks.com/products/dsp-system.html https://www.mathworks.com/products/dsp-system.html I am not condoning use of MATLAB, just stating the facts having used Julia and MATLAB extensively. I personally like Julia language FWIW. At work, we use MATLAB and happily pay for it. Their support is absolutely top-notch and for us it is the reason alone to use MATLAB. Julia has support but not even close to MATLAB's direct line to compiler engineers (yes, I've had them fix a bug and do a release in an afternoon).
- vcxy 6y agoYou're absolutely right. I'll agree with the person you replied to as well though: displacing (at least some portion of) MATLAB use cases really would be a good goal for Julia. Personally, I managed to switch over 100% and DifferentialEquations.jl is the reason that made sense for my work.