6 ms·

Julia 1.12 highlights

194 points by pella 1y ago

alhirzel 1y ago
Has anyone tried the `--trim` option? I wonder how well it works in "real life".
- pavon 1y ago
  I've tried it on some of my julia code. The lack of support for dynamic dispatch severely limits the use of existing libraries. I spent a couple days pruning out dependencies that caused problems, before hitting some that I decided would be more effort to re-implement than I wanted to spend. So for now we will continue rewriting code that needs to run on small systems rather than deploy the entire julia environment, but I am excited about the progress that has been made in creating standalone executables, and can't wait to see what the next release holds.
- postflopclarity 1y ago
  it works well --- IF your code is already written in a manner amenable to static analysis. if your coding style is highly dynamic it will probably be difficult to use this feature for the time being (although UX should of course improve over time)
  - ChrisRackauckas 1y ago
    v1.13 already has a good number of improvements to trim in the cases which are less analyzable, but even then I think the best thing for the package ecosystem is to start to become really good for trim, JETLS, etc. through statically checking things.
- ChrisRackauckas 1y ago
  We use it for binary deployments via building simulations into the FMI standard (i.e. building FMUs) https://fmi-standard.org/ https://fmi-standard.org/. We still need to get libraries updated for getting the smallest possible trim when using the more computationally difficult implicit methods, but at least the stack is matured for simple methods like explicit RK and Rosenbrock-type solvers already. For folks interested in --trim on SciML, the PR to watch is https://github.com/SciML/NonlinearSolve.jl/pull/665 https://github.com/SciML/NonlinearSolve.jl/pull/665 which is currently held up by https://github.com/SciML/SciMLBase.jl/pull/1074 https://github.com/SciML/SciMLBase.jl/pull/1074 which is the last remaining nugget to get the vast majority of the SciML solver set trimming well. So hopefully very soon for anyone interested in this part of the world. Note that does not include inverse problems in the binary as part of small trim. But all of this is more about maturing the ecosystem to be more amenable to static compilation and analysis. The whole SciML stack had an initiative starting at the beginning of this summer to add JET.jl testing for type inference everywhere and enforcing this to pass as part of standard unit tests, and using AllocCheck.jl for static allocation-free testing of inner solver loops. With this we have been growing the surface of tools that have static and real-time guarantees. Not done yet, some had to be marked as `@test_broken` for having some branch that can allocate if condition number hits a numerical fallback and such, but generally it's getting locked down. Think of it as "prototype in Julia, deploy in Rust", except instead of re-writing into Rust we're just locking down the behavior with incrementally enforcing the package internals to satisfy more and more static guarantees.
jakobnissen 1y ago
So much goodness in this release. Struct redefinition combined with Revise.jl makes development much smoother. Package apps are also an amazing (and long awaited) feature! I can't wait to try out trimming and see how well it actually works in its current experimental instantiation.
clickety_clack 1y ago
I wish a) that I was a Julia programmer and b) that Julia had taken off instead of python for ML. I’m always jealous when I scan the docs.
- culi 1y ago
  Python predates Julia by 3 decades. In many ways Julia is a response to Python's shortcomings. Julia could've never taken off "instead of" python but it clearly hopes to become the mature and more performant alternative eventually
  - williamstein 1y ago
    Some small additional details: 23 years not 30. Also, I think Julia was started as much in response to Octave/Matlab’s shortcomings. I don’t know if it is written down, but I was told a big impetus was that Edelman had just sold his star-p company to Microsoft, and star-p was based around octave/matlab. - https://julialang.org/blog/2012/02/why-we-created-julia/ https://julialang.org/blog/2012/02/why-we-created-julia/
    - culi 1y ago
      Thanks for the corrections/added context and the fun link. The whole blog post feels like an attempt to name-drop as many related languages as possible > We want a language that's open source, with a liberal license. We want the speed of C with the dynamism of Ruby. We want a language that's homoiconic, with true macros like Lisp, but with obvious, familiar mathematical notation like Matlab. We want something as usable for general programming as Python, as easy for statistics as R, as natural for string processing as Perl, as powerful for linear algebra as Matlab, as good at gluing programs together as the shell. Something that is dirt simple to learn, yet keeps the most serious hackers happy. We want it interactive and we want it compiled. (Did we mention it should be as fast as C?). While we're being demanding, we want something that provides the distributed power of Hadoop — without the kilobytes of boilerplate Java and XML > We are power Matlab users. Some of us are Lisp hackers. Some are Pythonistas, others Rubyists, still others Perl hackers. There are those of us who used Mathematica before we could grow facial hair. There are those who still can't grow facial hair. We've generated more R plots than any sane person should. C is our desert island programming language.
