I don't understand this argument: "it's 47 years old" as a bad thing. If something has been around that long, does it not mean it is proof tested?
The syntax of Taskfile looks more verbose to me than Makefile, which is basically a shell script in disguise. To note also is that you praise Devenv because of it being based on Guix (Guile scheme), while you ditch Makefile which also embeds Guile scheme as the extension language (in latest versions).
Also to note, the opening argument, writing Readme files on how to build and use the software, has nothing to do with Makefiles at all. You could write a simple skeleton codegen that generates a Readme file skeleton or a template with those steps autogenerated in any language preferred, shell included, and run it as a Makefile target.
That is not the argument though. The argument is: After being unhappy with Makefile for years now
As to why being unhappy is probably not because it haven't been proof tested. I get your sentiment but feel the remark is out of place. I thought the rationale for picking other tools was straightforward and motivated.
Though the simplicity of make has been lost and I'm not sure the overhead is worth it. I wouldn't want to be the one introducing taskenv, direnv and derenv to a project.
But it was; one of his arguments. Yes, he opens with the argument that he was unhappy with the Make for years, but he later clarifies why:
> I am still stuck with a tool that (according to Wikipedia) has been written 47 years ago.
You probably haven't read his article to the end? Those were his words I copy-pasted from the blog. So one of the reasons he is unhappy is because Make is 47 years old. For some reason, it stopped to be good enough 20 years ago, according to his opinion.
I can give him that we can always have a better tool, but it is a tautology. Unfortunately, his offered alternative is not better IMO.
Software build has essential complexity. Dealing with peculiarities in config syntax is a mere drop in the vast lake of unhappiness wept from having to deal with build at all. It's the tools that are salient, so folks may perceive that it's the tools at fault and must be reworked, but it isn't really: complexity in build tools is an emergent property of the domain, and any sufficiently developed reinvention will asymptotically correspond to makefiles.
Do we know that taskfile does any better than make on this front? It isn't mentioned in the article. Sounds like taskfile is runs on raw "command line string interpolation" just like good old make.
I thought Nix used as Guix Guile under the hoos, but looked up now, and they seem to use custom language, in which case is it even worse. I should have looked up that before the hand, my bad there, I appologize.
Op complained about that make requires a bunch of extra tools to get running, and suggests another bunch of extra tools, as well as of make DSL which is more or less shell on steroids, but suggests a mix of two different languages instead, and does not even seem to be aware he can use Guile Scheme to extend Make.
It’s proof tested yes. But it still falls over if you put in a space versus a tab, and the error message is cryptic and frustrating to beginners. Make is such a huge impediment to C adoption, long time users have no idea.
Even the fact makefiles have no extension is confusing to beginners. Everything about it screams outdated, idiosyncratic computing artifact and students pick up on that.
> But it still falls over if you put in a space versus a tab
It fails only in a certain part of the script where tab is part of the syntax. It is like saying Python language fails if I add a wrong number of spaces, or replace a space with a tab, since white spaces are part of the Python syntax.
> Even the fact makefiles have no extension is confusing
How is that confusing, the entire filename (makefile) is "the extension" :-)
Put .mk at the end of the file name if that makes you happy and less "outdated" and "idiosyncratic". C/C++ does not require extension either, it is just a convention. Ever seen <vector>, <algorithm>, <iostream> etc?
Sorry for the plug, but I can't help myself everytime I read about task managers to notice you have to learn yet another DSL.
DSL are the plague of our field, for one that is useful like SQL, you have a hundred that turn your life into hell. Make's DSL is already full of gotchas, but templated YAML based DSL are just insanity. They have so many footguns, and so little flexibility and ability to be debugged.
After trying a lot of task runners and builders, I finally settled on doit:
- It makes the simple things simple, and the hard things possible.
- It scales up (you get targets, dependencies, manual scripting, etc), but it also scales down (you can define a simple list of shell commands to run and that's it).
- Instead of a DSL, you have regular Python. Which for all it's faults, is an excellent scripting language. It has great tooling support, and comes with a debugger.
- To avoid people abusing the expressiveness of Python, the default syntax to create tasks encourages a declarative style.
I've been using doit for years, and every single project I introduced it to was improved by it.
Of course, it comes with it's own problems (non python dev can dislike having to install that, and it doesn't yet provide a stand alone executable), but the ROI is way better than the alternatives I tried.
Python is such a massive dependency though, people who code in python rarely realize how big of a barrier it is for people not in that ecosystem. Package management is insane and every project has its own way of dealing with it. Installing python by itself is a chore on many operating systems.
I wish more projects would compile their Python tool into a stand alone executable so that the users wouldn't have to deal with the installation process.
I will at some point write about how to do that with Python, so that the knowledge will more broadly available and maybe the community will grow the habit of doing it.
And it breaks over time. Absolutely terrible choice for makefile. It would be far better to just use bash, even though it would mean coding your own dependecy and update-detecting logic.
I wouldn't write anything in python that I still wanted to work a month later or on even one other system.
It started off with configuration files, but then we needed logic, control flow, or variables; and for some reason nobody goes "ok, maybe we need an actual progamming language now" and instead we've created horrors beyond our comprehension.
Azure Pipelines is the worst I've used: three types of variables, conditional statements return string "True" and "False", and of course it's mostly undebuggable.
I have hopes that one day something like CUElang (https://cuelang.org) will become popular to be the configuration language of everything. Just enough logic to get by, but not turing complete, plus strong typing and embedded schemas.
However, for now there is just a single implementation in GO.
Templated YAML just means that something somebody thought was configuration either wasn't or wasnt under every circumstance. It's not really a problem with YAML.
In most cases I think it's the fault of the creators of the YAML DSL (e.g. ansible) but with CI pipelines people really just should be writing scripts 100% in other languages and wiring them up to events with YAML. I dont have any sympathy for people using them as programming languages.
I'm sure Microsoft is happy to indulge it though because hey, vendor lock-in.
This is the exact reason why I moved to magefiles[0] in my Go projects. I had a semi-working Makefile base I spent days honing years ago, but then I ran into a few walls (can't remember which).
Enter magefiles, I could use the same language in them as I could with my other code and stuff just worked.
No need to apologise, I don't like YAML, I like Python, and I agree: I'd rather have a domain specific library than a DSL anyday.
The best of both worlds is a good programming language that allows expressing domain specific libraries almost as if they were domain specific languages, without going so declarative that people don't know how to script anything anymore.
I don't know if Python/doit really achieved that, but its task definitions seem almost as readable as the YAML, in a real language where I can do anything I want without asking permission. So I would always choose doit over Taskfile.
But a better comparison is between doit and make. I much prefer make's basic syntax, although I dislike newer features which inevitably have stretched the syntax beyond its original simplicity, but conceivably you can achieve something similar to make in a language but as a library rather than a DSL, and it would be immediately friendlier and more powerful than make. Depending on what I was doing I would use doit, but for something simple I've still got make (and it would be easy to convert if desired, in fact I have some projects in mind that could do with this!).
Yes. I said it in another comment as well, but I'm rooting for a solid non turing complete conf language like CUElang (https://cuelang.org) to become popular. For now we can already use it to check and generate regular JSON or YAML, which is a good compat story.
But imagine having this in CI instead of YAML files.
For Pythonistas or people interested in Python, I can't plug the commenter's newsletter enough: it is an absolute treasure trove of good advice for new and old users of Python. They did a whole series on the right way to install and use Python [1]. If you follow their advice you'll never struggle with any of the problems people complain of encountering with Python.
> DSL are the plague of our field, for one that is useful like SQL, you have a hundred that turn your life into hell.
The same can be said about using general purpose programming languages to specify stuff declaratively, but instead of implementation the problems happen in each and every single use of it. It only takes a single user that either does not comply with standards or feels they are particularly clever to mess everything for everyone.
I guess that could work for a Python project, where you already have Python installed. But still you would need to set up a venv or similar to keep your system Python clean. Then you cannot run the tasks without creating that venv or similar. How to create the venv and install all the correct dev dependencies into it? You can't use the task runner yet, because you still need to install that ... Maybe a Makefile?
I have coworkers who use this. They tried to make me use this too. I failed to see the point. It offers no benefits of a build system, no benefits of existing automation tools, comes with "bespoke" syntax and requires installing an extra program to run it.
I have never tested it enough to discover things it does wrong, but given how new and not exactly popular this tool is, I bet there are lots of things it doesn't do right...
So, I have no idea why would anyone want this tool... beside just using one extra infra tool to appear as if you know something others don't (and that's exactly the kind of people who use it at my workplace).
I remember how I promoted Git over a decade ago, and I heard from the lead guy that “SVN does the same” and “there are no benefits of using branches” (he never used them). Please listen to your coworkers and don’t be that guy. Technology moves forward, make it great, but it’s time to move on.
I didn't like the transition from SVN to Git. My biggest problem was the commit numbering. While SVN assigned consecutive numbers to commits, Git assigned hashes.
I still think that most people working with VCS today would've been better off using SVN. Most companies use Git in a centralized way anyways -- they don't need the distributed feature of the system. Most people using Git today don't know how to go back in history and wouldn't be physically able to carry out this task if requested because most Git repositories I've seen in my life were, essentially, write-only, just a glorified rsync.
I needed many years of working in infra to come to terms with Git and become efficient at using it. Most developers using it today will not have a multiple-year rotation in infra position, and are terrible at using the tool.
But this is very different from Taskfile vs Makefile. Git came with many attractive features. Some, perhaps inconvenient or demanding in terms of learning, but it was a genuine new tool that solved a problem other tools at the time didn't (branches were very expensive in SVN, sharding repositories across large distances was very expensive in SVN, and Git solved both).
Taskfile doesn't do anything better than any of the existing tools. It doesn't even promise anything like that... It's just "like make" but worse... so, what's the point exactly?
> Technology moves forward
Oh you sweet summer child... no, it doesn't. Sometimes it moves backwards, sometimes it jumps in place pretending to do useful work... there's no rule to say it should, and the evidence abounds of how this statement isn't true.
And from the response you got you failed at it. Were you promoting it because technology was "moving forward" and it was "time to move on"--whatever that means, instead of its merits? Didnt work for git, certainly won't work for Taskfile.
So, don't be what guy? The idiot that says branches have no benefits? The lesson is that there are dummies on both sides of the table.
Evaluate technology on merit. And, anything that is to dislodge a ubiquitous tool that's been around for 47 years has a high bar to cross.
Because Make is too stable and well documented, because it's just one tool and not 3, because it isn't written in Go and because you don't have to scratch you head at another YAML hell. Because 47 years of proven track record is nothing compared to "modern". Need I go on?
If you think there’s nothing to fix with make, you’re severely mistaken. The differences between GNU Make and BSD Make are for me a big reason to be extra careful when using it. Make also relies a lot on cleverness so it comes with lots of idiosyncrasies (like having to add .PHONY to all the targets not representing files, which in itself proves Make was not thought to be used like we use it). Some basic conventions we use today are also hard to do correctly with a Makefile (using dotenv files for example)
I used Task on a new project and the explicitness of it all was a breath of fresh air. I mean which is clearer between:
BINARY = ./foo
GO_FILES = $(shell find . -type f -name '*.go')
# Rebuild BINARY only if GO_FILES have been modified
$(BINARY): $(GO_FILES)
go build -o $@
.PHONY: build
build: $(BINARY)
some tasks a developer might need to do besides just building the application:
- copying a database from production to local for bug reproduction/fixes
- inserting seed-data into the local database
- creating a migration after changing records
- applying the migration
- rolling back the migration
- running a tool to copy configuration from a keyvault
- running the end to end tests
- generate certificates
- set up an ssh tunnel to a remote server or database
All of these things are part of the development process, and cannot be part of the build system. Each of them has their own commands and tools.
All developers need to easily be able to do these things, without asking help each time, or learning the syntax of each command.
One easy way is to stuff all of them in a task runner with simple aliases. Another could be writing a document that you can copy/paste from. I prefer a task runner, since you can memorize the alias and work from the terminal without looking things up.
Make doesn’t have any builtin —help for the list of user defined targets, and has a slightly wonky bespoke syntax of it’s own. So it’s quite natural to look for something that has those properties.
But Taskfile didn't improve anything about Make? Make has a huge user base, it's battle-tested in many environments, it has a ton of infrastructure around it...
Taskfile brings nothing to the table. It cannot compete with existing automation tools. It doesn't even promise to be better than existing automation tools...
I mean, give me at least some reason to believe it could be better than what I already have... to me it looks like the people who wrote it simply never saw what's already there. Kind of like a university project where students write a simplistic compiler for a subset of C language... It's nice that they tried their hand, but they have a long way before they actually produce something useful.
This is the most real criticism of makefiles I've seen in this thread. There's fixes for it, but it usually involves parsing `--print-data-base` output, which is pretty awkward without reaching for a helper language like python/perl/ruby, and that then reduces portability and the batteries-included stuff that makefiles enjoy. It really does need a fix of some kind in make-core.
Yep, `just` is much more truthful to the bare bones `make` legacy while `task` offers a bit more structured approach coming from inclusion of yaml as a specification language and many convenience things like handling env, run directories etc. I have worked with `just` for quite a bit but this looks very good honestly and I will consider switching.
I, too, use just a lot in a very off handed way. My memory isn't great and I just toss commands in a projects justfile which I occasionally need.
Yes, a readme would work to a degree too, but a justfile is runnable code. That beats dead documentation everytime.
How Yaml of all things became so popular is a mystery to me.
I am guessing the primary selling point is that it's sort of human readable similar to Markdown but even that (in fact, especially that) falls short when a configuration is more than just 5 lines, in my opinion. Trying to figure out which bullet this sub-bullet belongs to by holding my finger on the screen while scrolling is not an improved experience. And don't even get me started on the clever type system.
> Trying to figure out which bullet this sub-bullet belongs to by holding my finger on the screen while scrolling is not an improved experience
I don't see this as any worse than figuring out where nested parentheses are closed: tooling helps. I'm almost certain there's a whitespace plugin equivalent of Rainbow Parentheses for your IDE/editor of choice
> How Yaml of all things became so popular is a mystery to me.
Well . . . the Perl folks, I think, came up with something less pointy than XML. And we all appreciated that because we'd all poked ourselves with XML too many times.
I found it amusing how the main features advertised for Task were the programming language used to write it, how it's distributed as a single executable, and how it's easy to install.
None of them are relevant, or made any case for using it instead of just using the thing described in an international standard that is shipped by default in UNIX and Unix-like OSes for decades.
It's like their selling point is to talk crap about other tools without making any case for their own offering.
UNIX might be standard but it doesn't make it cross platform. You might not like it but a lot of people develop on windows. Build tools that assume a unix environment is present aren't a solution.
We use this to trigger local tasks (like build, codegen, db migrations etc.) in our monorepo. We moved to it because our npm scripts were getting messier in absense of task dependencies, lack of multiline support, comments in json etc. Being an easy to use cross platform binary that can be managed through asdf made adoption very easy.
We have few colleagues working on react-native who use windows, and it is easy to support them because it uses mvdan/sh for script execution.
Being able to organize tasks into multiple module specific taskfiles which can be merged (with auto-prefixing) into the top level taskfile is quite nice. The support for watch mode, timestamp checking, environment propagation with built in dotfile support are all nice features that we found very handy.
It would have been nicer if it used hcl but I can live with yaml. I am glad that it doesn't use a real programming language - it makes it easy to look at a task in isolation (we have hundreds) and figure out what it depends on and what it does.
It is easy to be dismissive of such tools when glancing at the homepage, but it is one of those tools that grow on you when you give it a chance. The author has also been addressing a lot of common pain points over the years for which we are thankful - it is nice to be able to trigger tasks from any subdir (similar to npm run ...) and the new editor integration is quite too.
I see people saying that you can do all that this tool does using a few simple scripts. But these scripts only start off as simple, once you need a watch mode, cross platform support, timestamp change detection, selective argument propagation, need to exec dependencies in right directories etc. they tend to get buggier and messier.
One day after writing a complex Makefile and getting frustrated because 1) it was hard to read and reason about because of make weird syntax, 2) it didn't run on CI because it uses GNU Make instead of BSD Make on my MacBook, I thought of writing a "modern" alternative:
I wanted it easy to read, write, parse and use, so I'd use YAML. You guys all shit on YAML because it's extremely badly used by, say, Helm charts, but it's a good markup language in itself. StrictYAML is anyway.
So I started writing a toy Makefile in YAML with these requirements: I need to run a command, with variables, it needs to depend on another command, and shouldn't run if the "output" file is already present and newer than the "source" files. So something like this:
At this point I realized I had written exactly the same things proposed by Taskfile (which I heard of but thought "meh it sucks, Makefiles are great).
So yeah, Taskfiles are just Makefiles with a sane syntax and better tooling (JSON schema, auto generated doc, real default target...). I have no idea why the comments are so hostile towards it, because clearly Makefiles are not perfect (it's even a pretty bad format)
it didn't run on CI because it uses GNU Make instead of BSD Make on my MacBook
What?
$ /usr/bin/make --version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for i386-apple-darwin11.3.0
My memories must fail me, I thought it was a BSD make vs GNU make issue but probably not! Maybe a version issue between the bundled make binaries on each platform, I don't remember the details to be honest
I wanted to see what was wrong with Makefile and how Taskfile solved the issue, but the post doesn't explain; it's more a tutorial on how to use Taskfile. If the author reads this, I think we'd love to know what's wrong with make.
Also, a lot of those look like artificial complexity over a shell script sourcing another one containing only variables export, and running the required scripts.
If you don't know what's wrong with make, just use make. But it probably means you probably don't USE make.
If your Makefiles look like this:
build:
go build -o dist/app
You might as well just use make, it's fine. It's less fine when you want to avoid rebuilding if sources didn't change, or if you want to use environment variables, maybe from a dotenv file, or if you want to do conditions (like adding a debug flag to a build command if a make variable is set), or if you need to use make incantations (hoping they'll work with both BSD Make and GNU Make), then a Taskfile might help solving some issues, including legibility.
I don't use make, so I wanted to see what was wrong with it, and the author's argument is that it's old. Not very convincing.
Your description starts to be more interesting, and I feel like mk (the successor of make from the Plan 9 people: https://plan9.io/sys/doc/mk.html) might address those, but again, I don't have a need for it.
Readit News
The syntax of Taskfile looks more verbose to me than Makefile, which is basically a shell script in disguise. To note also is that you praise Devenv because of it being based on Guix (Guile scheme), while you ditch Makefile which also embeds Guile scheme as the extension language (in latest versions).
Also to note, the opening argument, writing Readme files on how to build and use the software, has nothing to do with Makefiles at all. You could write a simple skeleton codegen that generates a Readme file skeleton or a template with those steps autogenerated in any language preferred, shell included, and run it as a Makefile target.
As to why being unhappy is probably not because it haven't been proof tested. I get your sentiment but feel the remark is out of place. I thought the rationale for picking other tools was straightforward and motivated.
Though the simplicity of make has been lost and I'm not sure the overhead is worth it. I wouldn't want to be the one introducing taskenv, direnv and derenv to a project.
But it was; one of his arguments. Yes, he opens with the argument that he was unhappy with the Make for years, but he later clarifies why:
> I am still stuck with a tool that (according to Wikipedia) has been written 47 years ago.
You probably haven't read his article to the end? Those were his words I copy-pasted from the blog. So one of the reasons he is unhappy is because Make is 47 years old. For some reason, it stopped to be good enough 20 years ago, according to his opinion.
I can give him that we can always have a better tool, but it is a tautology. Unfortunately, his offered alternative is not better IMO.
Deleted Comment
Op complained about that make requires a bunch of extra tools to get running, and suggests another bunch of extra tools, as well as of make DSL which is more or less shell on steroids, but suggests a mix of two different languages instead, and does not even seem to be aware he can use Guile Scheme to extend Make.
Even the fact makefiles have no extension is confusing to beginners. Everything about it screams outdated, idiosyncratic computing artifact and students pick up on that.
If someone can't understand how to use make perhaps they shouldn't be fiddling with C.
It fails only in a certain part of the script where tab is part of the syntax. It is like saying Python language fails if I add a wrong number of spaces, or replace a space with a tab, since white spaces are part of the Python syntax.
> Even the fact makefiles have no extension is confusing
How is that confusing, the entire filename (makefile) is "the extension" :-)
Put .mk at the end of the file name if that makes you happy and less "outdated" and "idiosyncratic". C/C++ does not require extension either, it is just a convention. Ever seen <vector>, <algorithm>, <iostream> etc?
DSL are the plague of our field, for one that is useful like SQL, you have a hundred that turn your life into hell. Make's DSL is already full of gotchas, but templated YAML based DSL are just insanity. They have so many footguns, and so little flexibility and ability to be debugged.
After trying a lot of task runners and builders, I finally settled on doit:
https://www.bitecode.dev/p/doit-the-goodest-python-task-runn...
- It makes the simple things simple, and the hard things possible.
- It scales up (you get targets, dependencies, manual scripting, etc), but it also scales down (you can define a simple list of shell commands to run and that's it).
- Instead of a DSL, you have regular Python. Which for all it's faults, is an excellent scripting language. It has great tooling support, and comes with a debugger.
- To avoid people abusing the expressiveness of Python, the default syntax to create tasks encourages a declarative style.
I've been using doit for years, and every single project I introduced it to was improved by it.
Of course, it comes with it's own problems (non python dev can dislike having to install that, and it doesn't yet provide a stand alone executable), but the ROI is way better than the alternatives I tried.
I wish more projects would compile their Python tool into a stand alone executable so that the users wouldn't have to deal with the installation process.
I will at some point write about how to do that with Python, so that the knowledge will more broadly available and maybe the community will grow the habit of doing it.
Meanwhile, I don't have more to offer than the "Relieving your Python packaging pain" procedure: https://www.bitecode.dev/p/relieving-your-python-packaging-p...
It's not perfect, but it's an improvement for any people that don't do a lot of Python but has to.
Deleted Comment
The truest statement of all of HN
It started off with configuration files, but then we needed logic, control flow, or variables; and for some reason nobody goes "ok, maybe we need an actual progamming language now" and instead we've created horrors beyond our comprehension.
Azure Pipelines is the worst I've used: three types of variables, conditional statements return string "True" and "False", and of course it's mostly undebuggable.
However, for now there is just a single implementation in GO.
In most cases I think it's the fault of the creators of the YAML DSL (e.g. ansible) but with CI pipelines people really just should be writing scripts 100% in other languages and wiring them up to events with YAML. I dont have any sympathy for people using them as programming languages.
I'm sure Microsoft is happy to indulge it though because hey, vendor lock-in.
Enter magefiles, I could use the same language in them as I could with my other code and stuff just worked.
[0] https://magefile.org
The best of both worlds is a good programming language that allows expressing domain specific libraries almost as if they were domain specific languages, without going so declarative that people don't know how to script anything anymore.
I don't know if Python/doit really achieved that, but its task definitions seem almost as readable as the YAML, in a real language where I can do anything I want without asking permission. So I would always choose doit over Taskfile.
But a better comparison is between doit and make. I much prefer make's basic syntax, although I dislike newer features which inevitably have stretched the syntax beyond its original simplicity, but conceivably you can achieve something similar to make in a language but as a library rather than a DSL, and it would be immediately friendlier and more powerful than make. Depending on what I was doing I would use doit, but for something simple I've still got make (and it would be easy to convert if desired, in fact I have some projects in mind that could do with this!).
But imagine having this in CI instead of YAML files.
[1] https://www.bitecode.dev/p/installing-python-the-bare-minimu...
The same can be said about using general purpose programming languages to specify stuff declaratively, but instead of implementation the problems happen in each and every single use of it. It only takes a single user that either does not comply with standards or feels they are particularly clever to mess everything for everyone.
Having to install doit first is indeed going to be a barrier of entry for a lot of people.
It's still worth it in my experience, but I get how it can deter users.
Unfortunately it’s named the same.
I have never tested it enough to discover things it does wrong, but given how new and not exactly popular this tool is, I bet there are lots of things it doesn't do right...
So, I have no idea why would anyone want this tool... beside just using one extra infra tool to appear as if you know something others don't (and that's exactly the kind of people who use it at my workplace).
I still think that most people working with VCS today would've been better off using SVN. Most companies use Git in a centralized way anyways -- they don't need the distributed feature of the system. Most people using Git today don't know how to go back in history and wouldn't be physically able to carry out this task if requested because most Git repositories I've seen in my life were, essentially, write-only, just a glorified rsync.
I needed many years of working in infra to come to terms with Git and become efficient at using it. Most developers using it today will not have a multiple-year rotation in infra position, and are terrible at using the tool.
But this is very different from Taskfile vs Makefile. Git came with many attractive features. Some, perhaps inconvenient or demanding in terms of learning, but it was a genuine new tool that solved a problem other tools at the time didn't (branches were very expensive in SVN, sharding repositories across large distances was very expensive in SVN, and Git solved both).
Taskfile doesn't do anything better than any of the existing tools. It doesn't even promise anything like that... It's just "like make" but worse... so, what's the point exactly?
> Technology moves forward
Oh you sweet summer child... no, it doesn't. Sometimes it moves backwards, sometimes it jumps in place pretending to do useful work... there's no rule to say it should, and the evidence abounds of how this statement isn't true.
And from the response you got you failed at it. Were you promoting it because technology was "moving forward" and it was "time to move on"--whatever that means, instead of its merits? Didnt work for git, certainly won't work for Taskfile.
So, don't be what guy? The idiot that says branches have no benefits? The lesson is that there are dummies on both sides of the table.
Evaluate technology on merit. And, anything that is to dislodge a ubiquitous tool that's been around for 47 years has a high bar to cross.
this is not one of those times
Deleted Comment
(I hear svn may have improved merge tracking, but I'm not going to spend more time on it.)
I used Task on a new project and the explicitness of it all was a breath of fresh air. I mean which is clearer between:
and- copying a database from production to local for bug reproduction/fixes - inserting seed-data into the local database - creating a migration after changing records - applying the migration - rolling back the migration - running a tool to copy configuration from a keyvault - running the end to end tests - generate certificates - set up an ssh tunnel to a remote server or database
All of these things are part of the development process, and cannot be part of the build system. Each of them has their own commands and tools.
All developers need to easily be able to do these things, without asking help each time, or learning the syntax of each command.
One easy way is to stuff all of them in a task runner with simple aliases. Another could be writing a document that you can copy/paste from. I prefer a task runner, since you can memorize the alias and work from the terminal without looking things up.
Also, what makes you think a build system doesn't or shouldn't do those things?
Also, you could just write a Shell script to do all of those -- what's the difference?
$ mkdir bin
> easily be able to do these things, without asking help each time
$ ls bin
> generate certificates
$ bin/mkcert.sh
What you didn't need: yet another tool and config syntax as a dumping bucket for your one-liners and command aliases.
Taskfile brings nothing to the table. It cannot compete with existing automation tools. It doesn't even promise to be better than existing automation tools...
I mean, give me at least some reason to believe it could be better than what I already have... to me it looks like the people who wrote it simply never saw what's already there. Kind of like a university project where students write a simplistic compiler for a subset of C language... It's nice that they tried their hand, but they have a long way before they actually produce something useful.
[0] https://github.com/casey/just
Maybe you're thinking of k8s and all of its related tooling?
I am guessing the primary selling point is that it's sort of human readable similar to Markdown but even that (in fact, especially that) falls short when a configuration is more than just 5 lines, in my opinion. Trying to figure out which bullet this sub-bullet belongs to by holding my finger on the screen while scrolling is not an improved experience. And don't even get me started on the clever type system.
I don't see this as any worse than figuring out where nested parentheses are closed: tooling helps. I'm almost certain there's a whitespace plugin equivalent of Rainbow Parentheses for your IDE/editor of choice
Well . . . the Perl folks, I think, came up with something less pointy than XML. And we all appreciated that because we'd all poked ourselves with XML too many times.
https://en.wikipedia.org/wiki/YAML
None of them are relevant, or made any case for using it instead of just using the thing described in an international standard that is shipped by default in UNIX and Unix-like OSes for decades.
It's like their selling point is to talk crap about other tools without making any case for their own offering.
We have few colleagues working on react-native who use windows, and it is easy to support them because it uses mvdan/sh for script execution.
Being able to organize tasks into multiple module specific taskfiles which can be merged (with auto-prefixing) into the top level taskfile is quite nice. The support for watch mode, timestamp checking, environment propagation with built in dotfile support are all nice features that we found very handy.
It would have been nicer if it used hcl but I can live with yaml. I am glad that it doesn't use a real programming language - it makes it easy to look at a task in isolation (we have hundreds) and figure out what it depends on and what it does.
It is easy to be dismissive of such tools when glancing at the homepage, but it is one of those tools that grow on you when you give it a chance. The author has also been addressing a lot of common pain points over the years for which we are thankful - it is nice to be able to trigger tasks from any subdir (similar to npm run ...) and the new editor integration is quite too.
I see people saying that you can do all that this tool does using a few simple scripts. But these scripts only start off as simple, once you need a watch mode, cross platform support, timestamp change detection, selective argument propagation, need to exec dependencies in right directories etc. they tend to get buggier and messier.
I wanted it easy to read, write, parse and use, so I'd use YAML. You guys all shit on YAML because it's extremely badly used by, say, Helm charts, but it's a good markup language in itself. StrictYAML is anyway.
So I started writing a toy Makefile in YAML with these requirements: I need to run a command, with variables, it needs to depend on another command, and shouldn't run if the "output" file is already present and newer than the "source" files. So something like this:
At this point I realized I had written exactly the same things proposed by Taskfile (which I heard of but thought "meh it sucks, Makefiles are great).So yeah, Taskfiles are just Makefiles with a sane syntax and better tooling (JSON schema, auto generated doc, real default target...). I have no idea why the comments are so hostile towards it, because clearly Makefiles are not perfect (it's even a pretty bad format)
I hate make and I dont like the idea of using non-typesafe YAML to build this (which presumably this tool does, since it's done in golang).
I've been using a "standardized" bash script with a huge case statement as a justfile/this/makefile replacement but it's not ideal.
Also, a lot of those look like artificial complexity over a shell script sourcing another one containing only variables export, and running the required scripts.
If your Makefiles look like this:
You might as well just use make, it's fine. It's less fine when you want to avoid rebuilding if sources didn't change, or if you want to use environment variables, maybe from a dotenv file, or if you want to do conditions (like adding a debug flag to a build command if a make variable is set), or if you need to use make incantations (hoping they'll work with both BSD Make and GNU Make), then a Taskfile might help solving some issues, including legibility.Your description starts to be more interesting, and I feel like mk (the successor of make from the Plan 9 people: https://plan9.io/sys/doc/mk.html) might address those, but again, I don't have a need for it.