4 ms·

Am I wrong for saying that the Clojure community has not yet achieved consensus for things as simple as a build system? In some ways that seems like there would

Am I wrong for saying that the Clojure community has not yet achieved consensus for things as simple as a build system? In some ways that seems like there would be more up-and-going friction than the JS build world.

msbarnett 7y ago
Doesn’t JS have basically the exact same thing going as leiningen vs boot in npm vs yarn?
- uncletaco 7y ago
  Not really no. Lein and boot don't read from the same project declaration file and clj adds another way to declare dependencies through dep.edn files. A previous poster was being very optimistic when they said you could switch from one to another in fifteen minutes. On the other hand using yarn or npm is almost completely interchangeable for the vast majority of workflows. The only thing one should be careful about with regards to them are project lock files. Otherwise most of the user facing differences are more about form rather than functionality.
  - didibus 7y ago
    Actually, lein and boot both use maven pom.xml and pom.properties as their declared dependencies format. When you publish or pull a dependency, it resolves it using pom.xml from the Maven repo, and when you push, they generate the pom.xml for publishing to the Maven repo. So this means that Gradle, Boot, Lein, Maven, and tools.deps all can consume packages from each other seamlessly, and they all publish to the same repositories in exactly the same format. The only thing that is different are the way you create build steps and build pipelines. As well as the way you declare your dependencies. That's why there isn't any friction due to having multiple build tools and dependency managers. Because the package manager is always the same: Maven.
    - uncletaco 7y ago
      Can you go backwards and generate a project/boot.clj from a pom file? And can lein read from your boot file? Because npm and yarn tag the same input, produce nearly the same output, and can run tasks defined in the same location (the project.json). Does clj tooling do that as well?
      - cbcoutinho 7y ago
        I'm not sure if you can create a project.clj, boot.clj, or deps.edn file from a pom file, but there are at least plugins available that let one tool to read the input of another. This plugin allows Leiningen to read deps.edn files for example. https://github.com/RickMoynihan/lein-tools-deps https://github.com/RickMoynihan/lein-tools-deps
        uncletaco 7y ago
        I think this sort of shows what I'm getting at. Without plug-ins or extra scripts yarn and npm take the same inputs, and yield the same output. A yarn user can share a prokect with an npm user and neither will know nor care what tool the other is using our how too make the tools talk. This isn't to knock clojure tooling, which is good, but I don't think lein and boot are drop in replacements for each other like npm and yarn (almost) are.
      - yomly 7y ago
        Wrt lein to deps.edn: https://clojureverse.org/t/has-anyone-written-a-tool-to-spit-out-a-deps-edn-from-a-project-clj/2086/5 https://clojureverse.org/t/has-anyone-written-a-tool-to-spit...
      - didibus 7y ago
        Yarn and Npm are package managers. They are not build automation tools. They only pull dependencies and publish them back and perform dependency resolution. Lein and Boot are full build tools. They do package management, but they also do task automation such as Gulp and Grunt, bundling such as Webpack and Parcel, and scaffolding such as Yeoman or Brunch. If you take only their package management subset. Then it does take only 15 min to switch from one to the other. Just like Yarn and NPM both publish too and pull from npm repositories, Lein and Boot publish too and pull from Maven repositories. It is only once you get to task automation that Lein and Boot start to differ. Rewriting your tasks and build pipeline from one to the other will take you much longer. That's also true of switching from Gulp to Grunt for example. I also want to add that, bundling is similar in Boot and Lein. While the tasks to do so are not, the way things are bundled is the same. Scaffolding is also interchangeable, since both support each others template formats.
namelosw 7y ago
JS is way from settled. There was grunt and gulp before, and there are Webpack, Parcel, RollUp, Pika etc.
michaelmrose 7y ago
Lein, boot, and clj are simple tools. Choosing one does not tie you to any other particular choice. You could pick one and switch to the other after 15 minutes reading.
didibus 7y ago
Not exactly, it doesn't have a single build tool, but its build mechanisms have never diverged and have remained the same since the beginning. Everything is packaged together in an UberJar or a Jar. The former can just be dropped on a host and ran, it contains everything needed to run. The latter is meant when packaging a library, it includes only your code, excluding all dependencies. Maven is used for distribution, Maven central and Clojars are the main repositories used for open source. So there's no issue of compatibility or confusion in how to package and distribute programs or libraries. But you have the choice between a few different frameworks for writing your build scripts and build pipelines. You can even just roll your own (seriously, rolling your own would take less than a week). Because of this, there isn't any friction, just choice of multiple ways to define your build steps. So you can choose your favorite style, declarative with Lein, functional with Boot, or Unix-like with tools.deps. Choice is everywhere in Clojure though, there's always a multitude of options for everything which can most of the time easily be combined together seamlessly and made to work together pretty simply. This choice attracts experienced devs, but turns off lesser experienced devs. It doesn't help that everything always continues to work, as backward compatibility is taken very seriously. So choice can be overwhelming, be prepared for that if you journey in Clojure. You'll have to make decisions of your own, and owe up to them.
thekhatribharat 7y ago
@traderjane, do you work at Jane Street? If yes, tell us the benefits of OCaml at work. :)
pjc50 7y ago
This is fairly low down the priority list for a language, even if it's very convenient for the users. Most of the older languages don't even have defined build/packaging systems. It doesn't stop people from using C/C++.