doctoboggan 1y ago
How's the Julia ecosystem these days? I used it for a couple of years in the early days (2013-2016ish) and things initially felt like they were going somewhere, but since then I haven't seen it make much inroads. Any thoughts from someone more plugged in to the community today?
- pjmlp 1y ago
  Going well, regardless of the regular doom and gloom comments on HN. https://juliahub.com/case-studies https://juliahub.com/case-studies
  - doctoboggan 1y ago
    One of those case studies is me at my former company. We ended up moving away from Julia
    - pjmlp 1y ago
      Because of Julia flaws, or management decisions completely unrelated to the tooling?
      - doctoboggan 1y ago
        We were a startup and I was the "management", but it was mostly for HR reasons. The original dev who convinced me to try Julia ended up leaving, and when we pivoted to a new niche that required a rethinking of the codebase, we took the opportunity to re-write in C# (mostly because a we _needed_ C# to develop a plugin, and it would simplify things if everything was C#).
        pjmlp 1y ago
        Thanks for the clarification.
    - deleted 1y ago
      [deleted]
cyberax 1y ago
I think Julia missed the boat with Python totally dominating the AI area. Which is a shame, because now Python has all the same problems with the long startup time. On my computer, it takes almost 15 seconds just to import all the machine-learning libraries. And I have to do that on every app relaunch.
- csvance 1y ago
  Waiting 15+ seconds to test small changes to my PyTorch training code on NFS is rather annoying. I know there are ways to work around it, but sometimes I wish we could have a training workflow similar to how Revise works. Make changes to the code, Revise patches it, then run it via a REPL on the main node. Not sure if Revise actually works in a distributed context, but that would be amazing if it did. No need to start/fork a million new Python processes every single time. Of course I would also rather be doing all of the above in Julia instead of Python ;)
  - andyferris 1y ago
    Revise can work on your server for hot reloading if you need it - you copy your new code files in place over the old ones. Of course there are caveats - it won't update actively running code, but if your code it's structured reasonably and you are aware of Revise's API and the very basics of Julia's world age you can do it pretty easily IME.
sundarurfriend 1y ago
> For example, the all-inference benchmarks improve by about 10%, an LLVM-heavy workload shows a similar ~10% gain, and building corecompiler.ji improves by 13–16% with BOLT. When combined with PGO and LTO, total improvements of up to ~23% have been observed. > To build a BOLT-optimized Julia, run the following commands Is BOLT the default build (eg. fetched by juliaup) on the supported Linux x86_64 and aarch64? I'm assuming not, based on the wording here, but I'm interested in what the blocker is and whether there's plans to make it part of the default build process. Is it considered as yet immature? Are there other downsides to it than the harmless warnings the post mentions?
- adgjlsfhk1 1y ago
  BOLT isn't on by default. The main problem is that no one has tested it much (because you can only get it by building your own Julia). We should try distributing BOLT by default. It should just work...
  - sundarurfriend 1y ago
    Juliaup can now install PR builds IIRC, so having someone make a PR that just changes the Makefile to do this BOLT based build would be an option too. Less potentially disruptive than making it the default straight off, while still being much more convenient to the user than having to do custom compilation.
    - postflopclarity 1y ago
      PR builds don't work on macos unfortunately.
      - sundarurfriend 1y ago
        These BOLT builds are Linux-specific anyway, so that doesn't matter in this case.
doppioandante 1y ago
Being able to redefine structs is what I always wanted when prototyping using Revise.jl :) great to have it
Archit3ch 1y ago
This is it. Anyone who's anyone has been waiting for the 1.12 release with the (admittedly experimental) juliac compiler with the --trim feature. This will allow you to create small, redistributable binaries.
- ModernMech 1y ago
  How small are we talking?
  - adgjlsfhk1 1y ago
    ~1MB for hello world (almost all of which is runtime), fairly complicated simulations in ~50 MB (solving 500 state ODEs with implicit solvers)
