Again, your argument has nothing to do with the topic or thread. My point given the papers on the topic and the empirical information people have gathered in the past is that Julia is not weaker than other open source communities in this area. That doesn’t mean it’s good. It’s more of a statement of how awful open source maintenance is across the board.
Having a poor situation instead of an absolutely god awful one puts you in the top 1% of communities. A bus factor of 1 is the norm for open source across the board, and 2 maintainers is generally spectacular. We have many projects with 3+, and Julialang/Julia and standard libraries itself being at 7 the last time I saw an estimate, that’s something to cheer for. Not great, but that’s not something that is just weaker than what’s common in open source.
We should make it better, but doing better also requires understanding the situation.
The data that Heather shows, the Heartbleed story, the Wes McKinney stories, etc. have pretty decisively demonstrated this as false to the point that open source advocacy groups and the papers on the topic generally claim that to is little to no correlation between the size of a user base and the number of open source maintainers. I’m on my phone right now so it’s a bit hard to link, but I highly suggest you watch Heather’s talk and go through the resources. I wish there was a simple answer to getting new maintainers like having people get jobs using Julia, but the historical record loudly and repeatedly demonstrates that this is not the case.
We will probably pull this into SciML. I still need to take a deeper look and find some grants around the topic but it’s actually quite odd that some of Daniel’s packages weren’t in SciML, given how many SciML deps they had and the level of communication between us. I think now is just the right time to elevate some of his personal projects into larger maintained systems, including his finite volume work.
Chris has a lot of other things on his plate, but others in the community have already stepped up to help it update to Julia v1.11 and keep it alive. He wants to spend his open source time working on LoopModels, which is effectively the v2 of that package. So it has found enough of a home and there’s continuing projects here.
A static subset of Julia with which one can guarantee static behavior.
The ability to enforce that some functions or modules are static.
The ability to put type restrictions on functions which methods need to obey
Tooling to prove that certain functions conform to a given interface.
Then from there the discussion diverges into all of the Z3 SAT solver proving properties using types etc. discussion which gets controversial and has a hundred ideas. But those big points are the 80% and I don’t think I’ve seen anyone really disagree on those.
But while I say this, note that the compiler folks I talk with often have a priority on the binaries problem right now, so I don’t think this will get a priority until at least the next JuliaCon.
I do not have hard data concerning bus factor, so this is purely a “pathos” perspective:
My impression is that Julia’s maintenance story is pretty decent, better than most open source projects. The thing is, “most” people are not ever using “most” open source projects. Instead, they are largely sticking to a small number of giga-popular libraries which often have large corporate backing and are not even “true” open source.
Just as a minor example, I have opened 3 different bug reports in the polars library for Python/Rust, and all three were fixed (not by me) with a new release tagged within days. OTOH in Julia, even when I write and submit a PR myself to fix a bug it can take weeks or months to merge, presumably because of a lack of review bandwidth. And bug reports I submit often go indefinitely without even a comment or a bug label. And even when they do get fixed, it might take months more for a new release to actually go public.
I do not mean at all whatsoever to put shame or blame upon maintainers in the Julia community, and I absolutely appreciate that most are overworked and underappreciated just to keep the language&packages working as well as they do. All I mean to say is that occasionally the difference in community sizes is quite visible
I have been playing around with a macro to declare where the interface has been implemented.
@implements AbstractInterface begin
struct MyType <: AbstractInterface
# ...
end
# methods that implement interface
end
During normal runtime, @implements does nothing. It just passes through the expression.
During an analysis phase, such as testing, it generates tests or runs checks directly. The analysis is generated by looking through the AST to determine what the type is and and what methods are being overriden. Perhaps some automated export of meta-information would be useful as well for others to test composition.
An important design consideration for me is that this has minimal impact on actual runtime.
One minor weakness that no-one has mentioned in this thread is GUI building frameworks. I don’t use this myself, but I expect that this would be important for some commercial users and commercial users seem to be underrepresented in the Julia user base.
@ChrisRackauckas , Your style is the solution. Though your team is not the maintainer of all packages in your domain, your vision and steering keeps all efforts aligned and focused.
Other efforts require that style of steering as well: Static compiling, Plotting, Development Tools, etc…
It seems Julia eco system is very fragile. Even if Pandas has a single maintainer no one is afraid to be dependent on it. The commercial impact of Pandas is large enough. In case of a a need, someone will step up and take care of that, paid or not. That’s not the case in some of the main components of the Julia eco system.
From my point, there is still too much change around automatic differentiation libraries.
There is Zygote.jl, which is used in Flux.jl. However, it’s more in maintenance mode. At some point, Diffractor.jl was hyped but it didn’t take off yet. And then there is Enzyme.jl which people hype now.
But for me as a user, it’s not clear what I should really do to make my code well differentiable for those libraries. I was hoping that AbstractDifferentiation.jl could fix that but my take-away from that recent discussion was that it also has its issues.
If you stick with torch, jax or tensorflow, everything seems to work better regarding AD.
This is the same pattern I keep observing from people in my community (differentiable forward models in imaging or physics). We work with large 2D or 3D arrays (millions to billions of entries) and try to optimize on them. So it has to run on CUDA and AD is the main feature everyone needs.
The new public keyword in Julia 1.11 is a great improvement here.This, plus the new “correctness bug” label on GitHub issues and the push to document all public and exported symbols suggest that the “lax culture of correctness” is evolving in the right direction
I guess you’re saying we have too many end users?! Actually that’s never a problem, just too few maintainers, in absolute numbers. I doubt a ratio is valid, as very meaningful.
Also I think it’s very common for packages in any language to have few maintainers. E.g. Python might have more larger, and then more maintainers for those, but in Julia you have more smaller, and though also some meta packages.
I have no idea about ratios (or absolute numbers) for other languages at least, I only got involved on Github for Julia. I’m not saying your or other issues are invalid, just strictly not about the language, rather than the ecosystem. The language likely helps.
Could there be a new section in the forum called Call for Participation or CFP for package developers to ask for help? One may want to collaborate with a package, but not know which one or how.
I disagree and actually don’t think there’s a lot of change in the AD landscape. Frankly besides Enzyme and a couple of other projects like FastAD, I really haven’t seen a lot of feature dev time put into AD in Julia recently. And Enzyme.jl is supported by a few academics in their free time, and thus new features are usually prioritized by whatever projects fund us or research questions we find interesting (e.g. for me personally things like climate science and notably not presently ML in Julia [shameless plug that as a new professor am actively looking for funding and would love to collaborate and grow the team to do more stuff ]).
In contrast, I think that the issue isn’t that there’s change in the ecosystem, but rather there’s no universal AD that works on all Julia codes. All these libraries have their own caveats: e.g., Zygote doesn’t support mutation, Enzyme doesn’t have complete support for type-unstable (or activity-unstable) code, etc.
These limitations tend to be fairly well articulated in the forums/package docs when I’ve seen (and if not we should fix that), but I think that it’s non-obvious to users what these are given the diverse landscape of options rather than a single dominating megapackage.
side note, if you do come across problems using Enzyme (and we should move this discussion to DM/slack/GH/etc to not hijack the thread), please open issues. Like I mention above having type unstable code isn’t fully supported (we support some but not all such type unstable runtime functions), but we are actively aiming to grow the landscape of support. Unfortunately, this isn’t so much of an Enzyme problem as a Julia one (e.g. Enzyme’s C++ frontend, it’s JaX frontend [which now has support within Google], Fortran frontend, etc, don’t have these issues because this is a notion that comes from Julia – similarly other packages in Julia, like CUDA.jl, etc don’t support essentially any type unstable code).
My personal big wish is some sort of tool/notation/guarantee that makes it easier for users to identify, fix, and ensure code is type stable, considering how critical this is for much of the Julia ecosystem – especially when involving performance (e.g. a type unstable variable poisons all of its dependents to be type unstable, and all of these now type unstable operations are often orders of magnitude slower than say a direct add instruction).
again tangential but re Diffractor, I personally think this was a big blow to the momentum/ecosystem for AD in Julia. A lot of the messaging around it was that it was going to solve all AD problems. It was going to be “Ultra high performance for both scalar and array code”, “Reasonable compile times”, “High flexibility (like Zygote)” [aka drop in replacement that worked on al codes], “Support for forward/reverse/mixed modes”, etc (see Diffractor.jl/README.md at 61d68863eb61bab5b6b6908385930a44648bc97c · JuliaDiff/Diffractor.jl · GitHub). This really drained the enthusiasm for devs to work on things, since why work on an AD tool if diffractor was going to solve your issue better soon. These promises were big and naturally, when they failed to materialize, everyone who relied on it happening was left holding the bag. For a language/framework/tool/etc to thrive there needs to be good expectation setting (and perhaps there can be a guide to library project management somewhere). The reason why Enzyme lasted past this, was that it’s language agnostic (e.g. c++ users outside julia who wouldn’t have their needs met by diffractor, if completed), and just that Valentin and I are stubborn and want to work on fun compiler optimizations regardless .
But yeah @roflmaostc just to clarify and do expectation setting (and hopefully avoid another Diffractor situation), the reason people are “hyping up Enzyme” right now is not because it is promising to solve all your julia AD problems, but because frankly it is one of the few Julia AD tools being actively developed.
Presently, like mentioned, Enzyme’s goal is to create fast differentiates of high-performance code (e.g. code that you can use in a CUDA kernel – or more specifically, code analyzable by GPUCompiler, should be differentiable by Enzyme). Of course, as time progresses we are expanding the scope of what Enzyme supports. This includes adding support for most type unstable operations (but presently not all), adding support for most common BLAS functions (though similarly we haven’t done LAPACK yet), and reducing limitations on union types and exceptions. We hope to make most well-behaved Julia code differentiable, and have completed a majority of that work, but there is always support for more things that can be added, and things we haven’t tested.
Since I said that we’re severely manpower limited, please file issues on what you see, help write tests and docs, etc – spending some time working with us up front will end up in you having the best outcomes.
What kind of “interface” exactly? Duck typing really helps with generic code. If you’re talking about the benefit of compile-time check where methods can guarantee that the types passed in have methods and won’t error out from method not being found, then it is plausible.
However… if you’re doing things like… “If the element type of this data structure has associative over operation ‘+’ then this data structure is foldable.” I think it’s staring at an endless abyss. You either not get fully generic code like…
y::foo-able = f(x)
foo!(y)
Then, you have several options. Do you add an interface that enforces the foo-ability of f(x)?
Maximum and easy generic is what allows code written in one area to be used in several areas, and it is something I would say we should hold on dear life.
How good is CxxWrap.jl? Haven’t tried it yet, but it’s a bit concerning that such an important package is only documented by the GitHub README not standalone tutorials.
