Hacker News Reader

Comment by crabbone | Hacker News Reader

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).

View on HN

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.

git's CLI is famously inconsistent, but git merge was obviously much more reliable than svnmerge.py ever had been.

(I hear svn may have improved merge tracking, but I'm not going to spend more time on it.)

Git's CLI has improved over the years. E.g. git switch is a thing now. And it's quite consistent regarding order of arguments.

What bugs me is stuff like

  git branch -c [old] new
  git checkout -b new [old]
  git switch -c new [old]
  git rebase old new # if new only exists upstream?

You have to remember how each command works separately, because any one will lead you astray about some of the others.

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.

> Most companies use Git in a centralized way anyways -- they don't need the distributed feature of the system.

Even if you have a single centralized remote, git being distributed lets you work offline, because you have a full copy of the repository, and you can commit locally.

> 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

Google exists and can help if someone doesn’t know but needs to do that.

> because most Git repositories I've seen in my life were, essentially, write-only, just a glorified rsync.

[citation needed]. If you have more than one person, how can a repository be write-only?

> Google exists and can help

Google isn't going to help if you were doing merges for a year, and then discovered you need to go back in history, and now you realize you should've been doing rebases instead. Google all you want -- it will be of no use, because your repository is a pile of garbage at this point, and it's not humanly possible to go back in time. Like I wrote in the post you replied to -- most programmers use Git where rsync would do.

> git being distributed lets you work offline

You could do that with SVN too. It was actually my other complaint about Git. Both SVN and Git use the word "commit", but those two mean different things. SVN "commit" is more like Git "push". Perhaps, you'd have to work harder in SVN having to reconcile the changes you haven't committed for a while, esp. because the tradition was for many developers to work on the same branch, but not impossible.

> If you have more than one person, how can a repository be write-only?

Do merges instead of rebases. When I say "write-only", I mean that the history of the repository is worthless -- it's written, but it's not actionable. This isn't apparent with smaller teams who have very few branches and work on a relatively small project. With larger teams merges in a repository create a ball-of-yarn history. I mean, you can read it, technically, but even using it as a log isn't feasible anymore. You could just throw it away, and nothing will change in your workflow / ability to recover from bad code changes / ability to transfer patches across versions etc.

sometimes there is great leap forward in build tools!

this is not one of those times

This is a poor take. MAKE files have existed for decades.

Every makefile I've used in the last decade has had every target marked as phony. When you're disabling one of the primary features of a tool to continue using it because you know how to use it, it's time to find a new tool.

Explicit is better than implicit? If everything was implicitly PHONY then of course people would complain about that as well. This is a bit like typing in function-signatures. But what's the proposal here, acknowledgement that your use-case is the best / most normal for default behaviour? Should function sigs that are missing type-hints always default to strings because that works well with your project code?

It's not about being explicit it's about using an abstraction that doesn't fit what you're abstracting.

Make operates on the abstraction of targets are files. If you don't confirm to that abstraction, make is the wrong tool. To use the hammer analogy, just because you're good at hammering something, doesn't mean you should use it for a screw.

Tools like docker and terraform don't use conventional files for state. Running tests in e.g. golang doesn't generate output files. Logging into the GitHub cli or aws don't have input and output files to compare for whether the task needs to be re-run.

To be pedantic: in the default mode, Terraform _does_ use a normal file for state, and for locks, and Make dependency tracking works fine with it.

That's a fair point. Funnily enough, I have the same complaints about terraform - the out of the box defaults (local state/lock files, and how backends work) are nonsense and incompatible with how the tool is actually used.

Make is not a task runner. Let me quote from it's manpage:

The purpose of the make utility is to determine automatically which pieces of a large program need to be recompiled, and issue the commands to recompile them.

And yet of course it runs tasks all the time in thousands of projects for decades, so there's the possibility that you're being overly literal and pedantic about the whole thing. Make specifies DAGs and helps resolve paths in them. A build is just a "program" where "recompile" is "re-execute task" and dealing with file-based dependencies is a special case.

> I promoted Git over a decade ago

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 the sort of logic that replaced make with cmake. New can definitely be worse than old. For example, cmake is terrible.

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)