- wolvesechoes 1y ago
  If it is experimental it doesn't allow to create small, redistributable binaries, but allows to hope it will create such binaries. Though it is quite a progress after years of insisting that this additional package PackageCompiler.jl is all you need.
  - Archit3ch 1y ago
    Honest take: yes, it's not ready. When I tried it, the generated binary crashed. For what it's worth, I am able to generate a non-small (>1 GiB) binary with 1.11 that runs on other people's machines. Not shipping in production, but it could be if you're willing to put in the effort. So in a sense, PackageCompiler.jl is all you need. ;)
- pepa65 1y ago
  Very hard to find out how to even get a `juliac` binary unfortunately...
  - Archit3ch 1y ago
    Disclaimer: this is early, experimental, subject to change, etc. Notably, there are reports that it doesn't work in Windows. It works here on Mac, but YMMV. 1) Install juliaup following the instructions for your platform from julialang.org 2) Install julia 1.12 with `juliaup add 1.12` and switch to it `juliaup default 1.12`. 3) Start a standard julia 1.12 REPL with `julia --project=.` This is the "Outer" project that will do the compiling (PackageCompiler.jl terminology, might not be necessary now that juliac can run from the command line). 4) Install juliac with `] app add JuliaC`. The ']' character opens the package manager. You might need to add Julia's app location to your PATH in .zshrc with `export PATH="/home/ccp/.julia/bin:$PATH"` and restart your shell (I had this already from earlier attempts with 1.12 beta). 5) Create a new project with `] generate AppProject`. This is the "Inner" project that will be compiled. Put the example AppProject code from the julia 1.12 announcement in src/AppProject.jl 6) Run the example command `juliac --output-exe app_test_exe --bundle build --trim=safe --experimental ./AppProject` while in the "Outer" directory. You should be able to run it as in the announcement `./build/bin/app_test_exe`
blindseer 1y ago
I'm excited to see `--trim` finally make it, but it only works when all code from entrypoints are statically inferrable. In any non-toy Julia program that's not going to be the case. Julia sorely needs a static mode and a static analyzer that can check for correctness. It also needs better sum type support and better error messages (static and runtime). In 2020, I thought Julia would be _the_ language to use in 2025. Today I think that won't happen until 2030, if even then. The community is growing too slowly, core packages have extremely few maintainers, and Python and Rust are sucking the air out of the room. This talk at JuliaCon was a good summary of how developers using Rust are so much more productive in Rust than in Julia that they switched away from Julia: https://www.youtube.com/watch?v=gspuMS1hSQo https://www.youtube.com/watch?v=gspuMS1hSQo Which is pretty telling. It takes a overcoming a certain inertia to move from any language. Given all that, outside of depending heavily on DifferentialEquations.jl, I don't know why someone would pick Julia over Python + Rust.
- tagrun 1y ago
  Telling what? Did you actually listen to the talk that you linked to, or read the top comment there by Chris Rackauckas? > Given all that, outside of depending heavily on DifferentialEquations.jl, I don't know why someone would pick Julia over Python + Rust. See his last slide. And no, they didn't replace their Julia use in its entirety with Rust, despite his organization being a Rust shop. Considering Rust as a replacement for Julia makes as much sense to me as to considering C as a replacement for Mathematica; Julia and Mathematica are domain specific (scientific computation) languages, not general systems programming languages. Neither Julia nor Mathematica is a good fit for embedded device programming. I also find it amusing how you criticize Julia while praising Python (which was originally a "toy" scripting language succeeding ABC, but found some accidental "gaps" to fit in historically) within the narrative that you built. > In any non-toy Julia program that's not going to be the case. Why?
  - wolvesechoes 1y ago
    Python has useful and rich ecosystem that grows every day. Julia is mostly pile of broken promises (it neither reads as Python, nor it runs as C, at least not without significant effort required to produce curated benchmarks) and desperate hype generators.
andyferris 1y ago
Wow, there are so many amazing practical improvements in this release. It's better at both interactive use _and_ ahead-of-time compilation use. Workspaces and apps and trimmed binaries are massive - letting it easily do things normally done in other languages. It will be interesting so see what "traditional" desktop software will come out of that (CLI tools? GUI apps?). I am so excited - well done everyone!
__grob 1y ago
This is a fantastic release, been looking forward to --trim since the 2024 JuliaCon presentation. All of the other features look like fantastic QoL additions too - especially redefinition of structs and the introduction of apps. Congrats Julia team!
zahlman 1y ago
Somehow I thought Julia had been around for much longer than this.

