Development resources for Julia ecosystem?

As a general comment, since this is a pet peeve of mine: There’s a difference between a “debugger” and a “tool for finding/fixing bugs” (a “de-bugger”). This distinction tends to get lost in many discussions, but it’s important. Julia has pretty good tools for de-bugging. @show, @info, Infiltrator, etc. And AI tools can further help with that. But a Debugger is a very specific type of software that allows to run a program with breakpoints, and when it hits a breakpoint, continue to step through (step-in and step-over) the code, and to inspect the local variables in every frame. A good debugger also allows changing variables, and to step up to explore different code paths.

The primary use of a Debugger isn’t necessarily to identify bugs, it’s to understand control flow. If you have a large code base, you want to be able to run an “experiment” and follow the exact code path that it takes. This is all the more important in Julia with multiple dispatch, because it is impossible to know from reading the source code which method a particular line will call. Even if somehow you knew the types of all variables, you can’t know whether some indirect dependency might define a method that you don’t know about. There’s which of course, but sprinkling in which statements in combination with print-debugging` is not a great experience.

There isn’t really a substitute for a good debugger for diving into unfamiliar code. The only debugger we have in Julia is Debugger.jl, and it’s not in great shape, with the difficulties of switching between compiled and interpreted code.

23 Likes

:clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap:

5 Likes

I didn’t say this. The statement you screen shot says that people are selected to be independent (which they are), and “representative of the open source project,” which I take to mean Julia itself.

And given this list of people is probably (many) years old, I certainly don’t object at all to the idea that shaking it up might be a good. The community had changed a lot over the last decade. What I object to is the implication that this statement is a lie or that there’s something underhanded going on. Like Stefan, Tim, Avik et al are some nefarious cabal of fat cats sucking of the teat of “the community.”

Why do we have a right? I mean, I totally dig transparency, and it makes me happy when things are in the open, but if I started using your packages, even if I developed a really important dependent, would that entitle me to start dictating your development priorities and demanding that you disclose how you’re spending your company’s revenue? I don’t think that it would.

The Julia community has a stake in the development of Julia, and I think many, myself included, would be less likely to spend the amount of time and energy engaging with the community that we do if things were less transparent. You are perfectly within your rights to ask that things be different than they are, with respect to governance or transparency or development priorities or whatever else, and to vote with your feet if things don’t go the way you want.

I am pushing back on your sense of entitlement, your demands, and your implication that you speak for “the community”. I’m part of this community to, and you don’t speak for me.

I genuinely think this is great! I really appreciate your efforts on that part of the ecosystem, and I think it’s wonderful too have companies using Julia. Kudos.

Now, why aren’t you paying someone to develop the VS code extension? Have other priorities for your effort and attention and money? Maybe that ought to tell you something?

Except this is not my argument. You have a word in this community. You use it, and I’m glad you do. I have a word too. We even often agree on substance, believe it or not. I don’t use VS code any more, but I recommend it to students and I totally agree that it would be awesome for it to be a first-class user experience for newcomers.

My argument is that it is very easy to make demands, but it takes a lot of effort to be involved and know enough about all of the existing trade-offs and priorities that are being balanced in order for your opinions to have value.

In this thread you are demanding that JuliaHub pay someone to work on VS code. In other threads you have demanded that other things get worked on. Everyone spending time on something that you want is someone not spending time of something else.

As an example, I really wanted to have good command-line executables to be a thing for many years (that’s how a lot of biologists tend to interact with software). Had I been setting development priorities, I would have made what is now being called juliac top of the list.

I would have never looked at things like precompile caching or invalidations or a dozen other things that have measurably improved my life and the life of every other Julia developer better, and may even have been necessary to make juliac as good as it’s going to be. Because I don’t join triage calls or spend a lot of time developing the core language, I don’t think my opinions have weight.

When I ask if you’ve volunteered to set priorities for who gets funded for GSoC or whatever else, my point is not that you don’t get to have opinions, it’s that you can get things to move in the direction you want them to, but posting your demands on discourse or zulip is not the way to do that. You don’t get to decide what other people do. You do get to decide what you do.

For sure. I also request diversity and transparency - in fact, months ago I reached out to Avik and someone that volunteers to review small development grants for NumFOCUS asking how the process worked. Had lovely interactions that were very clear and helpful. I encourage you to try it!

19 Likes

A statement is true or false. The statement that the current list of Stewards is diverse is clearly false. You are objecting reality.

These are your words. And that is not the first time that you reply to my comments adding conclusions of your own, assigning them to me.

You clearly don’t dig transparency. Your position in this thread is contributing to the opposite. Instead of supporting comments in favor of transparency, you reply saying that I don’t have the right to ask for more transparency.

Where did I ask for disclosure of company revenue? You are probably so confused with your arguments that you are mixing JuliaHub the company, with the Stewards and Julia Governance.

I certainly speak for colleagues of mine who abandoned the Julia community at this point given the lack of transparency and centralization of decisions at JuliaHub. They felt that the governance model was not really fit with open source, and felt it was too risky to invest on the technology. You may live in a bubble where everything looks perfectly fine, but I have enough evidence that the situation is not ideal.

So predictable. Should we also pay for the compiler? After all, your argument is super strong and makes total sense. A small company in Brazil should be the leading source of financial resources for the Julia ecosystem. Bravo!

You contradict yourself all the time. It is really hard to help improve the status quo when your comments come in the way. You are actively working towards the opposite direction of this goal.

Again, your words. I have nothing more to say about that.

Sorry, I don’t see that at all.

That is my last response to your comments. Your contribution in this thread is in the direction of inertia, where nothing changes for the better.

If you want to be pedantic, the statement says that’s why it was chosen, not what it is. Can you say that the reason it was chosen is different from what it says?

My position in this thread is that you shouldn’t act like a jerk. I don’t think that asking people to be kind, and treat others with a presumption of good faith is a contribution against transparency. I think that making demands to a bunch of volunteers is surefire way to keep them from engaging constructively.

Well,

And

And

I mean,

You’re sure that it’s me who’s confused? All of these quotes are from this thread.

I don’t think everything’s perfectly fine. I think that resources are tight and tough decisions need to be made. I don’t always agree with the decisions being made. But I don’t feel I have a right to demand something different.

If you want to dictate the priorities of compiler development, then yes, of course you should.

Wait, do you mean to say that I don’t have a good perspective on the priorities and resources of your organization? Interesting :thinking:

It is not a contradiction to acknowledge that there are trade-offs. When you say “JuliaHub or NumFOCUS or someone should do X”, you are implicitly arguing they should NOT do Y.

And once again, I am not saying that you can’t ask, or that you can’t argue your point. I have not flagged any of your posts as inappropriate. I am disagreeing with you that your priorities, or mine for that matter, should rule the day. And I object to your constant insinuation that anyone who disagrees with you must have nefarious motives.

12 Likes

Let’s try to keep this thread civil and constructive. If it keeps spiraling off I’ll have to close it.

24 Likes

I am not a native English speaker, but since you do not seem to be close friends, this sounds like an insult.

3 Likes

Edited to “shouldn’t act like…” Not sure if that softens it sufficiently, but probably better for the focus to be on behavior. Thanks for pointing it out.

3 Likes

Back to the topic, I think linting and debugging are hard in Julia because the deep infrastructure for that is still lacking. Macros, reflection and dynamic dispatch mean that just knowing about surface syntax doesn’t get you very far. We know that things like JuliaSyntax are an improvement but that more work in the lower layers is needed (and ongoing). Until that’s done, there’s not really a lot that somebody working on something like the VSCode extension can do to improve the situation. And this work is very specialized, so it’s unlikely someone interested in frontend work can just switch over and improve lowering etc. in the pursuit of that.

15 Likes

Beg your pardon, but this is patently false.

4 Likes

Well, a debugger can certainly help there, but is not the only tool to investigate call flow in an unknown code base. Personally, I rarely use the debugger except if I really need to dig in line by line, see specific local values etc. To get an overview of the call dependencies, I rather like to get a (partial) view of the whole call stack, i.e., without needing to step manually.
In most languages, I miss the wonderful trace facility from Common Lisp which allows to record each call and return of selected functions. My TraceFuns.jl aims to provide a similar tool for Julia and may be worth a try …

10 Likes

If I recall correctly, in a recent podcast appearance, Jeff mentioned that once their current push for AOT-compilation is done, the next big thing he wants to focus on was static analysis / developer tooling.

Obviously these things are always subject to change so who knows what the future holds, but it’s certainly something that’s on his mind.

There’s some fantastic analysis tools already like JET.jl, the main challenge I think is just taking JET’s capabilities and exposing them to a user in an IDE in a convenient way.

15 Likes

The question is really how much static analysis is needed for developer tooling. Most languages rely on some sort of static analysis tool to provide code information and – based on my very high-level and partial understanding – the language server protocol (LSP) is basically text based and requires static analysis via some back-end in order to provide meaningful responses to the IDE. While widely applicable – working for many languages as well as several IDEs – the LSP is somewhat of a minimal common denominator in that respect.
Yet, in dynamic languages with an introspective runtime there is another option, namely to just load the code and then query the runtime objects directly. Especially Smalltalk and Common Lisp are nice examples of this approach and from what I get julia-snail works similarly and gets away with a much simpler back-end compared to LSP as the runtime has done most of the heavy lifting already.

PS: Please correct me, if I misunderstood/-represented anything here as my understanding of the actual implementation of these tools is rather limited.

4 Likes

I particularly noticed that as well, but was (very) sad to notice that the debugger was not considered in that priority.

1 Like

From 59:24 here: https://youtu.be/4CV5SG3OLMw?t=3564

5 Likes

I think @jules nailed it with regard to the Debugger. Tim Holy has mentioned previously that the debugger could step though the typed (and optimized?) Julia IR, and it should be low hanging fruit for speeding up the interpreter, but there’s limited providence information about the code at that point, so it’s really hard to make a good Debugger (had to step over when you don’t know what line you’re on!).

Translating lowering to Julia is a major blocker for better tooling.

2 Likes

Foreword

One of the rare joys of running an open source project is that every few weeks you’ll get a bunch of messages that are variations of “you should really say something here” with just a link to some Twitter, Discourse, GitHub post etc. And with an uncanny degree of consistency, this invariable happens at the most annoying times. One of my most viewed discourse post “On Open Source” (On Open Source) was written on Christmas Eve, sitting in my parents’ living room by the fire place.

The past few weeks have been extremely busy trying to get compiler things in place for 1.12, so today happened to be the first day that I took off completely and decided to go dance Brazilian Zouk all weekend. Anyway, invariably, as I was resting by the side of the dance floor towards the end of the night today, I saw that I been sent that kind of mesage about this thread asking me to say something. I don’t think this particular thread is all that bad as these things go, but some themes that I’ve seen repeatedly for a few weeks (here and elsewhere), so I thought a somewhat extended post was appropriate.

Now, this is quite an extended intro (ahead of an even longer post) before getting to anything substantial and a significantly more personal voice than I usually use in my writing, but I do have a point to make first, which is the following: I’m posting here in my personal capacity as someone who’s been working to make this Julia thing happen for more than a decade now. There are real people behind all these organizations, with grand ambitions, way too few resources, and real feelings. I think brainstorming about ways to improve things, innovate ways to fund open source, etc, is all good, but (without prejudice to whether or not this happened in this particular thread), it is very exhausting for maintainers to keep hearing that they don’t care enough, aren’t working hard enough, aren’t spending enough money, etc. Open source software is a gift. It’s a gift we all give each other and a gift to the world. Yes, there can be politics, economics, and agendas involved, but it’s a gift first and foremost and I think it’s important to for all of us to keep reminding ourselves of that.

Alright, on to the substantive part, there’s a few different topics that keep getting intermixed, but let me try to make a few separate observations and hopefully between them, everything is covered. With respect to some of the governance gripes, I think what I wrote in the “On Open Source” post linked above are still good, so I won’t repeat myself there.

The economics of Julia

The first point I want to make is that there is no organization whose mission in life it is to improve julia for the average julia user. Not MIT or any of the other universities (whose mission is to do research). Not JuliaHub, Pumas, Relational, Beacon, or any of the other companies whose products are built in Julia and employ Julia (core and package) developers. And not even really NumFocus, whose mission is primarily educational and scientific. The second point I want to make is that even the current level of Julia development is expensive. Just counting the people whose primary job it is to work on Julia or core ecosystem packages (again for whatever purpose their organization may need such work), you’re probably looking at $10M a year, easily. And that’s not counting anybody contributing in their free time.

Since I’m sure not everyone knows how these kinds of organizations work, let me briefly expand on that in particular. The first is research organizations. Sometimes people think that there is significant research/grant dollars for work on Julia. However, that’s not the case. Generally you get research grants to solve some problem X and you convince the funding agency that the best way to do X is to spend 10-30% of the grant money making julia some part of Julia better, because then doing X will be so much easier. The nature of X where this work depends on project maturity. Early on it was more things like “make data science better” which obviously translates much more directly to Julia package development. However, as Julia has matured and become widely, doing those kinds of things in Julia is generally considered “not research” anymore. So now, you mostly get the applied science research grants, which translate somewhat less directly. But still, all the work there is in support of whatever science goal the funding is for, not general Julia development. There have in the past been occasional grants for Julia itself (e.g. there was a NASA grant which funded some of the work improving release quality and putting out patch releases), but none are currently active, and they are often small by comparison.

Similar story with the various companies that use Julia such as JuliaHub. I can’t speak for anyone else, and obviously this is not an official JuliaHub statement, but the reality is that Julia itself is not a JuliaHub product. That was a very deliberate choice when we started the company. You wouldn’t want it to be a product. If it was, someone would eventually try to make you pay for it. That’s where all the source available licenses, relicensing controversies, etc. come from. Things there can look great for a while, lots of development, beatiful documentation, developer relations staff, etc., but often when people try to turn on monetization, the project dies. We were very acutely aware of these dynamics and wanted to ensure that the Julia project is strong and independent of the company. But that also meant that we had to figure out something else that could be a product for JuliaHub. It took us a while to get there, but at this point in time, JuliaHub is a company that builds (mostly cloud-based) modeling and simulation products and workflows for various industries (which happen to be written in Julia). I saw a tweet recently where somebody was looking at the JuliaHub employee count and saying that they didn’t see anything intersting enough in Julia to justify that many employees, but that’s the misconception here. JuliaHub’s mission is not to develop Julia. JuliaHub’s mission is to develop its products and because we the founders care about Julia, we happened to set it up in such a way that the only way to do that is for JuliaHub to spend millions of dollars a year supporting Julia and its ecosystem, so the company does that.

Relatedly, sometimes people come to us asking for specific feature improvements. Ironically, over the years, I’ve learned that the more generally useful a feature is, the less people want to pay for it. The reasoning goes “this isn’t specific to me - everybody needs it”. There’s this idea out there that somehow there’s a magic pot of money for things that “the community” needs and that “the community” should pay for. Neither of those things really exist. In particular, if you ask those same pepople to pay for general development you get “but i might not need whatever gets worked on”.

Finally, there’s NumFocus, which is where the donations go. The primary economic activity of NumFocus (with respect to Julia) is the organization of JuliaCon. In some years, there’s some money left over from JuliaCon in addition to donations. These finances are open and you can see them here: Julia Language · Expenses - Open Collective (not fully sure that’s everything, since I’m not involved in any of that, but I believe it’s most of it at least). As you can see there covers various community infrastructure, services, etc. and funds the small development grants, travel grants, etc. But you can also see that the total amount of yearly funding available through NumFocus is less than what even just JuliaHub spends on Julia maintenance and development by about two orders of magnitude. In fact, if NumFocus was actually paying for all Julia community infrastrucutre (CI in particular, which, other than free AWS credits, is mostly paid for by MIT or JuliaHub), there’d probably be no money left at all.

Over the years, various people have asked about setting up a pot of money (either through NumFocus or otherwise) to fund Julia development, but basically everytime it’s been dicussed there wasn’t actually any long-term funding commitments available, people just wanted specific features done for a small amount of money. You can’t fund professional software development that way (you can maybe fund some grants, but even there, who pays for admin, management, review, etc).

On feature prioritization

Given the above realities, there was some discussion of how the people that do get paid to work on Julia prioritize work. The answer is pretty simple. Other than the ordinary bug fixing and release polishing, it’s “whatever the organization mission happens to require at this moment” plus personal annoyances of the people that are doing the day-to-day work. But that’s it.

The people who are getting paid to work on Julia generally work on large Julia code bases, so both of those tend to skew towards the issues that come with scaling julia to such code bases (native code caching, TTFX, juliac, binding invalidation, etc.). If you’re not working on code bases of these sizes, some of that prioritization can seem odd or unnecessary, making it seem that obvious issues are being ignored in favor of some niche thing, but often times issues that seem like corner cases in regular become absolutely debilitating at scale (to give a non-JuliaHub example - see Relational’s work on GC improvements) and thus require prioritization.

What I mean to say here is that there is no master plan for what Julia will look like in two years. There’s various things we know are important and want to do, but there aren’t enough people to do them all, so which ones of them become important you only find out once you’ve gotten through the current round. I can tell you with some confidence what the core Julia developers will be working on the next 3-4 months, have some idea of what might be being worked on for the next year but have absolutely no idea what will be the highest priority next December.

What can be done

Now, however pessimistic all of that sounded, I will actually say that often times funding is not actually the bottleneck - it’s scoping the work, finding the people who can do it, and making it happen. Various people in the community regularly help contributors who need funding for a particular project get that done. If there’s a concrete plan of 1) What needs to be done, 2) Who will do it and 3) What will it cost, it’s very possible that someone might be able to find money for it, whether at a company that uses Julia, finding a way to write it into a grant proposal, getting the person an internship or temporary academic position or finding some other pot of money some where. Not infrequently, there’s something creative that can be done. This is not like a formal offering or anything, but definitely let people (Viral and I do a lot of this, as do Avik and Chris R - or just post on discourse) - if you have a concrete project/person that you want to get funded (or have excess funding that you’d like to spend on getting something useful done in Julia - we’ll happily take referrals for excess grant money or left over research budgets ;). Obviously I can’t promise anything here, but certainly if nobody knows about it, the chance it’ll happen is 0.

Conclusion

I think all that to say. We’ve been doing this for a while now. I think compared to a lot of other projects, we’ve actually done a very good job at funding basic development work. It’s not easy to sustain this kind of investment for more than a decade and it’s taken a lot of (often very underappreciated) work by many, many, people to keep the lights on. But let’s please direct our energy towards actionable plans and discussions (NOTE: Complaints that other people don’t have actionable plans is not itself an actionable plan :wink: ). And finally, and most importantly, in the words of a particularly funky Zouk remix that happened to be playing as I was reading this thread

I’ll be there for you
(Like I’ve been there before)
I’ll be there for you
('Cause you’re there for me too)

65 Likes

Thank you @Keno for sharing your experience and views on open source Julia. You are 100% entitled to speak for the project, company, etc.

For many of us who are not part of the inner circle of decision makers it is good to know that these issues are not being ignored because “everyone is busy with other things”.

Do you have suggestions or an actionable plan to increase diversity in the Stewards list and governance model? How to make sure that the open source community is represented by other people outside the JuliaHub/MIT/… umbrella?

1 Like

Could you explain why that should be favorable for Julia development?

At the end of the day, decisions are made by people. People have different priorities depending on their background. For instance, I come from a developing country where students struggle with graduate education because the undergraduate education system is terrible. Thus, I prioritize developing projects that have a potential to improve basic education and change in poor/developing countries. Can you see how diversity can change decision making that way? Choosing the debugger, vscode, or any other project under limited budget is a function of priorities.

1 Like