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.
Nothing wrong with CMOS/APA/MLA dashes, I quite like them but usage in LLM prose has ruined it for me. AP dashes are weird, too much horizontal spacing, looks horrible and can really erode typographic color sometimes. "International" Oxford/Cambridge spaced dashes is nicest.
The funny thing is at both extremes, either none or indiscriminate use of dashes like in TFA, is a canary of "human writing".
People (including comments here) often attribute LLM use to prevalence in training data but it is probably far less common in the wild than we are led to believe, the more likely scenario is that whatever text-to-text normalization tools used ended up inserting whatever their idiosyncratic typographic styles were.
The concept of a "userspace package manager" is something I would expect Linux to have figured out twenty years ago. It's ridiculous that the usual situation for non-root users is "you can't install XY but feel free to build from source". Homebrew, Mise and Nix are filling that hole now. (Flatpak is more oriented towards GUI apps, and Snap... exists.)
At the very least, Linux package managers should have some concept of different layers of packages.
For example, there might be layers for “system” (core components), “environment” (display manager, DE, etc), and “user”, each of which are maintained fully separately so they can’t ever step on each others’ toes and break things. Yes, it means there will be some redundancy but for all the trouble and complexity it’s saving I think it’s a worthwhile tradeoff.
Most "immutable" distro flavors do something like this. Back when I ran Aurora, it was rpm-ostree for the core system packages and homebrew in a devbox container for the rest. One incentive for maintaining the layer separation was that rpm-ostree was slow.
I've since moved my desktop box to NixOS, where everything is just flakes, but my mac runs circles around it so it's just there for Steam nowadays.
One of the frustrating limits historically with some of these is that when you're already an unprivileged user it's been difficult or impossible to get to a sandboxed environment to perform hermetic or untrusted builds. So like with nix for example you could do a user install and then builds would build as your user, but if you installed as root, then builds would delegate out properly to nixbld users.
This has gotten better in recent years with user namespaces but it takes time for it to be adopted and achieve parity with what used to be just jumping to a user who can only write to a newly created dir in tmp.
In Debian-Ubuntu it's become a standard pattern to use `curl` or `wget` to add a third-party `deb` repo with keychain integration, because for whatever reason there's still no `apt` command for this obvious scenario. Really grinds my gears.
For whatever reason, nobody seems to use it. It must be a good reason or else they would. [PS: It's because it doesn't add the signing keys and maybe also because it's too associated with Ubuntu.] This, for example, is the official way to add Mozilla's repo:
echo "deb [signed-by=/etc/apt/keyrings/packages.mozilla.org.asc] https://packages.mozilla.org/apt mozilla main" | sudo tee -a /etc/apt/sources.list.d/mozilla.list > /dev/null
And here's Signal's instructions:
# 1. Install our official public software signing key:
wget -O- https://updates.signal.org/desktop/apt/keys.asc | gpg --dearmor > signal-desktop-keyring.gpg; cat signal-desktop-keyring.gpg | sudo tee /usr/share/keyrings/signal-desktop-keyring.gpg > /dev/null
# 2. Add our repository to your list of repositories:
wget -O signal-desktop.sources https://updates.signal.org/static/desktop/apt/signal-desktop.sources; cat signal-desktop.sources | sudo tee /etc/apt/sources.list.d/signal-desktop.sources > /dev/null
# 3. Update your package database and install Signal:
sudo apt update && sudo apt install signal-desktop
I believe apt-add-repository started out as Ubuntu specific for their PPA system, didn't it? It's part of the software-properties-common package.
When using it without a PPA (just giving in the repo URL) it won't add the key by default, so you have to follow it up with the wget -qO- https:/mykey.asc | sudo apt-key add - (<< don't to this, apt-key add will add the key to the global trust)
early days apt-add-repository also didn't support signed-by for the signing keys. Very early on when you added some PPA, it'd add the repo's GPG key to the global keyring, so you were better off not using it anyway.
At least the signal one is using the new DEB822 format, but whomever wrote that missed the fact they could have just embedded the key into the sources file and it would be a very simple command.
I love brew but it was decades of tradition to download source and compile as non-root on shared Unix systems. Not only were the sysadmins skilled at saying no, they were not always available at 2 am, but installing some random code, after editing the Makefile to reflect some oddity of something, was 24x7. And then when we got better offers than shared dial up hosting, it was root or nothing.
To be sure it is ridiculous, but it is also traditional.
I haven't looked much into snap but it seems very heavyweight from the few things I've tried, which downloaded what looked like an entire OS and filled up my disk and RAM. And the fact that you run `snapd` to install a package is just... odd.
There is also the possibility of using Toolbx (formerly [Fedora] Toolbox), distrobox or a container, and the underlying container's package manager. The issue then ends up being about how ergonomic it is to manage a separate guest system (and have to drop into it anytime we wish to use a binary that is unavailable in the host).
Stow only symlinks. That's even one layer below GoboLinux, and GoboLinux is not extremely active either (it is not dead, but kind of semi-dormant, that is sometimes a few changes and improvements are added, then it goes back to hibernation again).
I'm a total noob in this space but I'm using pacman, paru, yay, shelly. Are those different than "userspace package manager" or are these not relevant because it's Arch?
> The concept of a "userspace package manager" is something I would expect Linux to have figured out twenty years ago.
Each one uses their own package manager right?
What I hate is that e. g. debian puts me to conform to their FHS. I want things installed into versioned AppDirs. GoboLinux allows that; NixOS to some extent too (though they used hashed directory names). Debian does not allow me to do that. I don't want to conform to what others wrote; I want software that adjusts to my wants.
> Flatpak is more oriented towards GUI apps
Have they not recently added a mandatory systemd dependency? I can't use software that things it must force software I don't need or use onto me.
I am not sure it is recommending more than it is commenting on the current state of developing public-facing APIs in Python.
The downstream users that import the package either have to ignore checking its exported types altogether, manually stub it, or have a subpar development experience to varying degrees.
This is something I saw the other day with some package that provided comprehensive stubs for an untyped library. The .pyi file was littered with comments about quirks from the numerous type checkers (five now).
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.
reply