194 points by pella 1y ago

alhirzel 1y ago

Has anyone tried the `--trim` option? I wonder how well it works in "real life".

pavon 1y ago
I've tried it on some of my julia code. The lack of support for dynamic dispatch severely limits the use of existing libraries. I spent a couple days pruning out dependencies that caused problems, before hitting some that I decided would be more effort to re-implement than I wanted to spend. So for now we will continue rewriting code that needs to run on small systems rather than deploy the entire julia environment, but I am excited about the progress that has been made in creating standalone executables, and can't wait to see what the next release holds.
postflopclarity 1y ago
it works well --- IF your code is already written in a manner amenable to static analysis. if your coding style is highly dynamic it will probably be difficult to use this feature for the time being (although UX should of course improve over time)
- ChrisRackauckas 1y ago
  v1.13 already has a good number of improvements to trim in the cases which are less analyzable, but even then I think the best thing for the package ecosystem is to start to become really good for trim, JETLS, etc. through statically checking things.
ChrisRackauckas 1y ago
We use it for binary deployments via building simulations into the FMI standard (i.e. building FMUs) https://fmi-standard.org/ https://fmi-standard.org/. We still need to get libraries updated for getting the smallest possible trim when using the more computationally difficult implicit methods, but at least the stack is matured for simple methods like explicit RK and Rosenbrock-type solvers already. For folks interested in --trim on SciML, the PR to watch is https://github.com/SciML/NonlinearSolve.jl/pull/665 https://github.com/SciML/NonlinearSolve.jl/pull/665 which is currently held up by https://github.com/SciML/SciMLBase.jl/pull/1074 https://github.com/SciML/SciMLBase.jl/pull/1074 which is the last remaining nugget to get the vast majority of the SciML solver set trimming well. So hopefully very soon for anyone interested in this part of the world. Note that does not include inverse problems in the binary as part of small trim. But all of this is more about maturing the ecosystem to be more amenable to static compilation and analysis. The whole SciML stack had an initiative starting at the beginning of this summer to add JET.jl testing for type inference everywhere and enforcing this to pass as part of standard unit tests, and using AllocCheck.jl for static allocation-free testing of inner solver loops. With this we have been growing the surface of tools that have static and real-time guarantees. Not done yet, some had to be marked as `@test_broken` for having some branch that can allocate if condition number hits a numerical fallback and such, but generally it's getting locked down. Think of it as "prototype in Julia, deploy in Rust", except instead of re-writing into Rust we're just locking down the behavior with incrementally enforcing the package internals to satisfy more and more static guarantees.

jakobnissen 1y ago

So much goodness in this release. Struct redefinition combined with Revise.jl makes development much smoother. Package apps are also an amazing (and long awaited) feature! I can't wait to try out trimming and see how well it actually works in its current experimental instantiation.

clickety_clack 1y ago

I wish a) that I was a Julia programmer and b) that Julia had taken off instead of python for ML. I’m always jealous when I scan the docs.

culi 1y ago
Python predates Julia by 3 decades. In many ways Julia is a response to Python's shortcomings. Julia could've never taken off "instead of" python but it clearly hopes to become the mature and more performant alternative eventually
- williamstein 1y ago
  Some small additional details: 23 years not 30. Also, I think Julia was started as much in response to Octave/Matlab’s shortcomings. I don’t know if it is written down, but I was told a big impetus was that Edelman had just sold his star-p company to Microsoft, and star-p was based around octave/matlab. - https://julialang.org/blog/2012/02/why-we-created-julia/ https://julialang.org/blog/2012/02/why-we-created-julia/
  - culi 1y ago
    Thanks for the corrections/added context and the fun link. The whole blog post feels like an attempt to name-drop as many related languages as possible > We want a language that's open source, with a liberal license. We want the speed of C with the dynamism of Ruby. We want a language that's homoiconic, with true macros like Lisp, but with obvious, familiar mathematical notation like Matlab. We want something as usable for general programming as Python, as easy for statistics as R, as natural for string processing as Perl, as powerful for linear algebra as Matlab, as good at gluing programs together as the shell. Something that is dirt simple to learn, yet keeps the most serious hackers happy. We want it interactive and we want it compiled. (Did we mention it should be as fast as C?). While we're being demanding, we want something that provides the distributed power of Hadoop — without the kilobytes of boilerplate Java and XML > We are power Matlab users. Some of us are Lisp hackers. Some are Pythonistas, others Rubyists, still others Perl hackers. There are those of us who used Mathematica before we could grow facial hair. There are those who still can't grow facial hair. We've generated more R plots than any sane person should. C is our desert island programming language.

