15 ms·

Clojure 1.10 release

355 points by finalfantasia 8y ago

jplane 8y ago
I'm so excited about all the error messages work on this release! Also, the new metadata and tap functionality creates so many possibilities. And Java 8 minimum guaranteed so we can build things on top of java's time libraries and trust they will be there. Nice work everyone!
jwr 8y ago
From the perspective of a (fairly large-scale at this point) app developer: I find it great that Clojure places such emphasis on backwards compatibility. In general, migration to newer Clojure versions is completely painless. The language has been designed by experienced and mature people and doesn't go through "let's throw everything out and start again" phases like so many other languages do.
- agumonkey 8y ago
  I was a bit sad that the changelog was so small. Then I realized that maybe core features were stable and that's it, what was needed wasn't big beside spec and a few other things.
  - puredanger 8y ago
    A lot of the year's effort went into things outside core - 2 releases of spec, 2 releases of core.specs, many releases of tools.deps.alpha / clj, tools.gitlibs, new release of REBL, etc. Lots of small fixes and enhancements in core too.
    - agumonkey 8y ago
      blame it on rich, I'm addicted to revolutionary talks about collections that brings speed and expressiveness enhancement for free :p
- trevor-e 8y ago
  > The language has been designed by experienced and mature people and doesn't go through "let's throw everything out and start again" phases like so many other languages do. Swift was designed by highly experienced and mature compiler devs and is notorious for making breaking changes. It's just a difference of opinion. I prefer to suffer the occasional upgrade pain in exchange for clean and consistent APIs. And I totally understand those who don't want to deal with that. Although to be fair to them, Swift is much younger than Clojure and the number of breaking changes has steadily declined with each major release. In seven years maybe they will take the backwards compatible approach too.
  - tombert 8y ago
    I'm in the same boat; I work for a company that's been around for awhile, and as a result they've accrued a lot of Java code, a lot of it using deprecated APIs. It's quite frustrating to dig through them, and I would have been happier if Oracle had just phased out a lot of these things from the compiler (though my understanding is that JDK11 is making steps for that).
  - jwr 8y ago
    > Swift was designed by highly experienced and mature compiler devs "Compiler devs". I think that is exactly my point. I should have said "app developers" or "system designers". If you listen to a Rich Hickey talk, you'll see that he is all about Getting Things Done in the real world, and much less about theoretical concepts. Language design is subservient to app developer needs.
    - krn 8y ago
      I would put it simply: Clojure was designed by a thinker, who creates when he is away from the keyboard, not in front of it. When one releases and breaks the code in his head first, very few breaking changes are left for the public releases.
      - JBiserkov 8y ago
        Rich Hickey is a great thinker. But he's also an application developer (Datomic). So breaking changes don't just break "other people's code" in the abstract. The pain is real and immediate. By wearing multiple hats he's finding the right balance in a way that language designers who don't code day-to-day simply can't.
- porpoisely 8y ago
  Clojure's emphasis on backwards compatibility is commendable, but keep in mind Clojure is still a very young language ( only about 10 years old ) so there isn't much backwards compatibility to worry about.
  - KingMob 8y ago
    Maybe, but this was true even when Clojure was younger still. The language changes are overwhelmingly additive; Hickey places great stock in not breaking existing code.
    - thaumasiotes 8y ago
      I'm going to bring up again how + used to autopromote ints if your result was out of the primitive int range, and now throws an error instead.
      - KingMob 8y ago
        I didn't say there were no breaking changes, just fewer than most languages.
      - roenxi 8y ago
        If you want to demand perfection, then Clojure isn't going to meet your standards (what would?). The issue here is that, based on the way they (particularly Rich) talk, we can expect they will not do Bloody Stupid things like the old Python 2->3 changeover. Things like big, breaking changes that require architectural changes to keep current, or break all the available tutorials. If the problem can be fixed with a macro or single function (like a change to plus behavior) it is an irritant, not a threat to productivity. That is not a concern.
        thaumasiotes 8y ago
        You don't think a breaking change to + is any more significant than a breaking change to some other part of the language?
