• u_tamtam@programming.dev
    link
    fedilink
    English
    arrow-up
    1
    arrow-down
    1
    ·
    1 year ago

    I think the only way to make this constructive is if you could describe what you mean by “boilerplate”. My experience of writing and reading mill build files is that they are extremely succinct and convey their intent clearly.

    And judging by your “false equivalence” statement, I’m not sure you actually read the thread I linked. Cargo is factually a very basic tool, comparatively.

    • argv_minus_one@beehaw.org
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      1 year ago

      I think the only way to make this constructive is if you could describe what you mean by “boilerplate”.

      object, extends, def, Seq, etc. These things do not belong in the top-level description of the project.

      And judging by your “false equivalence” statement, I’m not sure you actually read the thread I linked.

      I just did. I am not at all convinced by lihaoyi’s reasoning. Maven already solved the “templating system” problem with POM inheritance. POMs are not functional programs. There is no need to pass values between different parts of the structure; simple variable substitution is usually adequate, and when it’s not, scripts and plugins fill the remaining gaps.

      Cargo is factually a very basic tool, comparatively.

      Maven isn’t, and although it has serious problems, none of them arise from the fact that its project description is not executable code. There is no need for that.

      And there is a need for not-that: it takes a long time for IDEs to open sbt projects, and they frequently fail to do so at all. Maven and Cargo projects, meanwhile, open instantaneously and reliably.