doctoboggan 1y ago

How's the Julia ecosystem these days? I used it for a couple of years in the early days (2013-2016ish) and things initially felt like they were going somewhere, but since then I haven't seen it make much inroads. Any thoughts from someone more plugged in to the community today?

pjmlp 1y ago
Going well, regardless of the regular doom and gloom comments on HN. https://juliahub.com/case-studies https://juliahub.com/case-studies
- doctoboggan 1y ago
  One of those case studies is me at my former company. We ended up moving away from Julia
  - pjmlp 1y ago
    Because of Julia flaws, or management decisions completely unrelated to the tooling?
    - doctoboggan 1y ago
      We were a startup and I was the "management", but it was mostly for HR reasons. The original dev who convinced me to try Julia ended up leaving, and when we pivoted to a new niche that required a rethinking of the codebase, we took the opportunity to re-write in C# (mostly because a we _needed_ C# to develop a plugin, and it would simplify things if everything was C#).
      - pjmlp 1y ago
        Thanks for the clarification.
  - deleted 1y ago
    [deleted]

cyberax 1y ago

I think Julia missed the boat with Python totally dominating the AI area. Which is a shame, because now Python has all the same problems with the long startup time. On my computer, it takes almost 15 seconds just to import all the machine-learning libraries. And I have to do that on every app relaunch.

csvance 1y ago
Waiting 15+ seconds to test small changes to my PyTorch training code on NFS is rather annoying. I know there are ways to work around it, but sometimes I wish we could have a training workflow similar to how Revise works. Make changes to the code, Revise patches it, then run it via a REPL on the main node. Not sure if Revise actually works in a distributed context, but that would be amazing if it did. No need to start/fork a million new Python processes every single time. Of course I would also rather be doing all of the above in Julia instead of Python ;)
- andyferris 1y ago
  Revise can work on your server for hot reloading if you need it - you copy your new code files in place over the old ones. Of course there are caveats - it won't update actively running code, but if your code it's structured reasonably and you are aware of Revise's API and the very basics of Julia's world age you can do it pretty easily IME.

sundarurfriend 1y ago

> For example, the all-inference benchmarks improve by about 10%, an LLVM-heavy workload shows a similar ~10% gain, and building corecompiler.ji improves by 13–16% with BOLT. When combined with PGO and LTO, total improvements of up to ~23% have been observed. > To build a BOLT-optimized Julia, run the following commands Is BOLT the default build (eg. fetched by juliaup) on the supported Linux x86_64 and aarch64? I'm assuming not, based on the wording here, but I'm interested in what the blocker is and whether there's plans to make it part of the default build process. Is it considered as yet immature? Are there other downsides to it than the harmless warnings the post mentions?

adgjlsfhk1 1y ago
BOLT isn't on by default. The main problem is that no one has tested it much (because you can only get it by building your own Julia). We should try distributing BOLT by default. It should just work...
- sundarurfriend 1y ago
  Juliaup can now install PR builds IIRC, so having someone make a PR that just changes the Makefile to do this BOLT based build would be an option too. Less potentially disruptive than making it the default straight off, while still being much more convenient to the user than having to do custom compilation.
  - postflopclarity 1y ago
    PR builds don't work on macos unfortunately.
    - sundarurfriend 1y ago
      These BOLT builds are Linux-specific anyway, so that doesn't matter in this case.

doppioandante 1y ago

Being able to redefine structs is what I always wanted when prototyping using Revise.jl :) great to have it

Archit3ch 1y ago

This is it. Anyone who's anyone has been waiting for the 1.12 release with the (admittedly experimental) juliac compiler with the --trim feature. This will allow you to create small, redistributable binaries.

ModernMech 1y ago
How small are we talking?
- adgjlsfhk1 1y ago
  ~1MB for hello world (almost all of which is runtime), fairly complicated simulations in ~50 MB (solving 500 state ODEs with implicit solvers)
