-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
I used asdf but found it caused a 200ms hit to launching any of the binaries: https://github.com/asdf-vm/asdf/issues/290
Personally that's not something I can live with as these binaries are sometimes launched many times in subprocesses.
> By Ruby, Python and JavaScript hackery I was meaning rvm, venv / pip, and npm. I have the most experience with rvm, and the hackery part comes from the experience when I created a web interface that could instruct the server to do ruby tasks. Turned out that rvm (and also bundler) does a bunch of stuff to the environment of the user, that's sometimes inaccessible, even if you invoke a "login shell" programatically. One of these "hacks" is doing a bunch of stuff when the user navigates to a Ruby project directory with cd, which is when rvm creates or uses the existing virtual env for the project - named is a specific way based on the directory name. I solved this of course but the discovery was quite annoying.
Keeping the "right context" when you do things in different directories with the same shell config is, unfortunately, a problem that I don't think is easy to solve. My preferred approach is to use direnv (https://direnv.net/), but that's not perfect either.
As for rvm, I think that a lot of people at some point discovered that rvm was maybe doing a bit too much (in particular, it would also manage gem sets, something that seems superfluous with Bundler). I think that's a reason why rbenv and chruby emerged as lighter-weight alternatives which are a bit less magic. I haven't seen many people use rvm anymore in recent years.
> Now that I think about it, every single one of the programming ecosystems I used were quite annoying.
That's something I agree with. As a more recent convert to the JVM world (and mostly just for lack of better alternatives), I'm still sometimes annoyed at the IDE-centrism (and UI-centrism, see also sonarqube) in this space. Luckily, things are already better than they were when I learned Java in university and "it runs in my IDE" was the default state of affairs...
Nix will even know which packages it'd need to build locally instead of downloading a prebuilt binary.
You can't do that with other common package managers. You're stuck with whatever the package manager provides you. So if you're not in the happy path, you're out of luck. You'd either have to give up or build from scratch. If you need a bugfix for a particular package, you'd have wait until the fix reaches the package repository. When I was using Ubuntu, that was often until the next major release. None of this stuff is a problem with Nix, which allows for customization with very little effort.
It's easy to learn about Nix if you know where to look for. Nix Pills [1] would be a good start. The core language is the easiest part. It's JSON, but with functions and variables for proper abstraction. The documentation, while imperfect, is quite extensive compared to numerous other high profile open source projects. If the documentation fails you, the Nixpkgs repository [2] is an even more rich source of information. The code is well organized, and I was able to get familiar with writing Nix packages fairly quickly by grepping the codebase. And finally, Nix has a sizable community so you could always ask if you're stuck.
[1]: https://nixos.org/guides/nix-pills/
[2]: https://github.com/NixOS/nixpkgs
https://github.com/asdf-community/asdf-direnv
> asdf version resolution is slow which makes every command execution pay that penalty. asdf reshim is needed for finding new executables, and some tools are not happy with their executables being masked by shims.
> Perform asdf version resolution only once and defer environment loading to direnv.
If you are looking for a language agnostic version manager, the nix package manager [0] might be worth a try. In combination with lorri [1] you will be dropped into a shell with all required development dependencies available, when you enter the project directory. This does not only include the interpreter/compiler versions but also any other dependency you can think of, like specific libraries the project links against (well almost any, it has to be available as a nix expression, best case directly in upstream nixpkgs).
[0]: https://nixos.org/
[1]: https://github.com/nix-community/lorri/
So is asdf good then? I have been using SDKMAN! to install JDKs, but i noticed that Gradle will automatically detect JDKs installed using SDKMAN!, asdf, and Jabba [1], which signals to me that the other two are worth a look. Although now i dig into it, asdf does not have a first-party Java plugin, so the support is through a third-party plugin maintained by three people and a robot [2].
[1] https://docs.gradle.org/current/userguide/toolchains.html#se...
[2] https://github.com/halcyon/asdf-java/graphs/contributors
This is a reasonable point, and something that is being worked on. I definitely think Docker can provide LSP servers as necessary, we're just not quite there. This is something that I'm interested in working on, though I'm not the only one: https://github.com/emacs-lsp/lsp-docker
I agree that the documentation story could be better. I also think it's a great shame that the language isn't statically-typed, so to understand how to use something I have to inspect its source code.
I've found it to be quite flexible though. For example, here's a commit in which I apply a patch to a tool to solve a problem that the derivation hadn't taken into account (and absent a home-manager solution): https://github.com/samhh/dotfiles/commit/867dd3b4d4b3942a0aa...
I like to use eclectica, it's not very popular, but it works for me
https://github.com/markelog/eclectica
If it's Rust, you can use https://github.com/oxalica/rust-overlay to get any version you want very easily without pinning an instance of nixpkgs just for it.
asdf does not allow you to keep three different versions of the same language, so I'm not sure how that compares? It's not super-trivial to do in Nix, but at least you can do it.
asdf is also no different than Nix when it comes to minor/major versions. You're at the mercy of what the plugin does, other than that you have to create your own plugin from scratch or make a fork. Nix has the option to patch things up more easily at least.
The lack of Ruby support instantly rings an alarm for me because CPython (on POSIX) also is not relocatable, but is listed as support. Turns pit Hermit is actually using a third-party build script[1] instead of the official one. While the python-build-standalone project is quite awesome and indeed is useful for a lot of things, it has enough quirks I would recommend against any generic package distributor to advertise as Python for general use. This in turn makes me lose most confidence on Hermit, unfortunately.
Be careful if you’re also interested in Hermit. These kinds of things bit you up way down the road when you least expect them to.
[1] https://github.com/indygreg/python-build-standalone