I kind of hope that @stevengj decides to go with the JupyterHub solution for his course. That would probably be the single most effective way that JupyterHub ends up working without any issues with julia
Another point if favor of institution wide JupyterHub setups is that students could potentially keep access to it after a course ends and keep using it while they are on campus.
Note that JuliaBox and similar are convenience services. If funding for such a service is a problem, one can always just install Julia on a computer for each user — it is free software, and the whole thing just takes a few minutes.
I don’t understand the problems people have with the price (and here I don’t mean to single out your comment). I understand that it can be a significant amount of money in some contexts (I grew up in an Eastern European country), but an analogy that comes to mind is eating out in a restaurant vs cooking a meal from scratch at home. You get the something to eat in both cases, it’s just that the first one may be more convenient, and one pays extra for that.
The key point in this topic is that providing this convenience service takes hardware and labor, and neither of them is free. Some users will find that it is cheaper to outsource these things, some won’t. Both can be sensible solutions in their place. But in the long run, it is not possible to get the convenience service unless someone pays for it.
I also understand that some people argue that providing a free web platform for Julia can help with spreading the language. But I am sceptical about this too, for the following reason: learning even the basics of Julia takes a few hours, and installing it on a PC takes a few minutes. If the second one is a barrier to entry for someone, surely the first one is too, and to a much larger extent. Julia is not a language that magically shines after 5 minutes of experimentation (quite the opposite, it requires significant investment for the gains to materialize). So if someone is unwilling to even invest the time it takes for a local installation, they may be the kind of person who will be very disappointed with Julia anyway.
My local uni is deploying a JupyterHub instance for use by students, which has not been made public but which I have access to. They have installed a few julia kernels for different julia versions, and it all works nicely.
The only hickups for users are due to the fact that JupyterHub is based on JupyterLab: packages like Interact.jl that haven’t yet caught up with the switch from jupyter notebook to jupyterlab.
It did take the cluster admins some work to figure out that they need to be careful about not leaking global/central JULIA_DEPOT paths into the depot paths of user sessions, so that when users add packages those get installed in folders they are privy to. It was mostly smooth sailing after that from what I can tell.
Did anyone read this blog post about the struggle of open source within academcy and CoCalc? Makes me want to support Cocalc. I had a spin of their Julia notebook and it has DataFrames and Plots pre-installed. It’s a bit slow but it’s the unpaid tier.
I saw it pop up on slack. Since this conversation originally started I’ve discovered a lot of different ways to make code interactive online. It seems like an increasingly saturated market. I wonder how important it will be to have JuliaBox as these services continue to grow.
I appreciate the need to keep JuliaBox financially viable. However, for academics trying to introduce Julia to students, the current subscription model will mean that we will have to remove our coding courses that rely on JuliaBox, and this means that lots of students will forgo an introduction to Julia.
What about providing 100 hrs free per year, then some kind of pay-as-you-go option thereafter, e.g. $7 for an additional 100 hrs.
This subscription model would not preclude those of us who do not receive financial support to run our courses and continue to introduce students to Julia.