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.
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.
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.
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.
No matter how much code it has “seen” during training, it still makes mistakes during inference. Therefore AI is most well-suited to write in languages with feedback loops that catch mistakes earlier.
Moreover, no matter how good it is at writing Python, Python is not a language you want to use everywhere. “The right tool for the job” still applies in the age of ai.
As you mentioned 38 languages, chances are high that these languages are not all coming from a scientific background, where 1 index based adressing of items is the norm. What is your take in respect to Julia, which is also one offset based?
TBH, that's like whitespace in Python. You can do endless bike shedding about it, but ultimately it's very simple to deal with, and after a few days you never think about it anymore.
One-index based addressing of items was the norm in most of the mathematics or physics books written before WWII, but even then there were exceptions, e.g. for the components of a quadri-vector or a quadri-tensor, i.e. for spatio-temporal vectors and tensors, it was already common to use the indices 0, 1, 2 and 3 for the temporal component and for the 3 spatial components, instead of the indices 1, 2, 3 and 4.
However, this tradition is worth nothing, because before automatic computers the use of decimal numbers instead of binary numbers was also the norm, like also the use of big-endian numbers instead of little-endian numbers. Having to actually implement the computational operations in hardware has revealed that many such traditions were sub-optimal.
Despite the fact that among my programming interests the scientific-technical computational problems have always been on the top and I have started programming with the Fortran language, I have always recognized that using 1-index based array addressing is inferior and any programming language that uses this convention makes a mistake, because this increases the chances of programmer off-by-one errors, by requiring more complex index expressions in many cases.
If anything, my opinion is that programming languages should not support any of such obsolete "norms", but they should go further in replacing them.
For instance, I believe that for integer constants and printed numbers it is still OK to use decimal numbers, because this simplifies mental computations for most humans, who have memorized the multiplication table of decimal numbers and because the conversions between decimal and binary integer numbers are exact, so it does not matter which base is used to display them to humans.
On the other hand, I believe that for floating-point constants and printed numbers it is a mistake to use decimal numbers, instead of using hexadecimal numbers for the significand and decimal numbers only for the exponent (like when printed by printf with the %A or %a conversion specifiers). The reason is that the conversion between floating-point decimal and binary numbers is slow and inexact, introducing rounding errors, without providing any advantage for a human who reads the program text or a table with results.
Comparing hexadecimal floating-point numbers is actually faster and easier for a human reader, than when working with decimal numbers, because the numbers are shorter. Except for comparison, a human will not do any other exact mental computations when reading a set of floating-point values. (At most, when looking at a column of numbers displayed as fixed-point values, a human might add one or a few of the digits, to check that their sum matches the corresponding digits in a displayed total value, but unlike multiplication, addition is almost as simple for hexadecimal numbers as it is for decimal numbers.)
Approximate mental computations are also easier to do with binary floating-point numbers than with decimal floating-point numbers, if you understand how to do them (which is by using logarithms in any mental computations; this is true for both binary and decimal floating-point numbers, because approximate conversions between numbers and their logarithms are very easy to do mentally, as any engineer working with decibels knows). Doing just the simple operations with exponents provides already a better accuracy than for decimal numbers, because an octave is smaller than a decade. For additional accuracy, it is usually enough in mental computations to approximate the floating-point values to 3 points per octave, in which case the approximation error is about the same as when doing approximate mental computations using decibels.
In decades of programming, I have never encountered any case when I would have wanted for my program to contain decimal floating-point constants, or for any result to be printed as a decimal floating-point value, but I have encountered the opposite case, when a programming language annoyed me because it forced the use of decimal floating-point constants, which introduced undesirable rounding errors, so I had to use equivalent integer constants and use something like memcpy to convert them into the desired floating-point numbers.
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 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 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.
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
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.
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)
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.
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).
--> 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.
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.
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.
> 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
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.
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.
> 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 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.
> All I ever wanted from Julia was great a development experience, but it appears to have never quite gotten there.
I feel you. After AOT support (it is improving; slowly, but still) my biggest gripe with Julia is tooling/dev experience. VSCode extension performance is abysmal. Debugging support is delegated to some external package and this debugger has to ship with its own interpreter, and download additional packages. Like, why the hell I need to download few packages just to have a debugger?
I keep track of what is going on and play with it sometimes, but to me Julia will remain a curiosity, even though the language itself is actually fun, with many good ideas (and some bad ones). Also, "two language problem" is not a problem for me.
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...
Similar visualization from the Chapel Lang team here, which shows Julia (and Chapel) in the ideal small-but-fast corner: https://chapel-lang.org//img/clbg/clbg_summary-zoomed-out.jp...
Found a presentation related to that chart, contains more context:
https://chapel-lang.org/chapelcon/2024/chamberlain-clbg.pdf
Previous discussion of this on HN (2009): https://news.ycombinator.com/item?id=634692
Cool. Thanks for sharing this.
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.
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.
RL works better / easier to implement with static typed languages.
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.
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.
No matter how much code it has “seen” during training, it still makes mistakes during inference. Therefore AI is most well-suited to write in languages with feedback loops that catch mistakes earlier.
Moreover, no matter how good it is at writing Python, Python is not a language you want to use everywhere. “The right tool for the job” still applies in the age of ai.
Good point. I had great success with Rust indeed, which can catch errors early.
As you mentioned 38 languages, chances are high that these languages are not all coming from a scientific background, where 1 index based adressing of items is the norm. What is your take in respect to Julia, which is also one offset based?
TBH, that's like whitespace in Python. You can do endless bike shedding about it, but ultimately it's very simple to deal with, and after a few days you never think about it anymore.
As someone into computers since 1986, I have used non 0 indexed adressing in BASIC, Pascal, Ada, Modula-2, and it was perfectly fine.
One-index based addressing of items was the norm in most of the mathematics or physics books written before WWII, but even then there were exceptions, e.g. for the components of a quadri-vector or a quadri-tensor, i.e. for spatio-temporal vectors and tensors, it was already common to use the indices 0, 1, 2 and 3 for the temporal component and for the 3 spatial components, instead of the indices 1, 2, 3 and 4.
However, this tradition is worth nothing, because before automatic computers the use of decimal numbers instead of binary numbers was also the norm, like also the use of big-endian numbers instead of little-endian numbers. Having to actually implement the computational operations in hardware has revealed that many such traditions were sub-optimal.
Despite the fact that among my programming interests the scientific-technical computational problems have always been on the top and I have started programming with the Fortran language, I have always recognized that using 1-index based array addressing is inferior and any programming language that uses this convention makes a mistake, because this increases the chances of programmer off-by-one errors, by requiring more complex index expressions in many cases.
If anything, my opinion is that programming languages should not support any of such obsolete "norms", but they should go further in replacing them.
For instance, I believe that for integer constants and printed numbers it is still OK to use decimal numbers, because this simplifies mental computations for most humans, who have memorized the multiplication table of decimal numbers and because the conversions between decimal and binary integer numbers are exact, so it does not matter which base is used to display them to humans.
On the other hand, I believe that for floating-point constants and printed numbers it is a mistake to use decimal numbers, instead of using hexadecimal numbers for the significand and decimal numbers only for the exponent (like when printed by printf with the %A or %a conversion specifiers). The reason is that the conversion between floating-point decimal and binary numbers is slow and inexact, introducing rounding errors, without providing any advantage for a human who reads the program text or a table with results.
Comparing hexadecimal floating-point numbers is actually faster and easier for a human reader, than when working with decimal numbers, because the numbers are shorter. Except for comparison, a human will not do any other exact mental computations when reading a set of floating-point values. (At most, when looking at a column of numbers displayed as fixed-point values, a human might add one or a few of the digits, to check that their sum matches the corresponding digits in a displayed total value, but unlike multiplication, addition is almost as simple for hexadecimal numbers as it is for decimal numbers.)
Approximate mental computations are also easier to do with binary floating-point numbers than with decimal floating-point numbers, if you understand how to do them (which is by using logarithms in any mental computations; this is true for both binary and decimal floating-point numbers, because approximate conversions between numbers and their logarithms are very easy to do mentally, as any engineer working with decibels knows). Doing just the simple operations with exponents provides already a better accuracy than for decimal numbers, because an octave is smaller than a decade. For additional accuracy, it is usually enough in mental computations to approximate the floating-point values to 3 points per octave, in which case the approximation error is about the same as when doing approximate mental computations using decibels.
In decades of programming, I have never encountered any case when I would have wanted for my program to contain decimal floating-point constants, or for any result to be printed as a decimal floating-point value, but I have encountered the opposite case, when a programming language annoyed me because it forced the use of decimal floating-point constants, which introduced undesirable rounding errors, so I had to use equivalent integer constants and use something like memcpy to convert them into the desired floating-point numbers.
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 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 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.
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
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.
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?
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)
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.
The third for me is that LLM usage has exploded for the development of core Julia itself (just look at the PRs).
Has this caused tangible problems?
this is true of pretty much every software project in existence.
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.
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
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.
We've tried our hand at writing such a resource for Julia's tooling and workflows:
https://modernjuliaworkflows.org
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.
Current discussion, https://news.ycombinator.com/item?id=49651384
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.
Oops, typo ... that should have been "WITH --trim you can't use dynamic types ..."
> 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
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.
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.
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.
> 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 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.
> All I ever wanted from Julia was great a development experience, but it appears to have never quite gotten there.
I feel you. After AOT support (it is improving; slowly, but still) my biggest gripe with Julia is tooling/dev experience. VSCode extension performance is abysmal. Debugging support is delegated to some external package and this debugger has to ship with its own interpreter, and download additional packages. Like, why the hell I need to download few packages just to have a debugger?
I keep track of what is going on and play with it sometimes, but to me Julia will remain a curiosity, even though the language itself is actually fun, with many good ideas (and some bad ones). Also, "two language problem" is not a problem for me.
Try this jetbrains plugin: https://plugins.jetbrains.com/plugin/29356-flexible-julia
[flagged]
[dead]