5 ms·

I've used Just at a workplace on a project I didn't start. It seemed slightly simpler than make when putting together task dependencies. But I couldn't figure o

I've used Just at a workplace on a project I didn't start. It seemed slightly simpler than make when putting together task dependencies. But I couldn't figure out what justifies using it over make.

qznc 2y ago
The manual lists the reasons why using it over make: https://just.systems/man/en/ https://just.systems/man/en/ The question is if those reasons are convincing to someone. The big advantage of Make is that it is probably already installed.
- erichdongubler 2y ago
  > The big advantage of Make is that it is probably already installed. ...unless you're on Windows, like me!
  - deaddodo 2y ago
    Make is installed on Windows, if you install Microsoft's C/C++ dev stack (typically via installing Visual Studio). They just use nmake instead of GNU make. They also include Cmake these days, as it's the common cross platform option.
    - BeetleB 2y ago
      > if you install Microsoft's C/C++ dev stack (typically via installing Visual Studio). So I have to install this huge dependency just to use make, when my project is in Python? Way easier to install just :-)
      - deaddodo 2y ago
        You wouldn't use GNU Make (the thing that comes for "default" on Linux) with Python either. What a weird way to converse.
        BeetleB 2y ago
        > You wouldn't use GNU Make (the thing that comes for "default" on Linux) with Python either. But people do use Make all the time for Python projects - as a command runner. Pelican projects, for example, come with a Makefile to start the server, publish, etc. The whole point of this submission is that many, many people use Makefiles not for incremental builds, but as a convenient place to store commonly used commands. And just is a better and simpler tool than make for that. If you're on Windows, it's a pain to install make, compared to installing just.
  - ttyprintk 2y ago
    Busybox comes with a vestigial make. I wager git might. Those are both in winget.
- fragmede 2y ago
  What does it offer over bazel?
  - peterldowns 2y ago
    Not making you want to shoot yourself in the head. It does one thing very well, and it has well-written and useful documentation. It literally just runs commands in a convenient way.
    - fragmede 2y ago
      how well does it cache across a build farm?
      - peterldowns 2y ago
        [flagged]
        fragmede 2y ago
        ? I'm trying to understand what this tool is and why I should use it for my next project
        pdimitar 2y ago
        You could have used two minutes to skim the top of the README. Not all projects make you want to commit suicide. :)
      - pdimitar 2y ago
        Did you miss the part that says "it just runs commands in a convenient way" and "it is not a build system"?
  - 12_throw_away 2y ago
    It's not a build system, it's a command runner, it is for different use cases
- hgs3 2y ago
  The manual states that "just is a command runner, not a build system," and mentions "no need for .PHONY recipes!" This seems to suggest that there's no way to prevent Just from rebuilding targets, even if they are up-to-date. For me, one of the key advantages of using Make is its support for incremental builds, which is a major distinction from using a plain shell script to run some commands.
  - klabb3 2y ago
    Maybe it’s the stacks I’m using, but I’ve always had incremental happen with language-native tooling like `go` or `cargo`. So for me at least, having lazy eval features like that would be an unnecessary increase in scope and complexity. With Just, I can just throw together different commands and it just works cross platform. I love it. I much prefer that than the other way, ie letting language tooling become command runners (looking at you npm). That’s the worst of both worlds.
    - hgs3 2y ago
      > I’ve always had incremental happen with language-native tooling like `go` or `cargo` That makes sense, but for me, Make is incredibly useful for incremental file processing outside of programming. I've written tiny Makefiles that use glob patterns to batch-convert thousands of SVGs into PNGs and WebPs, but only for the modified SVG files. I've used Make to batch-convert modified LaTeX files to PDFs and render modified Blender projects into WebM videos for the web. Rendering videos is very time-consuming, so only rendering modified video files is a huge win.
  - guipsp 2y ago
    If you need incrementalism, Just is not for you.
  - pdimitar 2y ago
    The programming languages that I use don't need to be told to not rebuild from scratch so yours is a pretty strange argument.
  - BeetleB 2y ago
- badsectoracula 2y ago
  > You can disable this behavior for specific targets using make’s built-in .PHONY target name, but the syntax is verbose and can be hard to remember. I think this is overstating things a bit. I first read `.PHONY` in a Makefile while i was a teenager and i figured out what it does just by looking at it in practice. Makefiles do have some weirdness (e.g. tab being part of the syntax) but `.PHONY` is not one of them.
