4 ms·

Julia 1.13 highlights

270 points by eigenspace 22d ago

eigenspace 22d ago
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.
- pjmlp 19d ago
  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.
brudgers 21d ago
Current discussion, https://news.ycombinator.com/item?id=49651384 https://news.ycombinator.com/item?id=49651384
MarkusQ 19d ago
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).
- postflopclarity 19d ago
  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
zuluonezero 19d ago
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.
- mulderc 19d ago
  Same, Julia really does just feel right to me. Which makes sense since I mostly program in R.
- shevy-java 19d ago
  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.
  - throwaway894345 19d ago
    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.
    - jgalt212 19d ago
      RL works better / easier to implement with static typed languages.
      - eigenspace 19d ago
        That's way too broad of a statement. Static typing makes it easier to do RL targeting the sorts of things that static types encode, but it doesn't help at all with things that aren't really type constrained, like for instance writing accurate numerical programs.
rtpg 19d ago
> 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
notthemessiah 19d ago
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 19d 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 19d 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__ 19d 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 19d ago
  The third for me is that LLM usage has exploded for the development of core Julia itself (just look at the PRs).
  - ModernMech 19d ago
    Has this caused tangible problems?
jan_m_savage 19d ago
Julia would have seen more adoption with: --> proper learning resources for beginners, but also for intermediate and advanced users. As of now resources are relatively sparse, compared to what you would find in the Python world. --> a dedicated IDE. Python has several. Otherwise it's a great clean language, faster and more elegant than Python. It's a shame it got stuck in Python's shadow.
- funks_ 19d ago
  We've tried our hand at writing such a resource for Julia's tooling and workflows: https://modernjuliaworkflows.org https://modernjuliaworkflows.org
  - jan_m_savage 18d ago
    This is great. I wonder if anyone would write a 'how to program + CS' book using Julia. Python has a dozen. Julia only has one (Think Julia but this book is just a presentation of syntax and doesn't teach how to program.). Still, for Linear Algebra, Julia is vastly better than Python in all sorts of ways. A recent Julia book by No Starch press is a good step, but this book, too, is not focused on teaching beginners how to write software.
vitorsr 18d ago
All I ever wanted from Julia was great a development experience, but it appears to have never quite gotten there. As a language it has gotten there a long while ago (1.6 LTS series comes to mind). The landscape has changed substantially since then, and now "ergonomics" has unfortunately taken lower priority due to agent-driven development. Nevertheless I think everyone should take a page from Go's book, really, language design now should include the default development workflow.
- eigenspace 18d ago
  What makes you say that ergonomics have taken a lower priority? A lot of the things mentioned in this blogpost are ergonomic things that don't matter for agentic workflows. Maybe it'd help me understand if you said what sort of ergonomic things you find are missing.
  - vitorsr 18d ago
    From memory, the language server appeared to be a second-class citizen, debugging was kind of idiosyncratic, static analysis was poor... but I confess it has been a while since I made a serious effort to use it. I was particularly frustrated by the promises of composability not translating into practice. I was also stricken by the same npm/Rust-like pathological dependency trees where I had to pull 200-plus packages for some function.
    - eigenspace 18d ago
      > From memory, the language server appeared to be a second-class citizen, debugging was kind of idiosyncratic, static analysis was poor. I see. Well, for what it's worth, I think the language server and static analysis have made tremendous progress since the 1.6 days. The regular language server has improved a lot, but there's also the very exciting https://github.com/aviatesk/JETLS.jl https://github.com/aviatesk/JETLS.jl which uses the JET.jl static analysis machinery directly in a language server. JET.jl is super useful, JETLS.jl is maybe not quite ready for prime-time yet, but it's under active development, and is getting pretty close to being ready to be the default choice IMO. There's also the JuliaSyntax and JuliaLowering work that's been happening in the core language itself which have have been improving code providence a lot, which improves static analysis. Regarding debuggers, I can't really comment on that since it's not something I use much, but I do know that JuliaInterpreter.jl has had a lot of improvements, and I assume that those improvements have knocked on to Debugger.jl. > but I confess it has been a while since I made a serious effort to use it. Totally fair! I don't think you are under any obligation to follow this stuff in order to share your experience, but I would at least push back against claiming that this hasn't been a priority. > I was particularly frustrated by the promises of composability not translating into practice. Mhm, this is a hard topic to have an overview of. I think composability has improved since the 1.6 days because we now have package extensions and weak dependencies which allow us to better glue together packages. I think the community has also been doing a better job of trying to identity and fix edge-cases in package composability, but it's hard to say how much this has improved or not (very vibes-based, hard to have data). > I was also stricken by the same npm/Rust-like pathological dependency trees where I had to pull 200-plus packages for some function. Mhm. Not sure I can comment much on this. Personally, I find our package manager quite good, and maybe it's a sign that our package manager is good that there's such a large proliferation of packages that you can pull in, rather than massive monoliths, but I also understand the concern and downsides.
ChristmasTomer 18d ago
[dead]
victorbvieira 18d ago
[flagged]
jibal 18d ago
Using juliac without --trim=safe took over 1 minute to compile a hello world program, and took the same for a second compilation with no source change. Without --trim you can't use dynamic types, which rules out even println without explicitly giving it a Core.stdout argument. I'll come back in a year or so to see if it's become usable.
- jibal 16d ago
  Oops, typo ... that should have been "WITH --trim you can't use dynamic types ..."

270 points by eigenspace 22d ago

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.

pjmlp 19d ago
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.

brudgers 21d ago

Current discussion, https://news.ycombinator.com/item?id=49651384 https://news.ycombinator.com/item?id=49651384

MarkusQ 19d ago

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).