- thaumasiotes 8y ago
  Didn't Clojure change the + function (hardly obscure!) from automatically updating ints to bigints and therefore never overflowing to throwing an exception if you added ints that were too big? I've got a Clojure book with a spirited defense of why it's good that the simple symbol + just does what you'd expect instead of throwing exceptions based on an implementation detail, and it kind of falls flat now.
  - puredanger 8y ago
    That was over 7 years ago, so not particularly recent. And you can get the auto-promoting behavior with +' instead.
  - solussd 8y ago
    Yes, very early in Clojure's life and only after testing the change across several popular libraries.
- atarian 8y ago
  Which languages threw everything out and started again?
  - fiddlerwoaroof 8y ago
    Python 3, Perl 6 it looks like Scala 3 is heading that way too.
    - xapata 8y ago
      Python 3 is quite similar to Python 2. They made some breaking changes, but nowhere near like Perl 6. The real stumbling block was str vs unicode, which they didn't realize would be such a pain when making the decision. There's breaking changes and there's writing a new language. It's a spectrum.
      - deleted 8y ago
        [deleted]
      - jwr 8y ago
        My computer has at least three different Python versions installed. I'd say that's a pretty big backwards compatibility problem. There is also Perl 6, and I've recently read about Go 2. Swift changes every couple of months in incompatible ways.
        xapata 8y ago
        I also have several Pythons installed. For me that's because of incompatibility between community packages I've installed, rather than differences in Python versions. Unfortunately, the various smaller communities can't always stay in sync. Right now there's a conflict between XGBoost and NumPy using MKL on MacOS. That's not a Python problem, exactly, as the issue is conflicting use of OpenMP, written in C, C++, and Fortran.
      - b2gills 8y ago
        It also seems like all of the changes in Python are all changes that Perl5 has done over the years without breaking backwards compatibility. Unfortunately this does mean you often have to opt-in to the new functionality. use v5.24; use feature 'unicode_strings'; use feature 'fc'; use feature 'postderef'; … Note that the `'postderef'` feature is now always enabled so that line is pointless if you use a new enough version of Perl5. The `'unicode_strings'` also isn't always necessary.
- lsh 8y ago
  S-expressions are perhaps partly responsible as well. They don't suffer the same brittleness as regular programming languages (is there a word for non-s-expression languages like c/python/etc?).
  - EuAndreh 8y ago
    M-expressions: https://en.wikipedia.org/wiki/M-expression https://en.wikipedia.org/wiki/M-expression
    - lsh 8y ago
      that's a great link, cheers
  - snorremd 8y ago
    I think so as well. When you have macros and can add syntax and features to a language at will, then the language and core library does not need to be very big. This probably helps immensely when trying to avoid breaking changes. New macros can very well be prototyped and battle-hardened in external libraries before being added to core.
brolester 8y ago
Woohoo?
casion 8y ago
The new error messages are fantastic. Clojure just went from one of the most annoying languages to debug to mid-top tier. More complex things still present you with overly complex errors, but with some painless repl usage it's way easier to figure out things now. Kudos.
Sharlin 8y ago
Any examples of what the new error reporting looks like? The release announcement is rather lacking in details.
- lsh 8y ago
  fwiw: https://gist.github.com/lsh-0/173f1a11e2e76f718c002607c8fa1e0f https://gist.github.com/lsh-0/173f1a11e2e76f718c002607c8fa1e...
- puredanger 8y ago
  I did a write-up that should give you an idea: http://insideclojure.org/2018/12/17/errors/ http://insideclojure.org/2018/12/17/errors/
kbd 8y ago
Are there any plans for a native version of Clojure? I'd rather avoid the JVM if possible, but I suppose the whole ecosystem is dependent on it so that's unlikely?
- reilly3000 8y ago
  Its often referred to as a guest language. The syntax is largely the same across JVM, CLR, and JS V8. The aim was to utilize the richness and reach of the most popular ecosystems, so all of Maven and npm are available to Clojure devs. The language should be able to be consistent across future runtimes with largely the same semantics.