msbarnett 7y ago

Doesn’t JS have basically the exact same thing going as leiningen vs boot in npm vs yarn?

uncletaco 7y ago
Not really no. Lein and boot don't read from the same project declaration file and clj adds another way to declare dependencies through dep.edn files. A previous poster was being very optimistic when they said you could switch from one to another in fifteen minutes. On the other hand using yarn or npm is almost completely interchangeable for the vast majority of workflows. The only thing one should be careful about with regards to them are project lock files. Otherwise most of the user facing differences are more about form rather than functionality.
- didibus 7y ago
  Actually, lein and boot both use maven pom.xml and pom.properties as their declared dependencies format. When you publish or pull a dependency, it resolves it using pom.xml from the Maven repo, and when you push, they generate the pom.xml for publishing to the Maven repo. So this means that Gradle, Boot, Lein, Maven, and tools.deps all can consume packages from each other seamlessly, and they all publish to the same repositories in exactly the same format. The only thing that is different are the way you create build steps and build pipelines. As well as the way you declare your dependencies. That's why there isn't any friction due to having multiple build tools and dependency managers. Because the package manager is always the same: Maven.
  - uncletaco 7y ago
    Can you go backwards and generate a project/boot.clj from a pom file? And can lein read from your boot file? Because npm and yarn tag the same input, produce nearly the same output, and can run tasks defined in the same location (the project.json). Does clj tooling do that as well?
    - cbcoutinho 7y ago
      I'm not sure if you can create a project.clj, boot.clj, or deps.edn file from a pom file, but there are at least plugins available that let one tool to read the input of another. This plugin allows Leiningen to read deps.edn files for example. https://github.com/RickMoynihan/lein-tools-deps https://github.com/RickMoynihan/lein-tools-deps
      - uncletaco 7y ago
        I think this sort of shows what I'm getting at. Without plug-ins or extra scripts yarn and npm take the same inputs, and yield the same output. A yarn user can share a prokect with an npm user and neither will know nor care what tool the other is using our how too make the tools talk. This isn't to knock clojure tooling, which is good, but I don't think lein and boot are drop in replacements for each other like npm and yarn (almost) are.
    - yomly 7y ago
      Wrt lein to deps.edn: https://clojureverse.org/t/has-anyone-written-a-tool-to-spit-out-a-deps-edn-from-a-project-clj/2086/5 https://clojureverse.org/t/has-anyone-written-a-tool-to-spit...
    - didibus 7y ago
      Yarn and Npm are package managers. They are not build automation tools. They only pull dependencies and publish them back and perform dependency resolution. Lein and Boot are full build tools. They do package management, but they also do task automation such as Gulp and Grunt, bundling such as Webpack and Parcel, and scaffolding such as Yeoman or Brunch. If you take only their package management subset. Then it does take only 15 min to switch from one to the other. Just like Yarn and NPM both publish too and pull from npm repositories, Lein and Boot publish too and pull from Maven repositories. It is only once you get to task automation that Lein and Boot start to differ. Rewriting your tasks and build pipeline from one to the other will take you much longer. That's also true of switching from Gulp to Grunt for example. I also want to add that, bundling is similar in Boot and Lein. While the tasks to do so are not, the way things are bundled is the same. Scaffolding is also interchangeable, since both support each others template formats.

namelosw 7y ago

JS is way from settled. There was grunt and gulp before, and there are Webpack, Parcel, RollUp, Pika etc.

michaelmrose 7y ago

Lein, boot, and clj are simple tools. Choosing one does not tie you to any other particular choice. You could pick one and switch to the other after 15 minutes reading.

didibus 7y ago

Not exactly, it doesn't have a single build tool, but its build mechanisms have never diverged and have remained the same since the beginning. Everything is packaged together in an UberJar or a Jar. The former can just be dropped on a host and ran, it contains everything needed to run. The latter is meant when packaging a library, it includes only your code, excluding all dependencies. Maven is used for distribution, Maven central and Clojars are the main repositories used for open source. So there's no issue of compatibility or confusion in how to package and distribute programs or libraries. But you have the choice between a few different frameworks for writing your build scripts and build pipelines. You can even just roll your own (seriously, rolling your own would take less than a week). Because of this, there isn't any friction, just choice of multiple ways to define your build steps. So you can choose your favorite style, declarative with Lein, functional with Boot, or Unix-like with tools.deps. Choice is everywhere in Clojure though, there's always a multitude of options for everything which can most of the time easily be combined together seamlessly and made to work together pretty simply. This choice attracts experienced devs, but turns off lesser experienced devs. It doesn't help that everything always continues to work, as backward compatibility is taken very seriously. So choice can be overwhelming, be prepared for that if you journey in Clojure. You'll have to make decisions of your own, and owe up to them.

thekhatribharat 7y ago

@traderjane, do you work at Jane Street? If yes, tell us the benefits of OCaml at work. :)

pjc50 7y ago

This is fairly low down the priority list for a language, even if it's very convenient for the users. Most of the older languages don't even have defined build/packaging systems. It doesn't stop people from using C/C++.