They did cite a significant performance boost as a side effect. On Fri, Jun 21, 2019 at 21:04, Sean Corfield <s...@corfield.org> wrote:
> I got the impression this was the primary reason for Storm’s rewrite: > > > > While Storm's Clojure implementation served it well for many years, it was > often cited as a barrier for entry to new contributors. Storm's codebase is > now more accessible to developers who don't want to learn Clojure in order > to contribute. > > > > 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:* clojure@googlegroups.com <clojure@googlegroups.com> on behalf of > Nathan Fisher <nfis...@junctionbox.ca> > *Sent:* Friday, June 21, 2019 4:17:43 PM > *To:* clojure@googlegroups.com > *Subject:* Re: Java Interop on steroids? > > 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 > <https://groups.google.com/d/msgid/clojure/CA%2Bc2dWdFKexJEjAtmt2qt2JD%3DUo5FvxeM1kZATBSwU5K6n9b1Q%40mail.gmail.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/MWHPR2201MB1134DA8985E3FEBE75B43B63F4E60%40MWHPR2201MB1134.namprd22.prod.outlook.com > <https://groups.google.com/d/msgid/clojure/MWHPR2201MB1134DA8985E3FEBE75B43B63F4E60%40MWHPR2201MB1134.namprd22.prod.outlook.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%2Bc2dWeiUnbb23R1fwaEE8PCx7R4gVYdb_6r0SwRTUcCpVhPsg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
