1. The language is extremely simple and is consistent.
2. I agree on having to move away from imperative and go for declarative (if the latter was what you had in mind) -- any ideas for a better tool that does that and is just as easy to learn?
3. RE: cobbling together stuff with and around `just` is relatively trivial to fix f.ex. I have my own `just` recipes to bring up the entire set of dev dependencies for the project at hand, and then to tear them down. It's a very small investment and you get a lot of ROI.
4. RE: Nix, nah, if that's your sales pitch for it and against `just` then I'll just strongly disagree. Nix is a mess, has confusing cutesy naming terminology, has a big learning curve and a terrible language. All of that would be fine, mind you, and I could muscle through it easily but the moment I received several cryptic error messages that absolutely did not tell me what I did wrong and I had to go to forums and get yelled at, is the moment I gave up. `just` is simply much easier and I am not worried about not having Nix-like environments for my projects. Docker + compose work very well for this.
Finally, your point about an obscure single command that people forget about in the future applies to literally any and all task runners and dependency managers, Nix included. That's not a valid criticism towards `just` IMO.
1. It's a fine language but I have all kinds of "works on my machine" problems with it because it has no associated dependency manager. Other languages solve this with lockfiles and such, and it's likely that you're already doing that with one of those same languages in the same project. So just... Use the main language for whatever it is.
2. No, nothing's so easy, but you can get more if you're willing to work for it, and I think the juice is worth the squeeze.
3. For runtime state, I find that using just as a wrapper around Tilt or docker-compose or k3d or whatever just hides the perfectly adequate interfaces that those tools have. The wrapper discourages deeper tinkering with those tools. It's not a particularly difficult layer of abstraction to pierce, but it doesn't buy you enough to justify having an additional layer at all.
4. In the case I'm thinking of, the whole team was working happily because they had used a Just recipe to download a file from a different repo, and then somebody removed the recipe, but everyone (except the new guy) had the file from months ago, which worked. Nix wouldn't have let us accidentally get into a broken state and not know it. It would have broken as soon as we removed the derivation for the necessary file. I sent him the file through slack and then he was able to work, and only discovered later how it got there on my machine. That kind of uncertainty leads to expensive problems eventually.
1. I don't follow. I work with Elixir, Golang and Rust and I use their dependency managers just fine. F.ex. I have `just deps` that does `mix deps.get` in Elixir and `go get -u ./... && go mod tidy && go mod vendor` in Golang. Furthermore, `just` does not claim to do dependency management. So what do you mean here?
2. Sure but I am not paid for it. Nobody will look at me with admiration if I delay an important milestone with 2 weeks (or, more likely, 2 years) to invent such a tool. :/ So not sure I get you here either.
3. We're veering into bikeshedding here and I will not argue; use whatever interface works best for you. I personally love having `just up` / `just down` / `just start` / `just stop` for my development dependencies of any project project. No more one big shared Postgres instance that if I screw it up (and homebrew did that a number of times!) I'll have to dig through TimeMachine for DB backups. I wisened up eventually and started making scheduled exhaustive backups of each DB... and then said to myself "forget it" and just started using separate containers for each project. For my work I found wrapping the tools worth it for not having to remember their bespoke full command lines. I standardized my tasks and I can enter almost any directory and run the same `just ...` commands and get what I expect as a result. To me that's valuable. But again, use whatever is convenient for you. No argument from me.
4. I don't disagree here and I am kind of 50/50 because on the one hand this is failure of process + lack of proper dev/ops tooling (f.ex. deleting this or that should raise alarms i.e. every such repository should have CI that makes sure everything important stays in place). On the other hand if Nix or anything else spares you from having to install those guard rails then sure, then it's a good fit for you. For my work and hobbies Nix is a net negative and I gave it more than a fair chance and I had enough of opinionated diva-like tools whose message is "learn everything about me to love me, baby". No thanks. But that's just a single example. Again, if there are tools that spare you from screwing up something accidentally, I usually vote strongly in favor of them.
People like Just when they're the one who is writing the recipes, because those recipes implicitly depend on whatever they have installed at the time of writing so everything is easy, but then other people come to the project and it has a culture of "IDK I just use the Just recipe," except that recipe doesn't work unless you've been around since it was written and have all of the right versions of things. For instance I've got all these errors like:
> This application uses version go1.20 of the source-processing packages but runs version go1.23 of 'go list'. It may fail to process source files that rely on newer language features. If so, rebuild the application using a newer version of Go.
They don't seem to be hurting anything but I'm not really sure how to reason about them since somebody packaged the commands together but didn't specify anything about the environment. The Justfile entry tells me that it's running some script in $FOO_DOWNLOAD_DIR but I've got some sleuthing to do to figure out where that dir actually is and how its contents were populated and what it has to do with `go list`.
This is of course bad practice, but Just is the rug under which it is hidden and made to look like good practice. It's good that Just doesn't claim to manage dependencies, since it doesn't, but this action could instead be a go program in which case go would be handling those dependencies for me.
I don't disagree. Your example is a good demonstration why Nix -- or a much more thorough Justfile -- would be needed.
In my case I also supply the `.tool-versions` file so that only mandates the other dev to have Just and asdf / mise (for installing exactly the right versions of tools).
I also tried having full Dockerized development environment but that proved to be too much of a hassle.
But yep, in your scenario it seems like the other guys did sloppy work. Sadly 99% of everything can be misused by people who don't practice their craft well.
(EDIT: Golang programs should really be made to work with the latest version, all being said and done. Another example of sloppy work, if you don't mind me saying.)
I never get this criticism. Nix is a pretty nice, small, functional programming language and lazy evaluation makes it really powerful (see e.g. using fixed-points for overlays). I wonder if this criticism comes from people who have never done any functional programming?
When I first started with Nix six years ago, the language was one of the things I immediately liked a lot. What I didn't like was the lack of documentation for all the functions, hooks, etc. in nixpkgs, though it certainly got better with time.
I did say I could learn it and I do FP for 8.5 years now. It's not that.
It's the obscure error messages, mostly. And as you said, documentation even to this day leaves stuff to be desired, thought that might be better nowadays, no idea and I don't plan to revisit still.
2. I agree on having to move away from imperative and go for declarative (if the latter was what you had in mind) -- any ideas for a better tool that does that and is just as easy to learn?
3. RE: cobbling together stuff with and around `just` is relatively trivial to fix f.ex. I have my own `just` recipes to bring up the entire set of dev dependencies for the project at hand, and then to tear them down. It's a very small investment and you get a lot of ROI.
4. RE: Nix, nah, if that's your sales pitch for it and against `just` then I'll just strongly disagree. Nix is a mess, has confusing cutesy naming terminology, has a big learning curve and a terrible language. All of that would be fine, mind you, and I could muscle through it easily but the moment I received several cryptic error messages that absolutely did not tell me what I did wrong and I had to go to forums and get yelled at, is the moment I gave up. `just` is simply much easier and I am not worried about not having Nix-like environments for my projects. Docker + compose work very well for this.
Finally, your point about an obscure single command that people forget about in the future applies to literally any and all task runners and dependency managers, Nix included. That's not a valid criticism towards `just` IMO.