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.
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.
God, please not another one with new tools, new libraries, etc.
Julia — odd language
R — not a general purpose programming language
Most of the data scientist and ml engineers I work with want a new language. So yeah it’s not a bad idea
What a profound criticism. If data scientists can't use Julia then they're not great data scientists - you have RCall and PyCall, Flux, Knet, MLJ, plotting libraries, etc. It has built-in and user-defined types, threads, multiple dispatch, ...
"Please don't think that Julia is only useful for 1. custom units 2. custom GPU kernels 3. Custom array types 4. custom bayesian priors. 5. AD through custom types 6. Task based parallelism 7. symbolic gradients with modeling toolkit 8. Agent based modeling 9. physics informed neural networks 10. abstract tables types ..."
I really tried to like Julia, wrote it for months, but it misses the mark. I've been working in analytics for 10 years and of everyone I know who's tried it I only know a couple people who like Julia.
Thats a problem, and you can see it in the adoption numbers. The Julia community keeps wanting to bury their head in the sand and pretend its not which is fun.
Anyone familiar with Python is unlikely to struggle with the syntax of Julia or with reading straightforward Julia code. In fact, I'd argue that Julia is easier to learn than Python in many aspects.
Python is now a large language, not the small, simple language of years past. Of course, in both languages (Julia and Python) you can ignore complex features.
But what Python also gives you is abundant examples and solutions to problems that are easily found on the Web.
In contrast, new(ish) programming languages suffer from a lack of libraries, examples and tutorials that slows down momentum.
~ the one end Ashton Tate delivering a shallow learning curve declarative language for semi referential data that SOHO novices can create applications with, and at the other, Stonebraker wanting to put the neatness that pure client computing enabled (dedicated cpu time and architecture leading to multimedia inexpensively) together with large system semantics [0] long before capabilities, a curse I believe was academic grant seeking behaviour in origin.
I seriously keep seeing the results of driving forces individually uniquely capable in project conditions which are very difficult to reconcile with the ultimate purpose software is used for. like, before Jim Keller quit Intel, he gave a talk explaining how Tesla was founded on a unique case where reductions to silicon were optimal for CAFÉ and that's a rare case, and how he couldn't see the 22 people in the audience he knew can tune the full performance out of modern silicon software instructions. (probably that should have called out his imminent departure considering the proliferating instruction set at Intel and his unusual call out to a success he thought worthy of mention). it used to be academia thinking about small systems applications and development, eg the Edinburgh AI group up to the 80s and Carl Hewitt thinking about how to make "next use unknown" a good thing in PLANNER. But certainly lately academic prowess has adhered to scale and the apparent needs of the largest computing users. If there's a impedance mismatch here I think it has evolved from putting the solo developer in the employ of hyperscalers without any thought about the effects of that situation.
[0] personally I remember the talk preceded the walk by some 20 years or so) and simultaneously take on the big iron boys at IBM. Oracle drove it's ugly polluting truck thru the middle and created a empire that we're still far from superannuating (not replacing, in the view of this guy seriously targeting openVMS 9.3 with the ability to have workstations join the cluster and run transactions across the system and db against the same native transaction manager and define time series objects using FORTRAN and make the cursor over the resulting blobs addressable from DEC BASIC inside user applications including Excel soon to be patched to the VMS TM via SRV-IO via a switch on the same NIC. All very much old functionality becoming the new. if I'm allowed to write about it, I will probably emphasise just how much innovative design has been enabled by expensive licensing and recount my memories of how nothing ever cropped up to address comparable needs in the FOSS world despite the foundations resting upon some of the most well documented CS and being wonderfully unencumbered by IP inhibitors due to the passing of time.
I agree it needs to be as simple as python on the high level though, or the data science end of the spectrum will just never adopt it.
before getting distracted by dot net and mono, I feel I have to lay the blame (and my nineties) at the feet of CORBA and the Object Management Group. Seriously though, what was the OMG but a UNIX consortium trying to break the hold of DEC and VMS over the most complex critical systems..
I stand with my "pitched by Google" :)
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.
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?
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.
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)
AsyncIO is quite complex in how it works. You use the same patterns for concurrency in Julia, but it is so much easier to grasp and work with.
Multiple-dispatch as used in Julia e.g. makes API design so much cleaner. You can see that almost anywhere. I make some comparison of making REST calls in Python and Julia here. Julia is much cleaner IMHO: https://erik-engheim.medium.com/explore-rest-apis-with-curl-...
The Python problem is that you cannot reuse the same function name easily for different types. Hence instead of creating one abstraction across many different types you need to invent all these different names which can be hard to guess. In Julia there are often far fewer core concepts to learn which can be re-applied in far more ways.
Python insistence on an object-oriented approach often creates problems. I have some observations on that in machine learning, looking at PyTorch compared to Julia's Flux: https://python.plainenglish.io/python-experience-in-machine-...
Out of the box experience is not all that great. The Python REPL is very bare bones. https://erik-engheim.medium.com/python-vs-julia-observations...
Things like calling shell programs is done more elegantly in Julia. Same with calling C functions. String interpolation is more obvious. There are not like 4 different ways of doing it.
Package management and environment management is much simpler and elegantly done.
I agree some of this may seem unfair as Python has baggage from being an older language. But that also counts in its favor with wider selection of libraries. Both should be taken into account when evaluating your choices.
At least there's `functools.singledispatch` in the standard library. There's apparently also multiple dispatch libraries. I've never used either, duck typing with some try/except (and some isinstance) has served me well so far, but I agree it's not as clean.
> There are not like 4 different ways of doing it.
Yet.
> Package management and environment management is much simpler and elegantly done.
Yeah, it's a nightmare in Python. After setting up projects dozens of times now I still don't grok it.
Yes Python is very dynamic, not more than Smalltalk, SELF or Common Lisp, all with quite good JIT engines.
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.
Python has a bunch of specific use-case, non-interoperable limited JIT’s that you have to learn separately.
Not the case with Julia: you write some arbitrary code, it gets optimised, so much simpler. The Julia community did some cool things with Flux where complex and field-specific equations were dropped wholesale into neural-network definitions without having to rewrite anything. That sort of power is invaluable.
I follow Python and Julia more as language geek than anything else.
Specially since ecosystems like CUDA have been polyglot since the early days.
I also really really really (really) like Julia, but don't quite think it's there yet. I'm optimistic though, these things take time.
It's growing in a sprawling, disorganized fashion. It's developing generics (with horrid ambiguous syntax) for semantic typing that's not generally used outside some applications. The walrus operator is obscene.
I used to be a huge Python fan, and I’d dug through docs and guides for pretty much everything I could, so my frustrations aren’t “outsider criticisms” as such.
My biggest issue is the amount of “magic” that goes on and is actively encouraged; it happily lets you get away with anything, and I’ve read and had to fix too much horrible Python code that technically does what’s required, but in the most torturous and difficult-to-untangle manner possible. I’ve come to resonate with this idea of “what does the language/tooling encourage you to do” and in my experience, Python doesn’t encourage a lot of good things, but it does end up encouraging you to “hack around problems” rather than fixing them at their root, lean on magic wherever possible (which is never backed up by any kind of correctness guarantee) and let the programmer do whatever they want, regardless of how much of a bad or non-idiomatic thing it is. The “type system” leaves a lot to be desired, there’s optional type hints now, but the larger community seems ambivalent at best-uptake is glacial in my observations and mypy is just sort of ok. The performance is pathetic, there’s no getting around that, and the response of “just write it in C if you need speed” is a poor answer. The Python core dev team seems insistent on continually stacking pointless new features in (walrus operator why?) whilst simultaneously not really doing anything about real issues (like the packaging situation). I’ve also come to really dislike exception-based error handling: having no compiler, type-checking and knowing that anything could explode anywhere isn’t a reassuring feeling once your codebase gets big enough. Yeah you can put try-catch, and code defensively to head-off issues, but it doesn’t take much before you’ve spent as much time and energy doing that as it would have taken to write it in a more suitable language but with maybe 1/10th of the guarantees and none of the performance. If you want to write a web API, you’d be better off writing something in Golang, .Net, Typescript on NodeJS, possibly even Swift.
General purpose stuff you could replace with any of those languages + Rust. Admittedly it does still have prime position for ML frameworks, but I’d be using Julia at work if it was up to me.
Edit: a sibling comment mentioned Async in Python - an experience that was so frustrating I’d excised it from memory.
How are you finding it? I’d like to think that with some suitable package evolution/development doing production ML stuff in it would actually be pretty reasonable.
What packages are you using? Linfa looks like it’s developing strong legs and SmartCore seems be ticking away in the background quietly...
I mainly use tch-rs which are just bindings around libtorch, there are a couple edges wrapping c++ (function overloading) but overall it works great. I've also used ndarray a fair amount which is nice.
The ML ecosystem in Rust is a bit underdeveloped at the moment, but work is ticking along on packages like Linfa and SmartCore, so maybe it’ll get there? In my field I’m mostly about it’s potential for correct, high-performance data pipelines that are straightforward to write in reasonable time, and hopefully a model-serving framework: I hate that so many of the current tools require annotating and shipping Python when really model-serving shouldn’t really need any Python code.
So neither Python not Julia.
A lot of people would be horrified to see how many business critical processes depend on a bunch of hacked together excel workbooks.
They reach for VB.NET when there is nothing left for VBA.
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 .
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
Take a look at the LIDAR toolbox for example: https://www.mathworks.com/products/lidar.html
or LTE: https://www.mathworks.com/products/lte.html
and I've used DSP toolbox the most: 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).
Personally, I managed to switch over 100% and DifferentialEquations.jl is the reason that made sense for my work.
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
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.