Thanks -- I had seen some Clojure startup benchmarks in relation to Java 9:
https://mjg123.github.io/2017/10/04/AppCDS-and-Clojure.html. I did try these
on one of my projects that uses a lot of Clojure library deps and I went from
~11 second startup to ~5 (both were AOT/direct linking compiled).
I appreciate the discussion. I think it's helped me think a little more
clearly about what my goals/requirements are. I started thinking about why
I've chosen to use any JVM language over just plain Java. After all, no JVM
language is going to execute faster or have more support behind it than Java
itself. I won't enumerate all the reasons writing Java code is more painful
than <other language here> code as the reasons are mostly personal per
developer, and I'm guessing that most people here in this particular forum have
already come to the same conclusion.
I'd love to know why people here have chosen Clojure. Everyone chooses it for
persistent data structures and functional programming, as Clojure essentially
forces you to use them. I've found structuring my code that way seems less
prone to bugs and more reusable and compose-able. However, with Java now
having lambda functions it's possible to get *some* of the same advantages
there.
For me the selling point of Clojure was the learning a lisp. My motivation for
wanting to learn a lisp, and the fact that Clojure was so perfectly practical I
could potentially use it professionally (JVM!) started me down the path. Where
I hoped I would end up is leveraging macros. I've always done a lot of code
generation in my Java projects... from things like using templating languages
to generate java source files to using annotations to generate additional java
code at compile time. What I've found with Clojure and macros is -- it's
sooooo much easier to do those same things. I know there's a huge emphasis in
the Clojure community (and maybe all lisps) of not over-using macros... and I'm
not disagreeing with that. But to me that's the heart of why I would ever use
a lisp.
So finally full circle (back to Kawa)... *my* primary benefit of Clojure could
be summarized as "JVM + Macros" (which to me is orthogonal to the
immutable/functional benefit - as it is possible to program this way in other
languages, and I'd argue writing in Clojure/<another JVM language> usually
limits projects to small teams of experts and on those types of teams it would
be possible to be disciplined enough to do so in a language that doesn't force
it). Kawa has "JVM + Macros" (though at the moment I find scheme macros much
less approachable than CL or Clojure macros). It also has different
development trade-offs, but the things I like:
- Little to no overhead over plain Java
- I think this would make it sell-able in the enterprise world for
*libraries* or *part* of a project. Could a couple of experts using Kawa
replace a lot of the code I used to generate in far more awful ways than macros
(templates or annotation processors)? If Kawa easily compiles to Java and has
good code completion (i.e., not IFn passing Objects but actual static method
definitions with types)... I bet "regular" Java-based software projects
wouldn't mind consuming libraries written in Kawa. And if there wasn't a 10-20
second startup penalty for using the library... (even though I know, in
"situated" programs this really doesn't matter at all -- but it does from a
language adoption standpoint. I think I couldn't convince a project to let me
write a library in Clojure if it took 20 seconds to load the library).
- Still has macros and sexps
- I prefer Clojure's syntax to scheme (maybe just because I'm used to it).
But it's really the same argument people have against using Clojure
(parenthesis :-)). Other low overhead JVM languages like Scala don't have
macros.
- I could still use Clojure's data structures and even STM from Kawa
- Clojure's runtime is very approachable and a beautiful piece of software
(I don't even mind the Java source formatting -- reminds of C# actually -- why
indent *everything* when the language says you must have a top level "form"
(namespace in C# / class in Java? :-)). Using its data structures and even STM
would be very straightforward.
My motivations in writing here is to get people's feedback about using Kawa /
other lisps when their main motivation is to stay in the JVM ecosystem. I'd
love to see both Kawa and Clojure be so easy to intertwine into a larger Java
project that they could be used even within large enterprise-y Java projects
(for some portion of the project). My interest in that is mostly personal :-).
I think using them in this manner would be a real benefit to both those
projects and to developers on them. That's what gets me excited about Kawa --
I think I maybe I could sell it's use as a library in a large corporate project
simply because there's no runtime overhead.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On April 5, 2018 4:00 AM, Didier <didi...@gmail.com> wrote:
> I'd recommend you try some of the startup optimizations for the JVM that
> zprint does:
> https://github.com/kkinnear/zprint/blob/master/doc/filter.md#we-all-know-that-clojure-startup-is-so-slow-that-this-will-not-work
>
> With it, they've managed to get the Clojure zprint filter to start faster
> then the equivalent ClojureScript one.
>
>
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> You received this message because you are subscribed to the Google
>
> Groups "Clojure" group.
>
> To post to this group, send email to clojure@googlegroups.com
>
> Note that posts from new members are moderated - please be patient with your
> first post.
>
> To unsubscribe from this group, send email to
>
> clojure+unsubscr...@googlegroups.com
>
> For more options, visit this group at
>
> http://groups.google.com/group/clojure?hl=en
>
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
>
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
