> The feeling of true Vim fluency—one where every keystroke is exact, I never make mistakes, and I’m exploiting every obscure feature—is a fantasy, at least for me.
Perfection is not particularly attainable, or necessarily the point. Nor would it be that fun, I think? It's nice to have some aspect to improve upon. See this Casals quote:
> A reporter asked Casals, "You are 95 and the greatest cellist that ever lived. Why do you still practice six hours a day?" He answered, "Because I think I'm making progress".
Hokusai wrote at the age of 75 that he would only begin to understand the structure of living beings at 100, and hoped to “reach perfection at 110.” He died at 89.
> Although, also, perfection probably doesn’t come from adding options either.
No. However, the first step to _refinement_ is knowing about the thing you want to refine, so in that sense actively engaging and learning about the option lets you know whether to pursue it further.
Not a bad idea, though 'too recent' I think would be the only benchmark - for now, until they get faster at training. OpenAI has thrown away most of their safety team so that shouldn't be a reason anymore to delay model releases "for safety checks".
What would be too obscure or useless, when every new model boasts increasing parameter count (as if having more parameters would make the models better after a certain threshold)?
I appreciate that Aaron is focusing on the practical algorithm/design improvements that could be made to Bundler, vs. prematurely going all in on "rewrite in Rust".
Well. GoboLinux solved that already. Back in 2005.
I never understood the real need for chruby rvm etc... - I manage everything, all programs, in a versioned AppDir manner. (Note: I am not using GoboLinux; I use a modified variant. GoboLinux gave the correct idea though.)
> each program in a GoboLinux system has its own subdirectory tree, where all of its files (including settings specific for that program) may be found. Thus, a program "Foo" has all of its specific files and libraries in /Programs/Foo, under the corresponding version of this program at hand. For example, the commonly known GCC compiler suite version 8.1.0, would reside under the directory /Programs/GCC/8.1.0
I think the question being asked is, if you’re already using mise (which has a built-in task runner) what is the advantage of going with the other one?
> mise can be used as a drop-in replacement for asdf. It supports the same .tool-versions files that you may have used with asdf and can use asdf plugins through the asdf backend.
> It will not, however, reuse existing asdf directories (so you'll need to either reinstall them or move them), and 100% compatibility is not a design goal. That said, if you're coming from asdf-bash (0.15 and below), mise actually has fewer breaking changes than asdf-go (0.16 and above) despite 100% compatibility not being a design goal of mise.
> Casual users coming from asdf have generally found mise to just be a faster, easier to use asdf.
I manage all my programs via ruby in a manner similar to GoboLinux, e. g. versioned AppDirs. So I don't need uv or anything else for this - not that I have anything against uv, it is just not something I need myself. But I agree with you in that there are multiple objectives or goals to be had here; you mention one, Aaron mentioned speed. I think there are many more (I mentioned documentation before too; people in ruby seem to think documentation is not important, or at the least really many think in that way - look at the documentation of rack, it is virtually not existing. I am not going to sift through low quality ruby code for hours to try to figure out what madness drove this or that author to write some horrible-to-read junk of code. A project without good documentation is worthless. Why do ruby developers not learn this lesson?).
I think all of ruby, including the ecosystem as well as how ruby is governed, needs to be considered. In particular with ruby constantly declining and losing user share. That is not good. That should change.
I'm always surprised to hear this, and I want to be clear that I'm not trying to be dismissive in my comment. However, I've not encountered issues while juggling dozens of Ruby projects since around 2011, despite seeing many people's complaints over the years. Ten years ago I was using rvm, and I saw people sharing their issues with it, and listing reasons why rbenv and chruby are better. So I tried those, and my resulting workflow felt basically the same once I got used to the differences.
At this point I've used rbenv, rvm, asdf, mise, and one other whose name isn't coming to mind. Not to mention docker containers, with or without any of those tools.
I don't mean to project any particular complaint onto you, and I'm curious what part of it is infuriating? Each of the version managers I've used has functioned as advertised, and I'm able to get back to work pretty smoothly.
My experience with the ruby ecosystem has been that if you get everything set up correctly all of the environment management tools have worked wonderfully. When you don't have everything set up correctly, they break in ways that is hard to understand for someone not intimately familiar with the ecosystem. It's something that's not at all a problem for someone using ruby as their primary language, and a major source of pain for dabblers and people who just want to run something written in ruby.
That's a fair point. That's why I'm interested to know what is at the core of AlphaSite's complaint.
One challenge, as I see it, is that there are three kinds of Ruby projects that need to take different approaches to the matter, in increasing level of complexity:
(1) Developing a longer-lived, deployed or distributed project. Here you should definitely use both the Gemfile Ruby version and a .ruby-version file. You're normally only targeting one version at a time, but contributors and/or users are very unlikely to somehow accidentally end up using the wrong Ruby version without getting a very obvious notification that they are using the wrong Ruby version. That's annoying to encounter, but not difficult to solve once you know that the concept of a "version manager" exists.
(2) Hacking on your own small project or just banging out a script. You just want to run some Ruby version and get to it. You probably should default to the latest, unless there's some dependency requiring a lower version, and you might not know that until after you've gotten started. The inverse issue might also occur, e.g. you installed Ruby 3.1 a few years ago, you start hacking, and now you want to pull in a gem version that requires Ruby 3.4. You can manage this by putting the Ruby version in your Gemfile, or using a .ruby-version file, or both, but if you're relatively green and just diving in, this might not be on your radar.
(3) Developing a gem. You probably want to test/validate your gem across multiple Ruby versions, and possibly even different versions of your dependencies. You obviously don't want to lock yourself into a single Ruby version, and use of a .ruby-version file is inappropriate. There is tooling to do this, but it takes some learning to be able to utilize.
My belief is that it is worth it for install documentation for category (1) to be a little more explicit about how to get up and running. For category (2), I don't know what the right answer is, but I understand the potential pain points.
What I was most curious about is whether AlphaSite's complaint was with a specific version manager, or the fact that multiple options for version managers exist, or even the need for version managers at all?
For a long time I avoided projects written in Python for this same reason, though they seem to have resolved the issues over time. The only stack these days that gives me pause is nodejs, but for different reasons.
what exactly is your issue? I've been using rvm for a decade(?) without any major pain. Cross-language tools such as mise or asdf also seem to work ok.
I can relate to the "I wish we didn't need a second tool", but it doesn't seem like much of a mess.
I've been using pyenv for a decade before uv and it wasn't a "major pain" either. But compared to uv it was infinitely more complex, because uv manages python versions seamlessly.
If python version changes in an uv-managed project, you don't have to do any extra step, just run "uv sync" as you normally do when you want to install updated dependencies. uv automatically detects it needs a new python, downloads it, re-creates the virtual environment with it and installs the deps all in one command.
And since it's the command which everyone does anytime a dependency update is required, no dev is gonna panic why the app is not working after we merge in some new code which requires newer python cause he missed the python update memo.
Hmmm. Aaron is cool, but also works at Shopify. Neither DHH nor Aaron mentioned anyone at the gem.coop project. I can't help but have mixed feelings here.
I think the underlying issue is much bigger than merely contained on speed. It also has to do with control - both for developers as well as users.
This is also why I think the label "prematurely" is weird, because it attempts to singularize everything down to the speed label. I think the issue is much wider than what is faster. In fact, speed doesn't interest me that much; whether it takes 0.35 seconds or 0.45 seconds or even 1.5 seconds to install a gem, is just so irrelevant to me. But, for instance, high quality documentation - now that is an area where ruby failed in epic ways. Not all projects but many. And then ruby wonders why it is dying? And nobody wants to focus on these issues really. So the issue should really be viewed much larger in scope than "merely" "speed is the issue". I mean ... matz focused on speed in the last 10 years. Ok. Ruby declined. Well, perhaps it is time to focus on other things more - not that people mind a faster ruby, but if a language is dying, then you need to think really hard, come up with a plan, multiple ideas, and push these hard. Rather than, say, purge away old developers and claim nothing happened here and all is well ...
I don't know a lot about Ruby, but I'd wager what its missing is a hero app or framework. Ruby on Rails got folks interested for awhile, but I guess other frameworks won out. What left does it have? What domains does it excel at?
Python has ML. JS has web. C/C++ has performance. Rust is stealing a slice of that thanks to safety.
That probably covers like 99% of things, at least from my world view. There are arguably other better languages but it doesn't much matter if the community all flocks to the well established ones.
There is no single established framework/language for backend Web development. There are many options, all valid, differing in popularity based on their qualities (or sometimes just hype).
Ruby used to be cool around 2010, but it lost to better options. Ruby has strange syntax, and Rails abuses magic, so I guess the viability of TypeScript for development made Ruby less popular.
> Ruby used to be cool around 2010, but it lost to better options.
I'd argue that it lost the cool kidz mindshare but not to better options. People jumped to Node.js because of async but in the end the relevant industry change was the switch to SPA based architectures in the web space. Rails never embraced that approach and hence lost the popularity.
Jump 15 years ahead, and now the Enterprise world is built with React and Angular apps, not with JSPs or Spring MVC apps. Can Rails do a comeback? Who knows, but it's still a bona fide web development stack with terrific productivity gains for those who want to optimize that metric.
IMO I think that the industry will start to move away from React and Angular. These apps take too much developer time for basic functionality, are too slow, and too much of a maintenance burden. The Future^TM is HTMX like functionality, which Rails is very well positioned for with Turbo + Stimulus. I rewrote some pages that had Rails backends with React front ends to Turbo + Stimulus, and the code base size drastically shrank, the performance increased, the maintenance time for features dropped, and it was even more reactive than before.
This is really too bad, as editors should be able to plug and play with AI tooling in the same way that editors <> LSP can plug and play with language tooling.
You can still think of AI as one facet of Graphite's product that you can use or not depending on your work style. Stacked PRs are still a core piece and not going anywhere :)
reply