That is likely more to do with doing a full rewrite with 5+ years of learned experience under their belt than any insurmountable performance issue by Clojure.
(Storm was mostly Clojure from day one but always had Java code in the mix, as well; in other words, they've always had Java if they had needed it... so crediting their perf gains to the PL switch is suspect imo.) On Sat, Jun 22, 2019 at 2:48 PM Nathan Fisher <nfis...@junctionbox.ca> wrote: > 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 a topic in the > Google Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/Yi922qYALg8/unsubscribe. > To unsubscribe from this group and all its topics, 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 > <https://groups.google.com/d/msgid/clojure/CA%2Bc2dWeiUnbb23R1fwaEE8PCx7R4gVYdb_6r0SwRTUcCpVhPsg%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/CAFahMUr%3D0pOwgiU9wJhh6rFZ9WrC9K6BGjO3cs7_nHZ4VEmAKA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
