collection-strawman

Scala experimented[0] with implementing those in its standard library. I'm not sure if it made it in to the final release or not. EDIT It looks like it did make it in: https://github.com/scala/scala/commit/d5ae93e1b35fac4002cfbf... [0] https://github.com/scala/collection-strawman/issues/192

Well it won't solve the biggest problems with interop https://github.com/scala/collection-strawman/issues/283 (sadly). I mean I can understand all the reasons not to, however It's just a pita that there is no sane way to do it, besides reimplementing either two api's or come up with your own collections.

Adoption (especially in industry) takes time, but there's definitely interest in the Clojure and Scala communities. The CHAMP data structure was already picked up by the ClojureScript community (https://github.com/bendyworks/lean-map), but still requires some work to be upstreamed to Clojure I guess. I personally (I'm the author of the thesis linked above) plan to work together with the Scala folks at Lightbend for the collections overhaul that's planned for Scala 2.13 (see https://github.com/scala/collection-strawman).

I like that BuckleScript has chosen the module-by-module design, if only to explore more design space than what was previously done in Scala.js and ClojureScript. I do not think this is what makes the 150 KB tax of Scala.js, though. The dead code elimination of Scala.js is really good, plus we combine it with Closure as well. But it faces a very difficult challenge: the entanglement of the Scala standard library. The collection library was designed when the JVM was the only target, and decoupling within the collections library was definitely not in the requirement set. This is why, once you touch the Scala collections library in Scala.js, you receive 150 KB worth of (non-gzipped) code. There is currently a large-scale effort to redesign the collections library for Scala 2.13 [1], with, among others, a desire to reduce inter-dependencies (