RFC: Add Julia Language support

[glennmoy]

trafficstars

Why are these changes needed?

We believe we have implemented all the necessary features to the CoreWorker libraries to support Julia language integration and we have successfully used the Ray.jl package to utilise Julia workers locally and on a distributed cluster for a realistic workflow.

We would now like to integrate our changes into the Ray project and are looking for feedback on our implementation and any other necessary modifications we may have missed. With regards to testing, we are considering triggering a workflow on the Ray.jl repo from the ray-project (for a suitable triggering event). Feedback on this would be welcome as well.

Related issue number

Closes #39637

Checks

• [ ] I've signed off every commit(by using the -s flag, i.e., git commit -s) in this PR.
• [x] I've run scripts/format.sh to lint the changes in this PR.
• [ ] I've included any doc changes needed for https://docs.ray.io/en/master/.
  • [ ] I've added any new APIs to the API Reference. For example, if I added a method in Tune, I've added it in doc/source/tune/api/ under the corresponding .rst file.
• [ ] I've made sure the tests are passing. Note that there might be a few flaky tests, see the recent failures at https://flakey-tests.ray.io/
• Testing Strategy
  • [ ] Unit tests
  • [ ] Release tests
  • [ ] This PR is not tested :(
  • [ ] Ray.jl integration tests

[rkooo567]

is this all the changes needed to integrate to https://github.com/beacon-biosignals/Ray.jl?

[jjyao]

That's very impressive. Where are the Julia implementations of Ray APIs like ray.remote, ray.get?

[glennmoy]

is this all the changes needed to integrate to https://github.com/beacon-biosignals/Ray.jl?

We believe so. We've successfully run Ray jobs from a julia driver process that launches julia workers that submits tasks and puts/gets objects in the object store so we don't think there's anything we've left out. But we're open to correction if any experienced ray developers spot that we missed something.

[glennmoy]

That's very impressive. Where are the Julia implementations of Ray APIs like ray.remote, ray.get?

Thanks! The implementations for Ray.put and Ray.get are found in src/object_store.jl while our task submission is currently implemented via submit_task which we plan to clean up / wrap in a Ray-like macro (Ray.@remote) in due course.

[kleinschmidt]

we don't think there's anything we've left out

The one major exception is that we have not attempted any Actor support at this point (it's on our roadmap but wanted to prove out the feasibility with a less ambitious subset of the Ray Core)

[glennmoy]

Rebased against https://github.com/ray-project/ray/commit/68d1feb871d5136a923141ff9e57c751add22eff

[stale[bot]]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

• If you'd like to keep this open, just leave any comment, and the stale label will be removed.

[glennmoy]

not stale - awaiting review from @wuisawesome @ericl @AmeerHajAli @robertnishihara @pcmoritz @raulchen

[anyscalesam]

picking this back up - @glennmoy will have an update on next steps Thursday.

[anyscalesam]

@glennmoy, unfortunately at this time we don't think the Ray code base is modular enough to efficiently maintain an additional lang. Better modularity is in our backlog (which will better enable scenarios such as these) and something we plan on revisiting towards the tail end of this year.

For now we want to stay python/golang/cpp-centric.

That said - if you have a cool use case please feel free to blog about it! We're also working on a new Community Examples Repo as well where I think a Ray on Julia example could fit in as well.

[iamed2]

We're also working on a new Community Examples Repo as well where I think a Ray on Julia example could fit in as well.

As of now (without this PR), the Julia workflow with Ray.jl requires a installing a fork of Ray, which will slowly diverge from official Ray releases. Would you still accept such an example?

[glennmoy]

@glennmoy, unfortunately at this time we don't think the Ray code base is modular enough to efficiently maintain an additional lang. Better modularity is in our backlog (which will better enable scenarios such as these) and something we plan on revisiting towards the tail end of this year.

Hi @anyscalesam , thanks for the feedback.

Just to be clear: we don't expect ray-project developers to provide ongoing support for the JuliaLang integration, that's something we're prepared to do ourselves. We're also happy for it to have "experimental" or "beta" status in the meantime while we build out the Ray.jl client package. The only thing we actually need is for the contents of this PR to be merged into the main fork to support those efforts, as it will help onboard new users who will hear about this at JuliaCon in a few months time.

We're glad to know that multi-language support is in the works, but we're content to have Julia experimentally supported until then and we're hoping there's still a path forward here to achieving that.

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had any activity for 14 days. It will be closed in another 14 days if no further activity occurs. Thank you for your contributions.

You can always ask for help on our discussion forum or Ray's public slack channel.

If you'd like to keep this open, just leave any comment, and the stale label will be removed.