Clojure 1.8
blog.cognitect.com
blog.cognitect.com
https://skillsmatter.com/skillscasts/7225-cider-the-journey-...
I think that particular point is somewhere towards the end of the talk.
http://clojure.github.io/clojure/clojure.core-api.html#cloju...
http://conj.io/store/v1/org.clojure/clojure/1.6.0/clj/clojur...
The design never bothered me, the issue I have is that docs are all over the place. I would like to see documentation consolidated, with improved completeness, and better search. To get there, it needs to be easier for developers to contribute to clojure.org, instead of spinning off their own version of docs, which seems to be the case at the moment.
Just for a glimpse of the documentation landscape, and what it's like getting started, here are the resources I've touched on:
* Main reference pages (recently redesigned) are nice for getting a high level gist of something, but I found it doesn't go in depth enough to really understand atom/transient/transducers/etc. [1] I walk away with a sense of: "sure, this all sounds good in theory".
* Main API docs are helpful for reference once you understand what's going on, also useful for finding new things to research elsewhere. [2]
* I've discovered there are wikis on the libs that have really good examples, but they're not complete, and I will still have to Google for more examples by people writing blog posts. [3]
* Clojuredocs has decent search, and sometimes people comment on a function with a good example. But most of the time comment unfinished code that's really misleading. [4]
* Google is really the best resource for finding examples, explanations, and idiomatic usage. There are a lot of idiomatic things that are hard to uncover, like to zipping is done by `(map vector [1 2 3] '(a b c))`.
* The #clojure IRC channel has pretty low response rate of actually getting help with something. As compared to #node.js/#python/#postgresql. The community is smaller, so it makes sense, but it's discouraging.
* There are quite a few other websites, but I haven't found them useful, so I never check them. [5] [6]
[1] http://clojure.org/reference/agents [2] http://clojure.github.io/core.logic/ [3] https://github.com/clojure/core.logic/wiki/A-Core.logic-Prim... [4] http://clojuredocs.org/clojure.core/keep-indexed [5] http://clojure-doc.org/ [6] http://conj.io/
#clojure has always been up and down in terms of volume. These days, there are upwards of 5000 people on the Clojurians slack channel and pretty constant and helpful communication for chat. Join at http://clojurians.net.
From personal experience class io, verification, method linkage, and reflection play a big role in startup of jvm languages (along with call site target setting if you're using invokeDynamic bytecodes), but removing indirection helps for long running processes.
Yes, but Clojure itself is the one to blame for slow startup as it as been proven multiple times by community members.
http://martinsprogrammingblog.blogspot.de/2012/02/why-is-clo...
“[It] spends 95% of the startup-time loading the clojure.core namespace (the clojure.lang.RT class in particular) and filling out all the metadata/docstrings etc for the methods. This process stresses the GC quite a bit, some 130k objects are allocated and 90k free-d during multiple invokes of the GC (3-6 times), the building up of meta data is one big source of this massive object churn.”
See also:
Also, Clojure can be AOT compiled with direct-linking and elided metadata which alleviate some of the broader concerns (they're unlikely to affect a hello world type app though). See: http://clojure.org/reference/compilation
Var class loading is still a concern, so there is of course still room for improvement. Experiments in this area are ongoing. Delayed var loading has the significant downside of making every var call thereafter slower (as the code needs a guard to check whether the class has been loaded or not). invokedynamic shows some promise is getting the best of both worlds there.
That being said, I use Clojure for scripting tasks frequently and it isn't so bad. It just isn't as awesome as it could be.
POTENTIAL SOLUTION: I think for script startup time someone is going to have to bite the bullet and write some kind of nREPL client in a language with no startup time (Go, C, etc). Then you could just send code to be evaluated to already running environments. You could use boot.pods to isolate the Clojure runtimes. Seems straightforward-ish.
See as an example: https://github.com/georgewsinger/yaml-table
This script takes about 100 ms on my computer and about 2.25 seconds (!) to run via pure clojure on the JVM.
If the dependency jar has source files (.clj) and you transitively AOT compile your app with direct linking, then yes.
If the jar has class files (.class) then you won't affect that dependency jars calls within itself or out to other libs. But you can compile your own app to directly link into a compiled dependency if it was compiled with Clojure 1.8 (and has the direct methods to call).
Clojure core itself is AOT compiled (that has always been true) with direct linking on. So calls within clojure core itself are direct linked - how you compile your own code to call into them is up to the choices you make when you compile. Code compiled with direct linking actually retains both the direct and dynamic call paths so this is always a compile-time decision.
Now that's something!
A. Web tutorial intro B. Book
B) Living Clojure
Looking at half of JS language features, I could say that's bloated too.
- JAR dependencies and dependency hell. My project.clj is usually full of exclusions, forcing versions and stuff like this. - Logging. Oh my, how I hate everything about logging, from terribly documented .properties files, even worse documented logback.xml files, to appenders which drop messages at peak times and this log4j/slf4j mess.
On the other hand, startup times are ok. The biggest problem wrt to startup times is the nrepl-refactor JAR which I load in some profiles for refactoring features in CIDER. Probably not worth it.
http://blog.ndk.io/jvm-slow-startup.html
http://martinsprogrammingblog.blogspot.de/2012/02/why-is-clo...
If you program directly in Java it can be as fast as Nim or Go.
Granted, if you want AOT to native code, your only option is a commercial JVM.
Especially when Java 1.8 will hit these languages. It reduces build times and startup times since these lanaguages could share their bytecode when it comes to lambda's and such things. With -Xexperimental on Scala 2.11 and changing some things to lambda it will reduce the code size by 10-15% which is a lot in such a big codebase. And I think closure will have such stuff, too. This also means faster startup times. Also Java 9 and Java 10 will also help these languages to improve.
For a long time I played with the idea of using it as common code between Android and Windows Phone, but the performance on Android and outdated CLR support demotivated me to pursue it, so it was back to C++11 (now C++14) for common code.
Currently this will bring a big one: https://github.com/clojure/clojure/blob/master/changes.md#11...
Also Clojure isn't tied to Java 8, it's compatible back to Java 5, so this brings a lot of overhead.
We written a small ERP project and looking forward to have a calculation layer in clojure.
If it's still a concern, you can do what I did a while back and just write the app on top of Node.js. Then the startup time is more or less gone altogether.