BeetleB 2y ago
Having recipes just for Windows/Linux. Being able to write your recipes in another language. Not having to be in the directory where the Makefile resides. Being able to call a recipe after the current recipe with && syntax. Overall lower mental burden than make. make is very complex. just is very simple. If you know neither of the two, you'll get going much faster with just.
nucleardog 2y ago
make is a build system and has a lot of complexity in it to make it optimal (or at least attempt to) for that use case. just is a "command runner" and functionally the equivalent of packing up a folder full of short scripts into a single file with a little bit of sugar on top. (E.g., by default every script is executed with the CWD being the folder the justfile is in so you don't need to go search for that stackoverflow answer about getting the script's folder and paste that in the top of every script.) If you use just as a build system, you're going to end up reimplementing half of make. If you try and use make as a command runner, you end up fighting it in many ways because you're not "building" things. I've generally found the most value in just in situations where shell is a good way to implement whatever I"m doing but it's grown large enough that it could benefit from some greater organization.
- 12_throw_away 2y ago
  > search for that stackoverflow answer about getting the script's folder and paste that in the top of every script Ah, a fellow Person of Culture.
clintonc 2y ago
For me, it's a fit-for-purpose issue. Make is great when you're creating artifacts and want to rebuild based on changes. Just is a task runner, so while there's a notion of dependent tasks, there's no notion of dependent artifacts. If you're using a lot of .PHONY targets in a Makefile, you're mostly using it as a task runner -- it works, but it's not ergonomic. I like that just will search upward for the nearest justfile, and run the command with its directory as the working directory (optional -- https://just.systems/man/en/attributes.html https://just.systems/man/en/attributes.html -- with fallback available -- https://just.systems/man/en/fallback-to-parent-justfiles.html https://just.systems/man/en/fallback-to-parent-justfiles.htm...). For example, I might use something like `just devserver` or `just testfe` to trigger commands, or `just upload` to push some assets -- these commands work from anywhere within the project. My life wouldn't be that different if I just had to use Make (and I still use Make for some tasks), but I like having a language-agnostic, more ergonomic task runner.
- peterldowns 2y ago
  As a heavy Just user, I agree with all of this — great answer.
- nrclark 2y ago
  Just a quick note for interested readers: you don't need to explicitly mark things as .PHONY in make, unless your Makefile lives next to files/folders with the same name as your targets. So unless you had some file called "install" in the same folder, you wouldn't need to have something like ".PHONY: install".
  - vbezhenar 2y ago
    That's the right thing to do, so you should. Relying on implicit condition of specific file missing in current directory is very wrong IMO.
metaltyphoon 2y ago
The moment you need to build the same software on windows its already justified IMO
richie_adler 2y ago
For me is not needing to chain a lot of commands with && to ensure that it fails with the first command that fails. With just, if one of the commands of the recipe fails, it stops.

I've used Just at a workplace on a project I didn't start. It seemed slightly simpler than make when putting together task dependencies. But I couldn't figure out what justifies using it over make.

qznc 2y ago

The manual lists the reasons why using it over make: https://just.systems/man/en/ https://just.systems/man/en/ The question is if those reasons are convincing to someone. The big advantage of Make is that it is probably already installed.

erichdongubler 2y ago
> The big advantage of Make is that it is probably already installed. ...unless you're on Windows, like me!
- deaddodo 2y ago
  Make is installed on Windows, if you install Microsoft's C/C++ dev stack (typically via installing Visual Studio). They just use nmake instead of GNU make. They also include Cmake these days, as it's the common cross platform option.
  - BeetleB 2y ago
    > if you install Microsoft's C/C++ dev stack (typically via installing Visual Studio). So I have to install this huge dependency just to use make, when my project is in Python? Way easier to install just :-)
    - deaddodo 2y ago
      You wouldn't use GNU Make (the thing that comes for "default" on Linux) with Python either. What a weird way to converse.
      - BeetleB 2y ago
        > You wouldn't use GNU Make (the thing that comes for "default" on Linux) with Python either. But people do use Make all the time for Python projects - as a command runner. Pelican projects, for example, come with a Makefile to start the server, publish, etc. The whole point of this submission is that many, many people use Makefiles not for incremental builds, but as a convenient place to store commonly used commands. And just is a better and simpler tool than make for that. If you're on Windows, it's a pain to install make, compared to installing just.
- ttyprintk 2y ago
  Busybox comes with a vestigial make. I wager git might. Those are both in winget.
fragmede 2y ago
What does it offer over bazel?
- peterldowns 2y ago
  Not making you want to shoot yourself in the head. It does one thing very well, and it has well-written and useful documentation. It literally just runs commands in a convenient way.
  - fragmede 2y ago
    how well does it cache across a build farm?
    - peterldowns 2y ago
      [flagged]
      - fragmede 2y ago
        ? I'm trying to understand what this tool is and why I should use it for my next project
        pdimitar 2y ago
        You could have used two minutes to skim the top of the README. Not all projects make you want to commit suicide. :)
    - pdimitar 2y ago
      Did you miss the part that says "it just runs commands in a convenient way" and "it is not a build system"?
