5 ms·

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 existin

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

trabant00 3y ago
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?
- thiht 3y ago
  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 ?
  - morelisp 3y ago
    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.
    - thiht 3y ago
      > 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
      - inopinatus 3y ago
        Keep digging this hole and you will just reinvent make, only worse. It's like Greenspun's tenth rule, only for build tools.
        thiht 3y ago
        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
  - inopinatus 3y ago
    > which is clearer (..) ? the makefile
    - thiht 3y ago
      In bad faith, yeah probably. $@, .PHONY, and the implicit target/dependency syntax is clever, terse, but NOT clear.
kmac_ 3y ago
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.
- erik_seaberg 3y ago
  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.)
  - mkesper 3y ago
    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.
    - erik_seaberg 3y ago
      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.
- crabbone 3y ago
  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.
strokirk 3y ago
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.
- silverwind 3y ago
  Targets can be conditionally defined, so a built-in help may be inaccurate.
  - jen20 3y ago
    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.
- crabbone 3y ago
  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.
- photonthug 3y ago
  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.
- monocasa 3y ago
  At least on debians using bash, tab completion will include the user defined targets.
datastack 3y ago
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.
- crabbone 3y ago
  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?
- inopinatus 3y ago
  > 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.

trabant00 3y ago

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?

thiht 3y ago
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 ?
- morelisp 3y ago
  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.
  - thiht 3y ago
    > 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
    - inopinatus 3y ago
      Keep digging this hole and you will just reinvent make, only worse. It's like Greenspun's tenth rule, only for build tools.
      - thiht 3y ago
        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
- inopinatus 3y ago
  > which is clearer (..) ? the makefile
  - thiht 3y ago
    In bad faith, yeah probably. $@, .PHONY, and the implicit target/dependency syntax is clever, terse, but NOT clear.

kmac_ 3y ago

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.

erik_seaberg 3y ago
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.)
- mkesper 3y ago
  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.
  - erik_seaberg 3y ago
    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.
crabbone 3y ago
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.

strokirk 3y ago

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.

silverwind 3y ago
Targets can be conditionally defined, so a built-in help may be inaccurate.
- jen20 3y ago
  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.
crabbone 3y ago
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.
photonthug 3y ago
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.
monocasa 3y ago
At least on debians using bash, tab completion will include the user defined targets.

datastack 3y ago

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.

crabbone 3y ago
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?
inopinatus 3y ago
> 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.