- preordained 8y ago
  I guess I might ask what this stance is founded on? The JVM is just a binary that runs byte code. It's stable and runs well pretty much everywhere. If you insist the JVM has cooties, you could use Docker and abstract it away, it might be an ideal way to use it anyways depending on your work. The JVM /= Oracle JVM by the way. There is OpenJDK EDIT: Also I think recent Java releases have gotten into making self contained binaries (which just means they package the JVM...it's in there, it might jump out and bite you!). But, as long as you are careful what you are shipping, packing up a JVM has always been an option
  - kbd 8y ago
    > I guess I might ask what this stance is founded on? Kotlin has Kotlin/Native, so I was hoping there might be a similar initiative for Clojure. But, a few reasons: * Startup time * Ability to deploy/share a binary * The JVM just seems so "heavy" to me. It's certainly the only language runtime I know of that runs a persistent helper app, or asks to install an Ask toolbar upon installation. * Bias against Oracle and Java > Also I think recent Java releases have gotten into making self contained binaries TIL, thanks. Edit: edited.
    - lsh 8y ago
      > Startup time Java is not as bad as you think. Clojure does takes a little longer though > Ability to deploy/share a binary there are jar files, but I know what you mean. Interesting work happening in GraalVM land: https://www.innoq.com/en/blog/native-clojure-and-graalvm/ https://www.innoq.com/en/blog/native-clojure-and-graalvm/ > Bias against Oracle and Java yeah, well ... we're all biased. It helps us make decisions quickly ;)
souenzzo 8y ago
Onde clojure is coded in edn, I think that is no reason to break changes. If one day we need to change something in core, we can make clojure.core2 and make the ns2 macro.
dannyobrien 8y ago
I've just started toying with Clojure, and while I've enjoyed it a great deal, the error messages were definitely one of the more unfriendly parts. Fortunately, my last two hobby languages were Elm and Haskell, so Clojure was always going to be in the middle between those two extremes). Good to see it being worked on!
billfruit 8y ago
While I like the language very well, tooling does have issues, even simple things like not distributing Leiningen with Clojure when it is almost essential for any serious development. Version incompatibilities between Leiningen and Clojure creates subtle problems. I also wonder what the experience of using lein in Windows, it seems to install using a mysterious batch file. The emacs based tooling had too many components, and is very brittle, ie, a minor version bump in one of the component often renders the whole build/repl process unserviceable. Usage of local jars is extremely difficult, you need to setup a local maven repository and then add dependencies through it, which is a very painful process, esp for hobby projects and prototyping. I should be working on my problem not wrangling with maven.
- drcode 8y ago
  Actually, I haven't used leiningen in 6 months, Clojure's new included cli tools work great these days.
  - snorremd 8y ago
    I quite like tools.deps, but it is maybe a bit problematic that it is bundled with the Clojure install. Before tools.deps there were no officially sanctioned dependency and project management tool. This is probably why we got both leiningen and eventually boot. Now the bar for choosing something different than tools.deps is probably going to be quite high. Sadly tools.deps lack the support for reading credentials from a gpg/pgp-encrypted file: https://dev.clojure.org/jira/browse/TDEPS-9 https://dev.clojure.org/jira/browse/TDEPS-9 This is a shame as I rely on this to keep repository credentials safe. I'm not a fan of the maven master password system.
- Skinney 8y ago
  > While I like the language very well, tooling does have issues, even simple things like not distributing Leiningen with Clojure when it is almost essential for any serious development. Version incompatibilities between Leiningen and Clojure creates subtle problems. I also wonder what the experience of using lein in Windows, it seems to install using a mysterious batch file. Clojure bundles tools.deps since 1.9, and it works great. cljs and figwheel already supports it, as do many others. I prefer it to leiningen, but YMMW. I use emacs to develop clojure, never had any problems with it :/ > Usage of local jars is extremely difficult, you need to setup a local maven repository and then add dependencies through it, which is a very painful process, esp for hobby projects and prototyping. I should be working on my problem not wrangling with maven. tools.deps makes this very easy.