- 12_throw_away 2y ago
  It's not a build system, it's a command runner, it is for different use cases
hgs3 2y ago
The manual states that "just is a command runner, not a build system," and mentions "no need for .PHONY recipes!" This seems to suggest that there's no way to prevent Just from rebuilding targets, even if they are up-to-date. For me, one of the key advantages of using Make is its support for incremental builds, which is a major distinction from using a plain shell script to run some commands.
- klabb3 2y ago
  Maybe it’s the stacks I’m using, but I’ve always had incremental happen with language-native tooling like `go` or `cargo`. So for me at least, having lazy eval features like that would be an unnecessary increase in scope and complexity. With Just, I can just throw together different commands and it just works cross platform. I love it. I much prefer that than the other way, ie letting language tooling become command runners (looking at you npm). That’s the worst of both worlds.
  - hgs3 2y ago
    > I’ve always had incremental happen with language-native tooling like `go` or `cargo` That makes sense, but for me, Make is incredibly useful for incremental file processing outside of programming. I've written tiny Makefiles that use glob patterns to batch-convert thousands of SVGs into PNGs and WebPs, but only for the modified SVG files. I've used Make to batch-convert modified LaTeX files to PDFs and render modified Blender projects into WebM videos for the web. Rendering videos is very time-consuming, so only rendering modified video files is a huge win.
- guipsp 2y ago
  If you need incrementalism, Just is not for you.
- pdimitar 2y ago
  The programming languages that I use don't need to be told to not rebuild from scratch so yours is a pretty strange argument.
- BeetleB 2y ago
badsectoracula 2y ago
> You can disable this behavior for specific targets using make’s built-in .PHONY target name, but the syntax is verbose and can be hard to remember. I think this is overstating things a bit. I first read `.PHONY` in a Makefile while i was a teenager and i figured out what it does just by looking at it in practice. Makefiles do have some weirdness (e.g. tab being part of the syntax) but `.PHONY` is not one of them.

BeetleB 2y ago

Having recipes just for Windows/Linux. Being able to write your recipes in another language. Not having to be in the directory where the Makefile resides. Being able to call a recipe after the current recipe with && syntax. Overall lower mental burden than make. make is very complex. just is very simple. If you know neither of the two, you'll get going much faster with just.

nucleardog 2y ago

make is a build system and has a lot of complexity in it to make it optimal (or at least attempt to) for that use case. just is a "command runner" and functionally the equivalent of packing up a folder full of short scripts into a single file with a little bit of sugar on top. (E.g., by default every script is executed with the CWD being the folder the justfile is in so you don't need to go search for that stackoverflow answer about getting the script's folder and paste that in the top of every script.) If you use just as a build system, you're going to end up reimplementing half of make. If you try and use make as a command runner, you end up fighting it in many ways because you're not "building" things. I've generally found the most value in just in situations where shell is a good way to implement whatever I"m doing but it's grown large enough that it could benefit from some greater organization.

12_throw_away 2y ago
> search for that stackoverflow answer about getting the script's folder and paste that in the top of every script Ah, a fellow Person of Culture.

clintonc 2y ago

For me, it's a fit-for-purpose issue. Make is great when you're creating artifacts and want to rebuild based on changes. Just is a task runner, so while there's a notion of dependent tasks, there's no notion of dependent artifacts. If you're using a lot of .PHONY targets in a Makefile, you're mostly using it as a task runner -- it works, but it's not ergonomic. I like that just will search upward for the nearest justfile, and run the command with its directory as the working directory (optional -- https://just.systems/man/en/attributes.html https://just.systems/man/en/attributes.html -- with fallback available -- https://just.systems/man/en/fallback-to-parent-justfiles.html https://just.systems/man/en/fallback-to-parent-justfiles.htm...). For example, I might use something like `just devserver` or `just testfe` to trigger commands, or `just upload` to push some assets -- these commands work from anywhere within the project. My life wouldn't be that different if I just had to use Make (and I still use Make for some tasks), but I like having a language-agnostic, more ergonomic task runner.

peterldowns 2y ago
As a heavy Just user, I agree with all of this — great answer.
nrclark 2y ago
Just a quick note for interested readers: you don't need to explicitly mark things as .PHONY in make, unless your Makefile lives next to files/folders with the same name as your targets. So unless you had some file called "install" in the same folder, you wouldn't need to have something like ".PHONY: install".
- vbezhenar 2y ago
  That's the right thing to do, so you should. Relying on implicit condition of specific file missing in current directory is very wrong IMO.

metaltyphoon 2y ago

The moment you need to build the same software on windows its already justified IMO

richie_adler 2y ago

For me is not needing to chain a lot of commands with && to ensure that it fails with the first command that fails. With just, if one of the commands of the recipe fails, it stops.