wolvesechoes 1y ago
If it is experimental it doesn't allow to create small, redistributable binaries, but allows to hope it will create such binaries. Though it is quite a progress after years of insisting that this additional package PackageCompiler.jl is all you need.
- Archit3ch 1y ago
  Honest take: yes, it's not ready. When I tried it, the generated binary crashed. For what it's worth, I am able to generate a non-small (>1 GiB) binary with 1.11 that runs on other people's machines. Not shipping in production, but it could be if you're willing to put in the effort. So in a sense, PackageCompiler.jl is all you need. ;)
pepa65 1y ago
Very hard to find out how to even get a `juliac` binary unfortunately...
- Archit3ch 1y ago
  Disclaimer: this is early, experimental, subject to change, etc. Notably, there are reports that it doesn't work in Windows. It works here on Mac, but YMMV. 1) Install juliaup following the instructions for your platform from julialang.org 2) Install julia 1.12 with `juliaup add 1.12` and switch to it `juliaup default 1.12`. 3) Start a standard julia 1.12 REPL with `julia --project=.` This is the "Outer" project that will do the compiling (PackageCompiler.jl terminology, might not be necessary now that juliac can run from the command line). 4) Install juliac with `] app add JuliaC`. The ']' character opens the package manager. You might need to add Julia's app location to your PATH in .zshrc with `export PATH="/home/ccp/.julia/bin:$PATH"` and restart your shell (I had this already from earlier attempts with 1.12 beta). 5) Create a new project with `] generate AppProject`. This is the "Inner" project that will be compiled. Put the example AppProject code from the julia 1.12 announcement in src/AppProject.jl 6) Run the example command `juliac --output-exe app_test_exe --bundle build --trim=safe --experimental ./AppProject` while in the "Outer" directory. You should be able to run it as in the announcement `./build/bin/app_test_exe`

blindseer 1y ago

I'm excited to see `--trim` finally make it, but it only works when all code from entrypoints are statically inferrable. In any non-toy Julia program that's not going to be the case. Julia sorely needs a static mode and a static analyzer that can check for correctness. It also needs better sum type support and better error messages (static and runtime). In 2020, I thought Julia would be _the_ language to use in 2025. Today I think that won't happen until 2030, if even then. The community is growing too slowly, core packages have extremely few maintainers, and Python and Rust are sucking the air out of the room. This talk at JuliaCon was a good summary of how developers using Rust are so much more productive in Rust than in Julia that they switched away from Julia: https://www.youtube.com/watch?v=gspuMS1hSQo https://www.youtube.com/watch?v=gspuMS1hSQo Which is pretty telling. It takes a overcoming a certain inertia to move from any language. Given all that, outside of depending heavily on DifferentialEquations.jl, I don't know why someone would pick Julia over Python + Rust.

tagrun 1y ago
Telling what? Did you actually listen to the talk that you linked to, or read the top comment there by Chris Rackauckas? > Given all that, outside of depending heavily on DifferentialEquations.jl, I don't know why someone would pick Julia over Python + Rust. See his last slide. And no, they didn't replace their Julia use in its entirety with Rust, despite his organization being a Rust shop. Considering Rust as a replacement for Julia makes as much sense to me as to considering C as a replacement for Mathematica; Julia and Mathematica are domain specific (scientific computation) languages, not general systems programming languages. Neither Julia nor Mathematica is a good fit for embedded device programming. I also find it amusing how you criticize Julia while praising Python (which was originally a "toy" scripting language succeeding ABC, but found some accidental "gaps" to fit in historically) within the narrative that you built. > In any non-toy Julia program that's not going to be the case. Why?
- wolvesechoes 1y ago
  Python has useful and rich ecosystem that grows every day. Julia is mostly pile of broken promises (it neither reads as Python, nor it runs as C, at least not without significant effort required to produce curated benchmarks) and desperate hype generators.

andyferris 1y ago

Wow, there are so many amazing practical improvements in this release. It's better at both interactive use _and_ ahead-of-time compilation use. Workspaces and apps and trimmed binaries are massive - letting it easily do things normally done in other languages. It will be interesting so see what "traditional" desktop software will come out of that (CLI tools? GUI apps?). I am so excited - well done everyone!

__grob 1y ago

This is a fantastic release, been looking forward to --trim since the 2024 JuliaCon presentation. All of the other features look like fantastic QoL additions too - especially redefinition of structs and the introduction of apps. Congrats Julia team!

zahlman 1y ago

Somehow I thought Julia had been around for much longer than this.