3 ms·

Q: What does java.lang.NoSuchMethodError: clojure.lang.RestFn.<init>(I)V mean? A: It means you have some code that was AOT (ahead-of-time) co

Q: What does java.lang.NoSuchMethodError: clojure.lang.RestFn.<init>(I)V mean? A: It means you have some code that was AOT (ahead-of-time) compiled with a different version of Clojure than the one you're currently using. If it persists after running lein clean then it is a problem with your dependencies. Note that for your own project that AOT compilation in Clojure is much less important than it is in other languages. There are a few language-level features that must be AOT-compiled to work, generally for Java interop. If you are not using any of these features, you should not AOT-compile your project if other projects may depend upon it. https://github.com/technomancy/leiningen/blob/stable/doc/FAQ.mdhttps://github.com/technomancy/leiningen/blob/stable/doc/FAQ.md https://github.com/technomancy/leiningen/blob/stable/doc/FAQ...

jamii 13y ago
I've never even seen AOT compiled code. If it becomes common (maybe in proprietary projects?) then I would argee that its important to maintain binary compatability.
- happy_dino 13y ago
  I just wanted to highlight how bizarre this discussion has become in general (nothing against you, it seems to be a common theme): “““ I'm unhappy with Scala's compatibility guarantees, therefore I'll pick a language which a) does not provide any binary compatibility guarantees at all, b) has no tool to figure out whether incompatible changes have actually happened, c) lacks any sort of guidance to figure out if library A is compatible with library B short of downloading and executing them together, d) provides no clean way to cross-compile libraries against multiple versions. But hey, let's bash Scala for caring about these issues and deride them for shipping actual, working solutions addressing those issues. ””” Scala guarantees: - Source compatibility between major versions - Source and binary compatibility (both backward and forward) for all minor and update releases of that major version People will have a hard time to find another modern language which gives them these guarantees. Hypocrisy and cognitive dissonance FTW, I guess.
  - jamii 13y ago
    I was not 'bashing' scala. I discussed the tradeoff between removing old cruft from the language and breaking old crufty code. I was careful throughout that entire comment to only discuss differences between the languages and communites and not make or imply any value judgement. I'm trying to provide useful information for people deciding between scala and clojure, not start a fight. With regards to binary compatibility, what I think you are missing is that clojure libraries are almost always distributed as source code. The clojure compiler is fast enough to just compile everything at runtime (during development at least) and clojure has not broken source / api compatibility since the first major version. Where AOT compilation is useful is: a) Improving application startup time b) Shipping libraries which generate java classes at compile-time (usually to c) Shipping proprietary libraries without source code I would definitely like to see the community figure out binary compatibility between libraries to improve cases b and c but it's really not a pressing concern. EDIT: On AOT compilation http://dev.clojure.org/pages/viewpage.action?pageId=1572898 http://dev.clojure.org/pages/viewpage.action?pageId=1572898
    - happy_dino 13y ago
      Fair enough, as mentioned, it was not targeted at you. Sorry if I didn't make that clear enough. I was mainly summarizing my impression of the (sad) current standard of debate in interested circles.
  - Uchikoma 13y ago
    1. Java. 2. The problem of binary compatibility is two folded: a. What Scala considers major versions (usually minor changes) b. An open source library community that jumps to beta Scala releases for minor updates These two together create a nightmare to upgrade libraries or Scala versions
    - happy_dino 13y ago
      > 1. Java. I said "modern language". > 2. First, the changes are too large, then the changes are too small? What now? It's bad if new Scala versions don't ship with full-scale library support, but it's also bad if developers start testing their libraries early? I guess it is impossible to make you happy.

jamii 13y ago

I've never even seen AOT compiled code. If it becomes common (maybe in proprietary projects?) then I would argee that its important to maintain binary compatability.

happy_dino 13y ago
I just wanted to highlight how bizarre this discussion has become in general (nothing against you, it seems to be a common theme): “““ I'm unhappy with Scala's compatibility guarantees, therefore I'll pick a language which a) does not provide any binary compatibility guarantees at all, b) has no tool to figure out whether incompatible changes have actually happened, c) lacks any sort of guidance to figure out if library A is compatible with library B short of downloading and executing them together, d) provides no clean way to cross-compile libraries against multiple versions. But hey, let's bash Scala for caring about these issues and deride them for shipping actual, working solutions addressing those issues. ””” Scala guarantees: - Source compatibility between major versions - Source and binary compatibility (both backward and forward) for all minor and update releases of that major version People will have a hard time to find another modern language which gives them these guarantees. Hypocrisy and cognitive dissonance FTW, I guess.
- jamii 13y ago
  I was not 'bashing' scala. I discussed the tradeoff between removing old cruft from the language and breaking old crufty code. I was careful throughout that entire comment to only discuss differences between the languages and communites and not make or imply any value judgement. I'm trying to provide useful information for people deciding between scala and clojure, not start a fight. With regards to binary compatibility, what I think you are missing is that clojure libraries are almost always distributed as source code. The clojure compiler is fast enough to just compile everything at runtime (during development at least) and clojure has not broken source / api compatibility since the first major version. Where AOT compilation is useful is: a) Improving application startup time b) Shipping libraries which generate java classes at compile-time (usually to c) Shipping proprietary libraries without source code I would definitely like to see the community figure out binary compatibility between libraries to improve cases b and c but it's really not a pressing concern. EDIT: On AOT compilation http://dev.clojure.org/pages/viewpage.action?pageId=1572898 http://dev.clojure.org/pages/viewpage.action?pageId=1572898
  - happy_dino 13y ago
    Fair enough, as mentioned, it was not targeted at you. Sorry if I didn't make that clear enough. I was mainly summarizing my impression of the (sad) current standard of debate in interested circles.
- Uchikoma 13y ago
  1. Java. 2. The problem of binary compatibility is two folded: a. What Scala considers major versions (usually minor changes) b. An open source library community that jumps to beta Scala releases for minor updates These two together create a nightmare to upgrade libraries or Scala versions
  - happy_dino 13y ago
    > 1. Java. I said "modern language". > 2. First, the changes are too large, then the changes are too small? What now? It's bad if new Scala versions don't ship with full-scale library support, but it's also bad if developers start testing their libraries early? I guess it is impossible to make you happy.