I've worked on several projects where Zing was considered as a solution to a few problems (normally GC pauses due to really large heaps). But in the end we never trailed it, due to a few factors:
1) Zing isn't super cheap, it's not that expensive in the grand scheme of things, but it's an additional cost that had to be added to a project, normally towards the end when heap sizes or other such things become a problem. So it's hard to go to management and ask for an increase in budget. 2) There really isn't a lot of documentation freely available as to how much Zing helps in a Clojure app. Chicken-and-egg problem here, need more experience reports to justify the cost, but it's hard to justify the cost of doing tests with such limited information. 3) Servers and ram are cheap in comparison. So often it was simply cheaper to create split services up, or partition data in a way that heap sizes could be reduced. Even something as simple as reducing the JVM heap size and using memecached on the same box was a cheaper way to solve the problem. 4) Algorithm changes were also cheaper. In a few cases we moved from using Clojure's persistent structures to off-heap structures like ChronicleMap or LevelDB. Or simply walk over the code in question and find ways of storing less in memory, or caching aggregates instead of whole collections. In the end there's a theme here. At about 2/3rds of the way through the project we'd hit an issue with HotSpot and say (hey Zing would help here). But switching JVMs would require an additional investment. But we already had a team, so it was simpler to spin off a few developers and have them solve the worst of the issues and perhaps let a feature slip. In the end, a small feature not getting in is easier to justify than the purchase of a new JVM. So I wish I could work with Zing someday, but each time I've gotten close, a cheaper solution has presented itself. Timothy On Mon, May 21, 2018 at 6:00 PM, Matching Socks <phill.w...@gmail.com> wrote: > IBM Java likewise has not excited very much conversation here. Perhaps > because Java is "write once, run anywhere"! The various implementations of > Java have their strong and weak points, but they will run Clojure in any > case. > > -- > 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. > -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- 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.