postflopclarity 19d ago
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

zuluonezero 19d ago

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.

mulderc 19d ago
Same, Julia really does just feel right to me. Which makes sense since I mostly program in R.
shevy-java 19d ago
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.
- throwaway894345 19d ago
  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.
  - jgalt212 19d ago
    RL works better / easier to implement with static typed languages.
    - eigenspace 19d ago
      That's way too broad of a statement. Static typing makes it easier to do RL targeting the sorts of things that static types encode, but it doesn't help at all with things that aren't really type constrained, like for instance writing accurate numerical programs.

rtpg 19d ago

> 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

notthemessiah 19d ago

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 19d 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 19d 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__ 19d 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 19d ago
The third for me is that LLM usage has exploded for the development of core Julia itself (just look at the PRs).
- ModernMech 19d ago
  Has this caused tangible problems?

jan_m_savage 19d ago

Julia would have seen more adoption with: --> proper learning resources for beginners, but also for intermediate and advanced users. As of now resources are relatively sparse, compared to what you would find in the Python world. --> a dedicated IDE. Python has several. Otherwise it's a great clean language, faster and more elegant than Python. It's a shame it got stuck in Python's shadow.

funks_ 19d ago
We've tried our hand at writing such a resource for Julia's tooling and workflows: https://modernjuliaworkflows.org https://modernjuliaworkflows.org
- jan_m_savage 18d ago
  This is great. I wonder if anyone would write a 'how to program + CS' book using Julia. Python has a dozen. Julia only has one (Think Julia but this book is just a presentation of syntax and doesn't teach how to program.). Still, for Linear Algebra, Julia is vastly better than Python in all sorts of ways. A recent Julia book by No Starch press is a good step, but this book, too, is not focused on teaching beginners how to write software.

vitorsr 18d ago

All I ever wanted from Julia was great a development experience, but it appears to have never quite gotten there. As a language it has gotten there a long while ago (1.6 LTS series comes to mind). The landscape has changed substantially since then, and now "ergonomics" has unfortunately taken lower priority due to agent-driven development. Nevertheless I think everyone should take a page from Go's book, really, language design now should include the default development workflow.

eigenspace 18d ago
What makes you say that ergonomics have taken a lower priority? A lot of the things mentioned in this blogpost are ergonomic things that don't matter for agentic workflows. Maybe it'd help me understand if you said what sort of ergonomic things you find are missing.
- vitorsr 18d ago
  From memory, the language server appeared to be a second-class citizen, debugging was kind of idiosyncratic, static analysis was poor... but I confess it has been a while since I made a serious effort to use it. I was particularly frustrated by the promises of composability not translating into practice. I was also stricken by the same npm/Rust-like pathological dependency trees where I had to pull 200-plus packages for some function.
  - eigenspace 18d ago
    > From memory, the language server appeared to be a second-class citizen, debugging was kind of idiosyncratic, static analysis was poor. I see. Well, for what it's worth, I think the language server and static analysis have made tremendous progress since the 1.6 days. The regular language server has improved a lot, but there's also the very exciting https://github.com/aviatesk/JETLS.jl https://github.com/aviatesk/JETLS.jl which uses the JET.jl static analysis machinery directly in a language server. JET.jl is super useful, JETLS.jl is maybe not quite ready for prime-time yet, but it's under active development, and is getting pretty close to being ready to be the default choice IMO. There's also the JuliaSyntax and JuliaLowering work that's been happening in the core language itself which have have been improving code providence a lot, which improves static analysis. Regarding debuggers, I can't really comment on that since it's not something I use much, but I do know that JuliaInterpreter.jl has had a lot of improvements, and I assume that those improvements have knocked on to Debugger.jl. > but I confess it has been a while since I made a serious effort to use it. Totally fair! I don't think you are under any obligation to follow this stuff in order to share your experience, but I would at least push back against claiming that this hasn't been a priority. > I was particularly frustrated by the promises of composability not translating into practice. Mhm, this is a hard topic to have an overview of. I think composability has improved since the 1.6 days because we now have package extensions and weak dependencies which allow us to better glue together packages. I think the community has also been doing a better job of trying to identity and fix edge-cases in package composability, but it's hard to say how much this has improved or not (very vibes-based, hard to have data). > I was also stricken by the same npm/Rust-like pathological dependency trees where I had to pull 200-plus packages for some function. Mhm. Not sure I can comment much on this. Personally, I find our package manager quite good, and maybe it's a sign that our package manager is good that there's such a large proliferation of packages that you can pull in, rather than massive monoliths, but I also understand the concern and downsides.

ChristmasTomer 18d ago

[dead]

victorbvieira 18d ago

[flagged]

jibal 18d ago

Using juliac without --trim=safe took over 1 minute to compile a hello world program, and took the same for a second compilation with no source change. Without --trim you can't use dynamic types, which rules out even println without explicitly giving it a Core.stdout argument. I'll come back in a year or so to see if it's become usable.

jibal 16d ago
Oops, typo ... that should have been "WITH --trim you can't use dynamic types ..."