4 ms·

I love Julia, but I feel two annoyances right now with the ecosystem. Interactive programming seems to be having a schism between Pluto, a reactive notebook li

I love Julia, but I feel two annoyances right now with the ecosystem. Interactive programming seems to be having a schism between Pluto, a reactive notebook like Observable, and Bonito, a more imperative notebook like Jupyter from the creator of plotting library Makie. The other annoyance is that the packaging ecosystem is tied very closely to Github and Gitlab as the only alternative, in an era where Microsoft is killing Github reliability, and many new projects are moving to Tangled (on the AT Protocol network) and Forgejo (with Codeberg as the flagship), which has no packaging support from JuliaHub.

markkitti 18d ago
I'm not sure there is anything tying Julia packaging to Github directly other than that that is where some projects are based. There is some integration with git, but any git host should do.
MrJulia 18d ago
There seems to be some work on GitForge.jl related to improving the compatibility with Forgejo/Codeberg. I bet as Github continues to go downhill we will see more of an effort to improving compatibility with forges. https://github.com/JuliaWeb/GitForge.jl https://github.com/JuliaWeb/GitForge.jl
__rito__ 18d ago
I have always used Jupyter to work in Julia. Beside .jl files, of course. Same habit with Python. The Ju in Jupyter does stand for Julia, you know. Pluto was a meh experience and I didn't keep using it.
a-french-anon 18d ago
The third for me is that LLM usage has exploded for the development of core Julia itself (just look at the PRs).
- ModernMech 18d ago
  Has this caused tangible problems?
- postflopclarity 18d ago
  this is true of pretty much every software project in existence.
ziotom78 18d ago
I would add the loose definition of interfaces, because it is hard to tell if you have implemented everything or not. (The compiler does not check, you have to write extensive tests.) It's one of the reasons why I am using Julia only for small personal projects but not for larger codebases.
- postflopclarity 18d ago
  I tend to agree, and unfortunately unlike some of its other more highly-prioritized development areas, this is one deficiency that the language is making very slow (or zero) progress on
  - kelipso 17d ago
    It’s funny, it’s actually issue number 5 in the julia github, so lots of history. I am guessing, but in addition to it being difficult to pick a solution, it’s probably because once they pick a solution, they can’t take it back and they wanted that flexibility. And as time went on ad hoc solutions and SimpleTraits became popular, and the calculus becomes how much they want to disrupt the current code to the potential benefits of the solution.
andyferris 18d ago
The package system typically uses a git URL and tree hash to identify a package version. It supports private registries. Is it really tied to github or is that just the path documented in tutorials?
- eigenspace 18d ago
  The only thing that really favours github is the package registrator bot, but that's pretty easy to port to another platform if desired (one can also just make manual registration PRs)

markkitti 18d ago

I'm not sure there is anything tying Julia packaging to Github directly other than that that is where some projects are based. There is some integration with git, but any git host should do.

MrJulia 18d ago

There seems to be some work on GitForge.jl related to improving the compatibility with Forgejo/Codeberg. I bet as Github continues to go downhill we will see more of an effort to improving compatibility with forges. https://github.com/JuliaWeb/GitForge.jl https://github.com/JuliaWeb/GitForge.jl

__rito__ 18d ago

I have always used Jupyter to work in Julia. Beside .jl files, of course. Same habit with Python. The Ju in Jupyter does stand for Julia, you know. Pluto was a meh experience and I didn't keep using it.

a-french-anon 18d ago

The third for me is that LLM usage has exploded for the development of core Julia itself (just look at the PRs).

ModernMech 18d ago
Has this caused tangible problems?
postflopclarity 18d ago
this is true of pretty much every software project in existence.

ziotom78 18d ago

I would add the loose definition of interfaces, because it is hard to tell if you have implemented everything or not. (The compiler does not check, you have to write extensive tests.) It's one of the reasons why I am using Julia only for small personal projects but not for larger codebases.

postflopclarity 18d ago
I tend to agree, and unfortunately unlike some of its other more highly-prioritized development areas, this is one deficiency that the language is making very slow (or zero) progress on
- kelipso 17d ago
  It’s funny, it’s actually issue number 5 in the julia github, so lots of history. I am guessing, but in addition to it being difficult to pick a solution, it’s probably because once they pick a solution, they can’t take it back and they wanted that flexibility. And as time went on ad hoc solutions and SimpleTraits became popular, and the calculus becomes how much they want to disrupt the current code to the potential benefits of the solution.

andyferris 18d ago

The package system typically uses a git URL and tree hash to identify a package version. It supports private registries. Is it really tied to github or is that just the path documented in tutorials?

eigenspace 18d ago
The only thing that really favours github is the package registrator bot, but that's pretty easy to port to another platform if desired (one can also just make manual registration PRs)