Requests for comments

[ShalokShalom]

So far as I can tell, has Julia no system to develop the language, akin to RFC’s in other languages.

This has worked superb for Rust, F#, Kotlin, and Python.

Is this intentional, and do you see sense in them, potentially?

[mbauman]

See the CONTRIBUTING.md on how this works:

The Julia community uses GitHub issues to track and discuss problems, feature requests, and pull requests (PR).

Issues and pull requests should have self explanatory titles such that they can be understood from the list of PRs and Issues. i.e. Add {feature} and Fix {bug} are good, Fix #12345. Corrects the bug. is bad.

You can make pull requests for incomplete features to get code review. The convention is to open these a draft PRs and prefix the pull request title with “WIP:” for Work In Progress, or “RFC:” for Request for Comments when work is completed and ready for merging. This will prevent accidental merging of work that is in progress.

Note: These instructions are for adding to or improving functionality in the base library. Before getting started, it can be helpful to discuss the proposed changes or additions on the Julia Discourse forum or in a GitHub issue—it’s possible your proposed change belongs in a package rather than the core language. Also, keep in mind that changing stuff in the base can potentially break a lot of things. Finally, because of the time required to build Julia, note that it’s usually faster to develop your code in stand-alone files, get it working, and then migrate it into the base libraries.

[Sukera]

I’ve recently heard an interesting take on why these projects have this kind of RFC or PEP process - it’s an easy “soft no”. “We’re happy to discuss this, provided you make a convincing case and specify what you want to achieve/fix/have” is such a “soft no”, at least for most big feature requests. If someone can’t even be bothered to spec out exactly what they want, why should they get the attention & mindspace from others to disseminate their idea?

Apologies for the long video, but I think it was somewhere in this discussion:

Oxide and Friends 8/28/2023 -- Open Source Anti-Patterns with Kelsey Hightower

[ShalokShalom]

I think this is true to the extent, that software development generally is full of soft no’s.
And this kind of process simply helps to organize and communicate that.
I like it.

[moble]

@Sukera

I’ve recently heard an interesting take on why these projects have this kind of RFC or PEP process - it’s an easy “soft no”.

I’m mostly familiar with PEPs, and can confidently say that — while it might be true for some — they are absolutely not all for "soft no"s or to “say ‘no’ by saying ‘yes’”; many of them become the de facto standards and documentation for a lot of things in the ecosystem. They are for working out the kinks in complicated issues that affect a lot of users, and those whose issues do get worked out fundamentally shape the language in important ways. Of course, IETF RFCs are the literal standards on which much of the internet is built.

On a related note, I’ll point out juleps, which filled that niche, but haven’t really taken off — I guess because the other options seem to work for the community. To take a current example, the main fiasco is being worked out here on discourse and on the original github PR. Maybe a julep would have worked better, but in its current state, not many users are paying attention to that repo. I think discourse and github make it easier for real users to get involved, and that increased churn allows faster iteration towards better ideas, but also more noise .

[Sukera]

@moble

I’m mostly familiar with PEPs, and can confidently say that — while it might be true for some — they are absolutely not all for "soft no"s or to “say ‘no’ by saying ‘yes’”; many of them become the de facto standards and documentation for a lot of things in the ecosystem.

Of course, an actual PEP or RFC, once written, is a very good starting point for that kind of standardization. That wasn’t my point though - it’s the action of requiring that which is the “soft no”, not the PEP or RFC itself. The argument is that if a feature merits larger discussion, it ought to merit a larger proposal (and how that would fit into the existing language) as well, not just a “I would like X please”, because those kinds of requests very quickly run afoul of hidden assumptions various people participating in the discussion end up making (through no fault of their own - that’s just how communication happens). Clarifying that up front in a PEP or larger RFC or JulEP can make that easier.

@moble

Maybe a julep would have worked better, but in its current state, not many users are paying attention to that repo. I think discourse and github make it easier for real users to get involved, and that increased churn allows faster iteration towards better ideas, but also more noise .

I attribute much of that to the general lack of direction in how feature requests would like to be handled, see e.g. here, here or here. There just isn’t any form of consistency or overlook by anyone, and hence getting a higher maintenance (but presumably much lower signal-to-noise ratio) proposal in the form of a JulEP off the ground is very challenging. We thus arrive at the current situation - feature requests or RFCs or similar go “wherever” and are picked up/commented on by “whomever”, implemented by “anyone willing to spend the time” (only to be then told once a PR is opened that, as implemented, “triage doesn’t like it”. Much of the time spent implementing something larger could be avoided by just talking about the thing ahead of time, and actually planning for where things should go).