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.
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.
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.
Over the last three years I have been doing a focussed investigation of a lot of different programming languages and styles (about 38 last count). I was reflecting over the weekend which one I really liked best. Not really for features or functionality or toolset just which one felt 'right'. Julia came out on top as the one language I wanted to play with more and I wish could give a reasoned well justified argument for it but it's really just a feeling. The right mix of intelligent design, power, absence of evangelical idiocy, and a pleasing interface. So nice to get that feeling validated from the random workings of the world and see this release message this morning. Thanks Julia team.
> Over the last three years I have been doing a focussed investigation of a lot of different programming languages and styles
I don't know what your invesitgation covers, but a long time ago (2009) someone [0] did an interesting visual comparison of languages. sadly now it seems it's only available at archive.org [1], but I've often gone back to it, partly because it's such an elegant way of looking at some aspects of different languages.
I liked Julia the first time I tried it years ago. I had some Matlab experience, so it seemed a similar, yet great improvement (no cost! more modern, but lacking some key libs or toolkits). I started programming Commodore BASIC in 1977 on my PET 2001. Then 6502 Assembler/machine language, C, Turbo Pascal, and many more. I have recently gone back to assembler because of AI. I don't miss hand coding assembler or creating macros that don't exist in FASM, but AI allows me to prompt for a terse program, using tried and true asm methods, which I can then audit. Julia has great math and scientific libraries, so my asm stuff isn't in competition with my asm efforts, but I am really enjoying the asm/AI thing for now. Granted this is for my own small projects. Coding is not my main job. I use coding in my other jobs to help me with certain tasks like scheduling, simulations, engineering, and project management. I was playing with the Julia version of cadCAD that was on Python, however, Julia has a lot of other libs that are way better to do dynamic or complexity studies than cadCAD.
Agreed. AI doesn’t level the playing field but turns it more in a winner takes all situation. AI is currently best in Python programming from what I hear and this is because it has seen the most Python code.
Even before AI the trend was moving toward increasingly static languages (JS->TS and even a lot more typed Python). Once you accept the static typing benefits, you start to wonder if you could leverage the constraints to drive performance improvements.
Due to how the release cycle turned out, most new major features got pushed to v1.14, and this one is a rather iterative release focused on making various things faster, quashing bugs, and general polish.
Still though, faster GC, lower startup latency, better interrupt handling, new REPL features, and faster package mangement are all great things. I'm especially happy that the `[sources]` section of a package is now applied recursively when you `add` a non-registered package.
I really like Julia, but I wind up not using it as much as I might otherwise because the startup time kills it for many use cases (though of course it's easily amortized in others).
> Faster GC by skipping image objects during marking
This one in particular I feel like we are inching towards in Python land. I had some really interesting convos from people who really want forking to "just work" and get actual memory savings, because a lot of code is really going to be in memory forever and if we can opt out of refcount work that'd be great
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.
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
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.
Over the last three years I have been doing a focussed investigation of a lot of different programming languages and styles (about 38 last count). I was reflecting over the weekend which one I really liked best. Not really for features or functionality or toolset just which one felt 'right'. Julia came out on top as the one language I wanted to play with more and I wish could give a reasoned well justified argument for it but it's really just a feeling. The right mix of intelligent design, power, absence of evangelical idiocy, and a pleasing interface. So nice to get that feeling validated from the random workings of the world and see this release message this morning. Thanks Julia team.
> Over the last three years I have been doing a focussed investigation of a lot of different programming languages and styles
I don't know what your invesitgation covers, but a long time ago (2009) someone [0] did an interesting visual comparison of languages. sadly now it seems it's only available at archive.org [1], but I've often gone back to it, partly because it's such an elegant way of looking at some aspects of different languages.
0: http://blog.gmarceau.qc.ca 1: https://web.archive.org/web/20100412073334/http://blog.gmarc...
I liked Julia the first time I tried it years ago. I had some Matlab experience, so it seemed a similar, yet great improvement (no cost! more modern, but lacking some key libs or toolkits). I started programming Commodore BASIC in 1977 on my PET 2001. Then 6502 Assembler/machine language, C, Turbo Pascal, and many more. I have recently gone back to assembler because of AI. I don't miss hand coding assembler or creating macros that don't exist in FASM, but AI allows me to prompt for a terse program, using tried and true asm methods, which I can then audit. Julia has great math and scientific libraries, so my asm stuff isn't in competition with my asm efforts, but I am really enjoying the asm/AI thing for now. Granted this is for my own small projects. Coding is not my main job. I use coding in my other jobs to help me with certain tasks like scheduling, simulations, engineering, and project management. I was playing with the Julia version of cadCAD that was on Python, however, Julia has a lot of other libs that are way better to do dynamic or complexity studies than cadCAD.
Same, Julia really does just feel right to me. Which makes sense since I mostly program in R.
To me it seems as if scripting languages have it hard right now, aside from Python.
AI seems to have changed how people find and use new languages. The influx of new people kind of ... died down for many older languages here.
Agreed. AI doesn’t level the playing field but turns it more in a winner takes all situation. AI is currently best in Python programming from what I hear and this is because it has seen the most Python code.
Even before AI the trend was moving toward increasingly static languages (JS->TS and even a lot more typed Python). Once you accept the static typing benefits, you start to wonder if you could leverage the constraints to drive performance improvements.
Due to how the release cycle turned out, most new major features got pushed to v1.14, and this one is a rather iterative release focused on making various things faster, quashing bugs, and general polish.
Still though, faster GC, lower startup latency, better interrupt handling, new REPL features, and faster package mangement are all great things. I'm especially happy that the `[sources]` section of a package is now applied recursively when you `add` a non-registered package.
In Java, C# and C++ land, there are equally features that take several years to finally land.
I think it is perfectly fine that Julia folks take their time as well.
I really like Julia, but I wind up not using it as much as I might otherwise because the startup time kills it for many use cases (though of course it's easily amortized in others).
I think there's a very bright future in this regard :)
1.13 is, to-date, the release with the fastest startup times. and AOT compilation continues to be a serious priority for upcoming releases
Current discussion, https://news.ycombinator.com/item?id=49651384
> Faster GC by skipping image objects during marking
This one in particular I feel like we are inching towards in Python land. I had some really interesting convos from people who really want forking to "just work" and get actual memory savings, because a lot of code is really going to be in memory forever and if we can opt out of refcount work that'd be great