11 ms·

My personal choice would be Clojure. I learned Racket and Common Lisp but haven't used them build something production-grade yet. I don't even know how to prope

My personal choice would be Clojure. I learned Racket and Common Lisp but haven't used them build something production-grade yet. I don't even know how to properly build, deploy and monitor a Racket server yet. Racket is good but the toolchain and libraries are far behind Clojure. Especially Cider and Cursive are so great, and for libraries, there are a lot of solid ones like Ring/Compojure, interesting things like Duct, Pathom, Fulcro. Common Lisp is also good, SBCL/Slime is solid, but it has its own idioms, a multiple paradigm Lisp-2 and feels pretty different from Scheme and Clojure. I found single-paradigm languages like Clojure and Scheme are sufficient to do most things already. Java-world-wise, you don't have to deal with Java most of the time if you don't want to. There are plenty of Clojure libraries which of course follow Clojure idioms.

paulddraper 7y ago
Exactly. You "have to" deal with Java for Clojure about as much as you "have to" deal with C for Python, or C++ for Node.js. The implementation leaks for some dependencies, and it is easy to drop down into the lower language, but you can avoid knowing much about it.
- michaelmrose 7y ago
  Not understanding Java at all would seem to limit your choice of libraries, understanding of performance, and even usage of language features that directly rely on calling Java. In theory you could but your experience won't be optimal.
  - cutler 7y ago
    I've been using Clojure productively for years without ever having to import anything from Java.
giancarlostoro 7y ago
Try Clojure. My advise and what wow'ed me the most: install Leinengen the package manager for Clojure and try a hello world web app tutorial that follows Leinengen. Lein will download and install Clojure for you and pull in all the dependencies. Idk any package manager that bootstraps itself like this. All you need is the Lein JAR and obv a JRE installed and you are good to do anything. Also having done both Clojure and Enterprise Java. I can tell you its not married to Java. Theres plenty of Clojure specific libraries you can use. Also try out Nightcode. Its coded in Clojure and is very straight forward. Just hold CTRL and it will show you all available commands.
- xkgt 7y ago
  // Idk any package manager that bootstraps itself like this. All you need is the Lein JAR and obv a JRE installed and you are good to do anything. Scala's sbt works in a similar manner.
  - giancarlostoro 7y ago
    Ah fair enough, never tried Scala before.
- anjanb 7y ago
  "Idk any package manager that bootstraps itself like this" Anaconda python's conda package manager can do the same.
- oblio 7y ago
  What do you mean? If you write some Clojure Leinigen automatically figures out the dependencies? If not, every package manager works like you describe, you need it plus something like the JVM and it just works (Maven, Gradle, npm, pip...).
  - ludwigvan 7y ago
    I think he means that Clojure is a dependency (a JAR) that lein installs. npm, pip etc require node or python, they don't bootstrap. Perhaps it doesn't make a huge difference in practice, but it might help in getting everyone on the same version. For node, you need something like volta or nvm.
    - oblio 7y ago
      He just said Leinigen still needs the JRE preinstalled, functionally it's the same thing.
traderjane 7y ago
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?
thekhatribharat 7y ago
Ref: https://github.com/topics/clojure https://github.com/topics/clojure
kamaal 7y ago
>>Racket is good but the toolchain and libraries are far behind Clojure. Plus they plan to deprecate the entire language's syntax in the near future. Clojure is the way to go. It might not be perfect. But it works for most part.
- BalinKing 7y ago
  I don't think they're planning to deprecate Racket's current syntax, since they say they'll still support it and that the existing syntax has already reached about a "local maximum."[0] Full excerpt from Matthew Flatt (as of about a month ago): > Racket's design and implementation is on solid ground, and from this point, it can continue to evolve and improve in many ways. No matter how Racket evolves, the community is committed to preserving what we have achieved: today's `#lang racket` programs will run in the future, and today's `#lang racket` modules can be used in future Racket programs. At the same time, the current language design may be close to a local maximum, and it's not in the nature of the Racket community to be satisfied with a local maximum. [0] https://groups.google.com/forum/#!searchin/racket-users/racket2%7Csort:date/racket-users/HiC7z3A5O-k/VgPW2hJNCwAJ https://groups.google.com/forum/#!searchin/racket-users/rack...
  - kamaal 7y ago
    I really don't think any one starting a project for production environment will be happy with being told that existing programs would run, but expect no fixes or enhancements from now on. See how Perl lost programmer mindshare in the 2000s because of Perl 5 development had stalled in the favor of Perl 6. Racket is(was) a language to do home work assignments. I guess even their very dedicated users would either switch to scheme or will just move to Clojure, with the current situation now.
    - pritambaral 7y ago
      > but expect no fixes or enhancements from now on. This is a common misunderstanding around the Racket 2 proposal. Racket is completely different from Python and Perl when it comes to syntax. Racket already supports multiple syntaxes over the same semantics, and is designed for people to be able to build new syntaxes themselves. IOW, Racket 1 (more precisely: `#lang racket`) and Racket 2 will not be different runtimes, only different ways of writing what is to run. You cannot run Python 2 and Python 3 in the same process, or import a Python 2 module in Python 3 file; similarly with Perl 5 and 6. But a `#lang racket` (less precisely: Racket 1) module can be imported and run in the same runtime and context as a `#lang racket2` (less precisely: Racket 2) module.
