Storm recently moved away from Clojure in its core. https://storm.apache.org/2019/05/30/storm200-released.html
I wonder how much of the legacy Clojure core could be optimised or if they reached an upper limit imposed by the runtime/architecture. That being said I suspect for 90% of orgs they'll never hit that boundary. On Fri, Jun 21, 2019 at 16:40, Chris Nuernberger <ch...@techascent.com> wrote: > Sean, > > That is an interesting blog post. Sorry if I am not following everything > but why not use the annotation support in gen-class for those types of > things? > > > https://github.com/clojure/clojure/blob/8af7e9a92570eb28c58b15481ae9c271d891c028/test/clojure/test_clojure/genclass/examples.clj#L34 > > On Friday, June 21, 2019 at 1:29:56 PM UTC-6, Sean Corfield wrote: >> >> You might be interested in how we provide type-based annotations on >> Clojure functions so that tooling (in our case New Relic) sees those >> annotations: >> >> >> >> >> https://corfield.org/blog/2013/05/01/instrumenting-clojure-for-new-relic-monitoring/ >> >> >> >> I agree that this could be a lot easier. >> >> >> >> Sean Corfield -- (904) 302-SEAN >> An Architect's View -- http://corfield.org/ >> >> "If you're not annoying somebody, you're not really alive." >> -- Margaret Atwood >> >> >> ------------------------------ >> *From:* clo...@googlegroups.com <clo...@googlegroups.com> on behalf of >> eglue <atd...@gmail.com> >> *Sent:* Thursday, June 20, 2019 9:03:45 PM >> *To:* Clojure >> *Subject:* Java Interop on steroids? >> >> Don't get me wrong, I'm as much against types as the next R̶i̶c̶h̶ >> ̶H̶i̶c̶k̶e̶y̶ guy. >> >> However -- there are many popular Java frameworks that love to reflect on >> their annotations and their generic type signatures. >> >> To name a heavyweight: Spring. But also, of late: big data frameworks, >> many written in Java, love reflecting on generic type signatures. My org is >> looking at Beam and Flink, for example. >> >> These frameworks use types not for the static checking really but as >> parameters governing their own dynamic behavior. For example, Spring will >> use types at runtime to simply match objects to where they should be >> dynamically injected. Beam will look at your type signatures and do runtime >> validations to ensure it can process things appropriately. Of course this >> is unfortunate, using types this way, when it is all really just data. >> Clojure does -- or would do -- it better, simpler, directer, and all of >> that. >> >> Yet we would like to leverage these frameworks. Or rather, we must for >> various pragmatic and business reasons. >> >> And any time we need to "communicate" to these frameworks "through" their >> desired fashion of generic types and annotations, we can, of course, create >> the appropriate .java files to represent what is needed (and then do the >> invocation back to Clojure via IFn.invoke or Compiler.eval, etc). Yes, this >> works. >> >> However this is quite tedious because in these frameworks I mentioned you >> end up having to create these Java files quite a bit. For example, when >> expressing a streaming data pipeline to Beam, you may specify multiple >> transforms, each a function with its own type signature. >> >> A little searching and it seems Clojure has shied away from generating >> generic type information in places where it could offer this capability. >> >> For example, in `proxy` ... or I suppose also in `gen-class`, `reify`, >> and other dynamic bytecode generation features of Clojure. >> >> However it seems to me that `proxy` (and these others) could allow one to >> pass in a representation of desired type arguments, annotations, etc. and >> then we could remain in Clojure to interop with these popular frameworks. >> >> I respect Clojure's efforts to keep its core small and wait for worthy >> features to prove themselves. >> >> So my question is not when is Clojure going to do this, but rather: >> >> Are there any precedents in the community for someone building out the >> kind of richer Java interop that I'm nodding toward here? >> >> For example, does anyone know of an attempt out there to build a `proxy` >> plus-plus, that would allow one to extend a generic class with provided >> type parameters and have this metadata properly rendered in the bytecode >> that proxy produces? >> >> If not, as a practical and hopefully quick and workable solution, I was >> thinking it'd be possible to take the bytecode emitted by proxy and re-run >> it through ASM to create a *new* class with simply the proxy-produced class >> bytes filled-in with the desired, provided type parameters. I bet this >> could be sufficient and fast, with the slight overhead of the extra class. >> >> To do this, I think I'd need access to these proxy-made bytes... either >> by having proxy answer them somehow, or offering a hook to contribute to >> the defined bytecode before it is committed to the classloader, or by >> having DynamicClassLoader have these bytes on hand for inquiring parties, >> or something else along these lines. This would likely be something that >> Clojure core would have to expose .. correct me if I'm wrong. >> >> Would love to hear any other immediate thoughts on this. >> >> I think once you realize that this generic type information is not even >> being used for "static typing" by these frameworks but rather as an (albeit >> poor) means to receive semantic information from their clients (as >> parameters to govern their own dynamic behavior), then the need/value of >> being able to remain in Clojure and communicate to these libraries through >> generic params and annotations perhaps becomes more understandable.. >> >> >> >> >> >> >> >> >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@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 >> clo...@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 clo...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/clojure/128dd732-b79e-4c35-999f-691cdc42512b%40googlegroups.com >> <https://groups.google.com/d/msgid/clojure/128dd732-b79e-4c35-999f-691cdc42512b%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/clojure/beca47df-4227-4d08-a71f-0e98e34a7acf%40googlegroups.com > <https://groups.google.com/d/msgid/clojure/beca47df-4227-4d08-a71f-0e98e34a7acf%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Nathan Fisher w: http://junctionbox.ca/ -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/CA%2Bc2dWdFKexJEjAtmt2qt2JD%3DUo5FvxeM1kZATBSwU5K6n9b1Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