billfruit 8y ago
Nice to know that debug messages have improved. Ease of debugging would improve more, if an exception happens a live repl is spawned at that point allowing one to view locals/values, modify state, continue execution, etc. Most lisps allows such live repls for debugging like Scheme and Emacs lisp, while clojure only provides a stacktace on exception, and not a repl.
- phyrex 8y ago
  You can do that yourself if you care (https://m.youtube.com/watch?v=zp0OEDcAro0 https://m.youtube.com/watch?v=zp0OEDcAro0) but I get what you mean. On the other hand, on a server application a REPL on exception wouldn’t help me.
marcrosoft 8y ago
Congrats. I'm trying to learn Common Lisp for great good. And, I love that lisp is still alive. I think we still haven't learned all that lisp has to offer. For me personally, I think Clojure (or any lisp) targeting Go would be awesome. The JVM lacks a killer Go "feature" which is _native binaries/easy deployment. Common lisp and many other lisps lack community which is why I think Go+Lisp would make a great combo. Go, even though it is a new language, already outpaces (a much older) Common Lisp as far as libraries go due to the huge community Go has. I know there is `zygomys` but it doesn't reach Clojure popularity/maturity. Can Clojure target Go? Edit: Maybe it is infeasible but I think targeting JVM, Go, and JavaScript would give Clojure a ridiculous advantage over almost any current programming language.
- xapata 8y ago
  All you'd need is a Clojure to Go compiler. A simple matter of implementation (joking). The good news is that Clojure is relatively easy to tokenize and has a simple grammar. Go v1's lack of generics would make the implementation tedious, but the features announced for Go v2 should make it easier.
  - fcurts 8y ago
    A more feasible option is to compile Clojure byte code to native code with GraalVM (http://www.graalvm.org/docs/reference-manual/aot-compilation/ http://www.graalvm.org/docs/reference-manual/aot-compilation...). GraalVM's native compiler still has some limitations but is coming along nicely.
- oweiler 8y ago
  No need for Go, GraalVM already allows you to create a native binary: https://www.innoq.com/en/blog/native-clojure-and-graalvm/ https://www.innoq.com/en/blog/native-clojure-and-graalvm/
- KingMob 8y ago
  As fcurts below mentioned, [Graal's native image generation](https://www.graalvm.org/docs/reference-manual/aot-compilation/ https://www.graalvm.org/docs/reference-manual/aot-compilatio...) might be what you want. It can turn a Clojure app into a single executable with excellent performance and memory characteristics.

355 points by finalfantasia 8y ago

I'm so excited about all the error messages work on this release! Also, the new metadata and tap functionality creates so many possibilities. And Java 8 minimum guaranteed so we can build things on top of java's time libraries and trust they will be there. Nice work everyone!

jwr 8y ago

From the perspective of a (fairly large-scale at this point) app developer: I find it great that Clojure places such emphasis on backwards compatibility. In general, migration to newer Clojure versions is completely painless. The language has been designed by experienced and mature people and doesn't go through "let's throw everything out and start again" phases like so many other languages do.

agumonkey 8y ago
I was a bit sad that the changelog was so small. Then I realized that maybe core features were stable and that's it, what was needed wasn't big beside spec and a few other things.
- puredanger 8y ago
  A lot of the year's effort went into things outside core - 2 releases of spec, 2 releases of core.specs, many releases of tools.deps.alpha / clj, tools.gitlibs, new release of REBL, etc. Lots of small fixes and enhancements in core too.
  - agumonkey 8y ago
    blame it on rich, I'm addicted to revolutionary talks about collections that brings speed and expressiveness enhancement for free :p
trevor-e 8y ago
> The language has been designed by experienced and mature people and doesn't go through "let's throw everything out and start again" phases like so many other languages do. Swift was designed by highly experienced and mature compiler devs and is notorious for making breaking changes. It's just a difference of opinion. I prefer to suffer the occasional upgrade pain in exchange for clean and consistent APIs. And I totally understand those who don't want to deal with that. Although to be fair to them, Swift is much younger than Clojure and the number of breaking changes has steadily declined with each major release. In seven years maybe they will take the backwards compatible approach too.
- tombert 8y ago
  I'm in the same boat; I work for a company that's been around for awhile, and as a result they've accrued a lot of Java code, a lot of it using deprecated APIs. It's quite frustrating to dig through them, and I would have been happier if Oracle had just phased out a lot of these things from the compiler (though my understanding is that JDK11 is making steps for that).
- jwr 8y ago
  > Swift was designed by highly experienced and mature compiler devs "Compiler devs". I think that is exactly my point. I should have said "app developers" or "system designers". If you listen to a Rich Hickey talk, you'll see that he is all about Getting Things Done in the real world, and much less about theoretical concepts. Language design is subservient to app developer needs.
  - krn 8y ago
    I would put it simply: Clojure was designed by a thinker, who creates when he is away from the keyboard, not in front of it. When one releases and breaks the code in his head first, very few breaking changes are left for the public releases.
    - JBiserkov 8y ago
      Rich Hickey is a great thinker. But he's also an application developer (Datomic). So breaking changes don't just break "other people's code" in the abstract. The pain is real and immediate. By wearing multiple hats he's finding the right balance in a way that language designers who don't code day-to-day simply can't.
porpoisely 8y ago
Clojure's emphasis on backwards compatibility is commendable, but keep in mind Clojure is still a very young language ( only about 10 years old ) so there isn't much backwards compatibility to worry about.
- KingMob 8y ago
  Maybe, but this was true even when Clojure was younger still. The language changes are overwhelmingly additive; Hickey places great stock in not breaking existing code.
  - thaumasiotes 8y ago
    I'm going to bring up again how + used to autopromote ints if your result was out of the primitive int range, and now throws an error instead.
    - KingMob 8y ago
      I didn't say there were no breaking changes, just fewer than most languages.
    - roenxi 8y ago
      If you want to demand perfection, then Clojure isn't going to meet your standards (what would?). The issue here is that, based on the way they (particularly Rich) talk, we can expect they will not do Bloody Stupid things like the old Python 2->3 changeover. Things like big, breaking changes that require architectural changes to keep current, or break all the available tutorials. If the problem can be fixed with a macro or single function (like a change to plus behavior) it is an irritant, not a threat to productivity. That is not a concern.
      - thaumasiotes 8y ago
        You don't think a breaking change to + is any more significant than a breaking change to some other part of the language?
thaumasiotes 8y ago
Didn't Clojure change the + function (hardly obscure!) from automatically updating ints to bigints and therefore never overflowing to throwing an exception if you added ints that were too big? I've got a Clojure book with a spirited defense of why it's good that the simple symbol + just does what you'd expect instead of throwing exceptions based on an implementation detail, and it kind of falls flat now.
- puredanger 8y ago
  That was over 7 years ago, so not particularly recent. And you can get the auto-promoting behavior with +' instead.
- solussd 8y ago
  Yes, very early in Clojure's life and only after testing the change across several popular libraries.
atarian 8y ago
Which languages threw everything out and started again?
- fiddlerwoaroof 8y ago
  Python 3, Perl 6 it looks like Scala 3 is heading that way too.
  - xapata 8y ago
    Python 3 is quite similar to Python 2. They made some breaking changes, but nowhere near like Perl 6. The real stumbling block was str vs unicode, which they didn't realize would be such a pain when making the decision. There's breaking changes and there's writing a new language. It's a spectrum.
    - deleted 8y ago
      [deleted]
    - jwr 8y ago
      My computer has at least three different Python versions installed. I'd say that's a pretty big backwards compatibility problem. There is also Perl 6, and I've recently read about Go 2. Swift changes every couple of months in incompatible ways.
      - xapata 8y ago
        I also have several Pythons installed. For me that's because of incompatibility between community packages I've installed, rather than differences in Python versions. Unfortunately, the various smaller communities can't always stay in sync. Right now there's a conflict between XGBoost and NumPy using MKL on MacOS. That's not a Python problem, exactly, as the issue is conflicting use of OpenMP, written in C, C++, and Fortran.
    - b2gills 8y ago
      It also seems like all of the changes in Python are all changes that Perl5 has done over the years without breaking backwards compatibility. Unfortunately this does mean you often have to opt-in to the new functionality. use v5.24; use feature 'unicode_strings'; use feature 'fc'; use feature 'postderef'; … Note that the `'postderef'` feature is now always enabled so that line is pointless if you use a new enough version of Perl5. The `'unicode_strings'` also isn't always necessary.
lsh 8y ago
S-expressions are perhaps partly responsible as well. They don't suffer the same brittleness as regular programming languages (is there a word for non-s-expression languages like c/python/etc?).
- EuAndreh 8y ago
  M-expressions: https://en.wikipedia.org/wiki/M-expression https://en.wikipedia.org/wiki/M-expression
  - lsh 8y ago
    that's a great link, cheers
- snorremd 8y ago
  I think so as well. When you have macros and can add syntax and features to a language at will, then the language and core library does not need to be very big. This probably helps immensely when trying to avoid breaking changes. New macros can very well be prototyped and battle-hardened in external libraries before being added to core.

brolester 8y ago

Woohoo?

casion 8y ago

The new error messages are fantastic. Clojure just went from one of the most annoying languages to debug to mid-top tier. More complex things still present you with overly complex errors, but with some painless repl usage it's way easier to figure out things now. Kudos.

Sharlin 8y ago

Any examples of what the new error reporting looks like? The release announcement is rather lacking in details.

lsh 8y ago
fwiw: https://gist.github.com/lsh-0/173f1a11e2e76f718c002607c8fa1e0f https://gist.github.com/lsh-0/173f1a11e2e76f718c002607c8fa1e...
puredanger 8y ago
I did a write-up that should give you an idea: http://insideclojure.org/2018/12/17/errors/ http://insideclojure.org/2018/12/17/errors/

kbd 8y ago

Are there any plans for a native version of Clojure? I'd rather avoid the JVM if possible, but I suppose the whole ecosystem is dependent on it so that's unlikely?

reilly3000 8y ago
Its often referred to as a guest language. The syntax is largely the same across JVM, CLR, and JS V8. The aim was to utilize the richness and reach of the most popular ecosystems, so all of Maven and npm are available to Clojure devs. The language should be able to be consistent across future runtimes with largely the same semantics.
preordained 8y ago
I guess I might ask what this stance is founded on? The JVM is just a binary that runs byte code. It's stable and runs well pretty much everywhere. If you insist the JVM has cooties, you could use Docker and abstract it away, it might be an ideal way to use it anyways depending on your work. The JVM /= Oracle JVM by the way. There is OpenJDK EDIT: Also I think recent Java releases have gotten into making self contained binaries (which just means they package the JVM...it's in there, it might jump out and bite you!). But, as long as you are careful what you are shipping, packing up a JVM has always been an option
- kbd 8y ago
  > I guess I might ask what this stance is founded on? Kotlin has Kotlin/Native, so I was hoping there might be a similar initiative for Clojure. But, a few reasons: * Startup time * Ability to deploy/share a binary * The JVM just seems so "heavy" to me. It's certainly the only language runtime I know of that runs a persistent helper app, or asks to install an Ask toolbar upon installation. * Bias against Oracle and Java > Also I think recent Java releases have gotten into making self contained binaries TIL, thanks. Edit: edited.
  - lsh 8y ago
    > Startup time Java is not as bad as you think. Clojure does takes a little longer though > Ability to deploy/share a binary there are jar files, but I know what you mean. Interesting work happening in GraalVM land: https://www.innoq.com/en/blog/native-clojure-and-graalvm/ https://www.innoq.com/en/blog/native-clojure-and-graalvm/ > Bias against Oracle and Java yeah, well ... we're all biased. It helps us make decisions quickly ;)

souenzzo 8y ago

Onde clojure is coded in edn, I think that is no reason to break changes. If one day we need to change something in core, we can make clojure.core2 and make the ns2 macro.

dannyobrien 8y ago

I've just started toying with Clojure, and while I've enjoyed it a great deal, the error messages were definitely one of the more unfriendly parts. Fortunately, my last two hobby languages were Elm and Haskell, so Clojure was always going to be in the middle between those two extremes). Good to see it being worked on!

billfruit 8y ago

While I like the language very well, tooling does have issues, even simple things like not distributing Leiningen with Clojure when it is almost essential for any serious development. Version incompatibilities between Leiningen and Clojure creates subtle problems. I also wonder what the experience of using lein in Windows, it seems to install using a mysterious batch file. The emacs based tooling had too many components, and is very brittle, ie, a minor version bump in one of the component often renders the whole build/repl process unserviceable. Usage of local jars is extremely difficult, you need to setup a local maven repository and then add dependencies through it, which is a very painful process, esp for hobby projects and prototyping. I should be working on my problem not wrangling with maven.

drcode 8y ago
Actually, I haven't used leiningen in 6 months, Clojure's new included cli tools work great these days.
- snorremd 8y ago
  I quite like tools.deps, but it is maybe a bit problematic that it is bundled with the Clojure install. Before tools.deps there were no officially sanctioned dependency and project management tool. This is probably why we got both leiningen and eventually boot. Now the bar for choosing something different than tools.deps is probably going to be quite high. Sadly tools.deps lack the support for reading credentials from a gpg/pgp-encrypted file: https://dev.clojure.org/jira/browse/TDEPS-9 https://dev.clojure.org/jira/browse/TDEPS-9 This is a shame as I rely on this to keep repository credentials safe. I'm not a fan of the maven master password system.
Skinney 8y ago
> While I like the language very well, tooling does have issues, even simple things like not distributing Leiningen with Clojure when it is almost essential for any serious development. Version incompatibilities between Leiningen and Clojure creates subtle problems. I also wonder what the experience of using lein in Windows, it seems to install using a mysterious batch file. Clojure bundles tools.deps since 1.9, and it works great. cljs and figwheel already supports it, as do many others. I prefer it to leiningen, but YMMW. I use emacs to develop clojure, never had any problems with it :/ > Usage of local jars is extremely difficult, you need to setup a local maven repository and then add dependencies through it, which is a very painful process, esp for hobby projects and prototyping. I should be working on my problem not wrangling with maven. tools.deps makes this very easy.

billfruit 8y ago

Nice to know that debug messages have improved. Ease of debugging would improve more, if an exception happens a live repl is spawned at that point allowing one to view locals/values, modify state, continue execution, etc. Most lisps allows such live repls for debugging like Scheme and Emacs lisp, while clojure only provides a stacktace on exception, and not a repl.

phyrex 8y ago
You can do that yourself if you care (https://m.youtube.com/watch?v=zp0OEDcAro0 https://m.youtube.com/watch?v=zp0OEDcAro0) but I get what you mean. On the other hand, on a server application a REPL on exception wouldn’t help me.

marcrosoft 8y ago

Congrats. I'm trying to learn Common Lisp for great good. And, I love that lisp is still alive. I think we still haven't learned all that lisp has to offer. For me personally, I think Clojure (or any lisp) targeting Go would be awesome. The JVM lacks a killer Go "feature" which is _native binaries/easy deployment. Common lisp and many other lisps lack community which is why I think Go+Lisp would make a great combo. Go, even though it is a new language, already outpaces (a much older) Common Lisp as far as libraries go due to the huge community Go has. I know there is `zygomys` but it doesn't reach Clojure popularity/maturity. Can Clojure target Go? Edit: Maybe it is infeasible but I think targeting JVM, Go, and JavaScript would give Clojure a ridiculous advantage over almost any current programming language.

xapata 8y ago
All you'd need is a Clojure to Go compiler. A simple matter of implementation (joking). The good news is that Clojure is relatively easy to tokenize and has a simple grammar. Go v1's lack of generics would make the implementation tedious, but the features announced for Go v2 should make it easier.
- fcurts 8y ago
  A more feasible option is to compile Clojure byte code to native code with GraalVM (http://www.graalvm.org/docs/reference-manual/aot-compilation/ http://www.graalvm.org/docs/reference-manual/aot-compilation...). GraalVM's native compiler still has some limitations but is coming along nicely.
oweiler 8y ago
No need for Go, GraalVM already allows you to create a native binary: https://www.innoq.com/en/blog/native-clojure-and-graalvm/ https://www.innoq.com/en/blog/native-clojure-and-graalvm/
KingMob 8y ago
As fcurts below mentioned, [Graal's native image generation](https://www.graalvm.org/docs/reference-manual/aot-compilation/ https://www.graalvm.org/docs/reference-manual/aot-compilatio...) might be what you want. It can turn a Clojure app into a single executable with excellent performance and memory characteristics.