and

    env:
        BINARY: ./foo
    tasks:
        build:
            cmds:
                - go build -o $BINARY
            sources:
                - **/*.go
            generates:
                - $BINARY

?

What if you use `embed`? Why rebuild the binary if you've only touched test files? Make at least theoretically gives you tools to deal with these (but between Make and Go they're quite hard to use), but Task gives you no chance.

> What if you use `embed`

You can add the embedded files to the "sources" list, no issues

> Why rebuild the binary if you've only touched test files

Yep, this is a thing not currently supported by Task, but they're considering extended globing iirc (with negation, like in gitignores). I think you could do something like that though:

    env:
        SOURCES:
            sh:
                find . -name *.go | grep -v _test.go

kinda ugly, but easy to understand

Keep digging this hole and you will just reinvent make, only worse.

It's like Greenspun's tenth rule, only for build tools.

I don’t see how this is worse than Make? This just shows that Taskfiles offers nicer syntax for some cases, but let’s you degrade to… something that looks just like Make actually, a variable initialized from a shell call

> which is clearer (..) ?

the makefile

In bad faith, yeah probably.

$@, .PHONY, and the implicit target/dependency syntax is clever, terse, but NOT clear.

It might be good to take a step back, and realize that the tool which is most "clear" is almost always the one which the user is most familiar with. It doesn't follow that the "clear" tool is actually more simple or more expressive.

To find out which tool is more simple, we could just count core concepts or use docs-length as a proxy. But 50 years of makefile's will muddy the water here.. is it super complicated or just well-documented? At minimum, when you reach for makefile then you know the concepts it brings are stable if complicated, and the tool is available by default almost everywhere, and the tool-versioning is almost totally safe to ignore. Looking at taskfile, I don't know the schema for the config-yaml, and more importantly I have no real confidence it's stable over time. Worrying about that sort of thing for project libs is enough work, so people don't want this kind of trouble in their build system. I also know taskfile isn't available by default until I install it.

Build-system yak-shaving mostly comes down to the same stuff. A group of people who don't want to learn tools try to convince everyone to learn some different tools, failing to realize that most of us are lazy in the same ways. Don't want to learn makefile tips and tricks? No one does really, but no one cares about taskfile tips and tricks either. Given the basic equivalence between these two situations.. there's definitely some wisdom here in preferring the standard rather than the startup.

If your needs aren't trivial, just use GNU make if you're using make.

But.... It is not build... It is running one binary one time, without any inter-dependencies. This binary (go in case of golang and cargo in case of Rust) IS build tool in these cases.

Looking at your example I think I understood why there is two schools for thoughts about this (and similar ones): because different ecosystems (go/rust vs C/C++/ObjC, mostly in these days, but also Fortran, etc) have completely different build needs.

Golang and Rust (and node.js, AFAIK) almost doesn't need external build tool, as they have their own (go, cargo, npm). It is very easy to make receipt for such build in any, even very limited, DSL, with any "task running" software.

On the other hand, how will Taskfile look for complex C/C++ project? You want separate on-demand compilation of each source file separately ("${CC} ${ALL-SOURCES}" is baaaaad idea), you need dependency extraction (ugly part of any Makefile, I admit, but receipts are well-known), you need linking, you often need some resource processing, or yacc/bison generation.

I don't think, Task file with all these features will be less ugly than typical Makefile. And many tricks are non-existing for Taskfile (and it is not clear, are they possible at all without extending DSL), and well-known for Makefiles.

This difference leads to polar views on such software.

Thank you for example!

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.

So, what's your point exactly? There are plenty of tools for this that do it a lot better than Taskfile? Like, Ansible for example?

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?

> stuff all of them in a task runner with simple aliases

$ 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.

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.

Targets can be conditionally defined, so a built-in help may be inaccurate.

Given that targets may be conditionally defined, having built-in documentation of existing targets is _more_ critical - and it should take into account such conditions.

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.

At least on debians using bash, tab completion will include the user defined targets.

Reply on news.ycombinator.com