3 ms·

Considering the staggering number of languages out there that have implemented their own worse-version of make, or even those that haven't and the language-agno

Considering the staggering number of languages out there that have implemented their own worse-version of make, or even those that haven't and the language-agnostic tooling systems that are implementing make instead... I hate to say this but Bazel is probably the first time we have a tool that's better than make. It took over 40 years to get here. And it's still a pain in the ass.

throwaway894345 7y ago
> Considering the staggering number of languages out there that have implemented their own worse-version of make, or even those that haven't and the language-agnostic tooling systems that are implementing make instead... The language-specific build tools tend to be good, at least for mainstream languages introduced in the last 20 years. Certainly better than make. Bazel and especially Nix are really interesting and directionally correct, but like you mention, they are pains in the ass. Fortunately, their issues aren’t fundamental to the category of general purpose reproducible build tools. They’re just issues of execution. And arguably Nix isn’t even trying to be a build tool as much as a packaging tool (subtle but manifestly important difference), which is a damn shame.
- adev_ 7y ago
  > The language-specific build tools tend to be good, at least for mainstream languages introduced in the last 20 years. Certainly better than make. They are good for 'quick & dirty' dev usage. And terrible for everything else. Specially integration. If they were perfect, you would not see things like lerna in JS (https://github.com/lerna/lerna https://github.com/lerna/lerna) or Conda in python (https://docs.conda.io/en/latest/ https://docs.conda.io/en/latest/) to go around them. > And arguably Nix isn’t even trying to be a build tool as much as a packaging tool (subtle but manifestly important difference), which is a damn shame. And they are right to be so. Build system and Package manager should be separated, or at least should be usable independently. If your environment is multi-languages or system oriented, there is no possible practical way you can get a tool that reliably do both and scale. It would imply to rewrite every the language specific builder of every language. I would say that in an ideal world, we would have language specific build system and one generic & portable set of dependency resolution tools (package managers). In our current world, every language is its own isolated island and making them interoperate is a mess.
  - iainmerrick 7y ago
    Yes! It’s ridiculous how modern languages all try to do package management too, and how they’re all mutually incompatible. I’m not so sure about language-specific build systems, though. Trying to set up a custom asset pipeline in most build systems is a pain, when they want you to shoehorn everything into a single language rather than just calling out to external tools and scripts (ideally including tools built as part of the same project!) Bazel gets this right.

throwaway894345 7y ago

> Considering the staggering number of languages out there that have implemented their own worse-version of make, or even those that haven't and the language-agnostic tooling systems that are implementing make instead... The language-specific build tools tend to be good, at least for mainstream languages introduced in the last 20 years. Certainly better than make. Bazel and especially Nix are really interesting and directionally correct, but like you mention, they are pains in the ass. Fortunately, their issues aren’t fundamental to the category of general purpose reproducible build tools. They’re just issues of execution. And arguably Nix isn’t even trying to be a build tool as much as a packaging tool (subtle but manifestly important difference), which is a damn shame.

adev_ 7y ago
> The language-specific build tools tend to be good, at least for mainstream languages introduced in the last 20 years. Certainly better than make. They are good for 'quick & dirty' dev usage. And terrible for everything else. Specially integration. If they were perfect, you would not see things like lerna in JS (https://github.com/lerna/lerna https://github.com/lerna/lerna) or Conda in python (https://docs.conda.io/en/latest/ https://docs.conda.io/en/latest/) to go around them. > And arguably Nix isn’t even trying to be a build tool as much as a packaging tool (subtle but manifestly important difference), which is a damn shame. And they are right to be so. Build system and Package manager should be separated, or at least should be usable independently. If your environment is multi-languages or system oriented, there is no possible practical way you can get a tool that reliably do both and scale. It would imply to rewrite every the language specific builder of every language. I would say that in an ideal world, we would have language specific build system and one generic & portable set of dependency resolution tools (package managers). In our current world, every language is its own isolated island and making them interoperate is a mess.
- iainmerrick 7y ago
  Yes! It’s ridiculous how modern languages all try to do package management too, and how they’re all mutually incompatible. I’m not so sure about language-specific build systems, though. Trying to set up a custom asset pipeline in most build systems is a pain, when they want you to shoehorn everything into a single language rather than just calling out to external tools and scripts (ideally including tools built as part of the same project!) Bazel gets this right.