oneObi 7y ago
I totally agree: I know Clojure and Racket and I think Clojure (and ClojureScript) are great for real, day to day, development; in fact, I use them at my job. I really don't know very much about Java, just the minimum needed

paulddraper 7y ago

Exactly. You "have to" deal with Java for Clojure about as much as you "have to" deal with C for Python, or C++ for Node.js. The implementation leaks for some dependencies, and it is easy to drop down into the lower language, but you can avoid knowing much about it.

michaelmrose 7y ago
Not understanding Java at all would seem to limit your choice of libraries, understanding of performance, and even usage of language features that directly rely on calling Java. In theory you could but your experience won't be optimal.
- cutler 7y ago
  I've been using Clojure productively for years without ever having to import anything from Java.

giancarlostoro 7y ago

Try Clojure. My advise and what wow'ed me the most: install Leinengen the package manager for Clojure and try a hello world web app tutorial that follows Leinengen. Lein will download and install Clojure for you and pull in all the dependencies. Idk any package manager that bootstraps itself like this. All you need is the Lein JAR and obv a JRE installed and you are good to do anything. Also having done both Clojure and Enterprise Java. I can tell you its not married to Java. Theres plenty of Clojure specific libraries you can use. Also try out Nightcode. Its coded in Clojure and is very straight forward. Just hold CTRL and it will show you all available commands.

xkgt 7y ago
// Idk any package manager that bootstraps itself like this. All you need is the Lein JAR and obv a JRE installed and you are good to do anything. Scala's sbt works in a similar manner.
- giancarlostoro 7y ago
  Ah fair enough, never tried Scala before.
anjanb 7y ago
"Idk any package manager that bootstraps itself like this" Anaconda python's conda package manager can do the same.
oblio 7y ago
What do you mean? If you write some Clojure Leinigen automatically figures out the dependencies? If not, every package manager works like you describe, you need it plus something like the JVM and it just works (Maven, Gradle, npm, pip...).
- ludwigvan 7y ago
  I think he means that Clojure is a dependency (a JAR) that lein installs. npm, pip etc require node or python, they don't bootstrap. Perhaps it doesn't make a huge difference in practice, but it might help in getting everyone on the same version. For node, you need something like volta or nvm.
  - oblio 7y ago
    He just said Leinigen still needs the JRE preinstalled, functionally it's the same thing.

traderjane 7y ago

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?

thekhatribharat 7y ago

Ref: https://github.com/topics/clojure https://github.com/topics/clojure

kamaal 7y ago

>>Racket is good but the toolchain and libraries are far behind Clojure. Plus they plan to deprecate the entire language's syntax in the near future. Clojure is the way to go. It might not be perfect. But it works for most part.

BalinKing 7y ago
I don't think they're planning to deprecate Racket's current syntax, since they say they'll still support it and that the existing syntax has already reached about a "local maximum."[0] Full excerpt from Matthew Flatt (as of about a month ago): > Racket's design and implementation is on solid ground, and from this point, it can continue to evolve and improve in many ways. No matter how Racket evolves, the community is committed to preserving what we have achieved: today's `#lang racket` programs will run in the future, and today's `#lang racket` modules can be used in future Racket programs. At the same time, the current language design may be close to a local maximum, and it's not in the nature of the Racket community to be satisfied with a local maximum. [0] https://groups.google.com/forum/#!searchin/racket-users/racket2%7Csort:date/racket-users/HiC7z3A5O-k/VgPW2hJNCwAJ https://groups.google.com/forum/#!searchin/racket-users/rack...
- kamaal 7y ago
  I really don't think any one starting a project for production environment will be happy with being told that existing programs would run, but expect no fixes or enhancements from now on. See how Perl lost programmer mindshare in the 2000s because of Perl 5 development had stalled in the favor of Perl 6. Racket is(was) a language to do home work assignments. I guess even their very dedicated users would either switch to scheme or will just move to Clojure, with the current situation now.
  - pritambaral 7y ago
    > but expect no fixes or enhancements from now on. This is a common misunderstanding around the Racket 2 proposal. Racket is completely different from Python and Perl when it comes to syntax. Racket already supports multiple syntaxes over the same semantics, and is designed for people to be able to build new syntaxes themselves. IOW, Racket 1 (more precisely: `#lang racket`) and Racket 2 will not be different runtimes, only different ways of writing what is to run. You cannot run Python 2 and Python 3 in the same process, or import a Python 2 module in Python 3 file; similarly with Perl 5 and 6. But a `#lang racket` (less precisely: Racket 1) module can be imported and run in the same runtime and context as a `#lang racket2` (less precisely: Racket 2) module.

oneObi 7y ago

I totally agree: I know Clojure and Racket and I think Clojure (and ClojureScript) are great for real, day to day, development; in fact, I use them at my job. I really don't know very much about Java, just the minimum needed