> 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

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