What Sucks about Clojure and Why You'll Love It Anyway Chas Emerick

why closure sucks and why you love it anyway and I'm I'm not afraid to admit that probably for the first time in quite a while I'm nervous giving a talk I think rightly I'm giving a closure sucks talk at a closure conference but there are mitigating factors that's the that's that's the point that's the point so I've been using closure for a long time I think I'm if I can count right I'm into my fifth year of using closure seriously into the fourth year roughly of using it in production environments and things like that so along that path I learned a lot about closure obviously about the things to avoid the things to really really recommend it but in particular writing the book with my great co-authors Brian Carver and Christophe Grande it really forced me to crystallize what about the language was excellent and what about it you needed to avoid mitigate or board or otherwise just deal with in order to do the work that you need to do because I needed to we needed to communicate to people who had never touched closure ever and communicate using not the most ideal medium perhaps so between that and you know hanging out an IRC for way too much time I thought this would be a good time to sort of present a high level discussion about what what the things are in closure that are that are a little difficult little warty things things you might want to avoid and and and how to work around those things so what I'd like to do is is do that I put holistic here that's not right really it's a grab bag of things that I think are worth talking about from a pragmatic users perspective of course if you're using closure for just hobbyist for you're doing research with it then some of these may not apply to you but I've always been using it in a commercial setting and so that's where a lot of my experience and my bias comes from and really what I want to do is answer the question that you may have if you've just started using closure you're considering using closure what will you wish you had known now a year from now or 18 months or 24 months I don't think there's gonna be anything anything groundbreaking here but just some things to think about and honestly my main objective is to get out of the building alive I'm surprised rich isn't right there with a bunch of tomato stack in front of them but but seriously I worried about the premise after I submitted the talk and it was accepted and I and I really needed to do more than just have notes and things like that because it's really easy to write a flaming blog post right you can say X sucks closure sucks Scala sucks the JVM sucks and throw it on on the internet and you know the next day is like the last but I think it's harder and hopefully more rewarding to try and have rational discussion about the shortcomings of something that we all enjoy that some of us love that some of us have built our livelihoods around so that maybe we can have some productive motion towards addressing those or building practices that everyone is aware of and can can and can communicate effectively to new people that they're bringing into the fold so that you know we can we can address the things that bug us the most and improve the environment for everybody and I was reminded while I was putting these slides together of the monologue at the end of ratatouille by the food critic who talks about the the risks of being a commentator and the damaging effects that sort of reflex criticism can have with in a world where you want to encourage the things that are new and innovative just throwing out how something is unusable if it didn't work in my circumstance so it sucks that's not adding much to the world and for the things that are innovative and new like closure you know the the it needs friends and it needs friends that aren't irrational that aren't that that aren't blind Evangelist to the thing that they think is the best and there was a recent blog post about how your favorite programming language is not enough and the real point of that is that you don't want to be partisan you want to have balanced approach the things and look at what can closure learn from other languages at just as much as what could you learn from closure so I'm going to measure the success of this talk by how many times people giggle about the topics that I put up yeah namespaces namespaces are tough namespaces are tough in general right I mean closure namespaces are really good compared to a nearly any other language I can't think of one that I would rather and I can't think of a name spacing system or a modularity system that I would rather have over closures however this large batch of complexity you know what is required do what is used to what is referred to how do they interact what should you use you know what are the what are the traps that are waiting for you when you blindly refer namespaces all over the place the whole notion of our immigration and things like that there's a there's a lot of complexity here and I think it's no one's fault none of this is anybody's fault this was a great experiment that was put together one of the oldest things in the language outside of like the core compiler and core library and things like that and it served us very well and will continue to serve us very well but there's a lot of complexity here and people trip on it every single time I still trip on it in terms of what should the best combination of require and use be maybe you should always use use with a empty only list and use an alias so then you can add in things that you want to use in blindly easily and things like that and then there's this hole do you need to quote your lip specs or not in what context you do you write you need to use the colon and the NS form although not really anymore because anyway it's it's it's complicated it shouldn't need to be like this right one really concrete problem especially for those of us that do a lot of Interop is that there is no package wild card import and I do maybe more interrupts than most maybe less I don't know but I know that when I'm working with a library and I need to touch 25 40 classes within that Java library which has happened you have an entire screen filled up with your your your import clause because you need to enumerate every class and there's ways to do this and there's what and there's utilities that will automate that out but it's not part of the base functionality of import and so very few people do use it I'll take questions later then there's this is a little more subtle so when you resolve the value of a var here this value G in some namespace you you get the value of it you don't get the bar and we were actually just talking about that myself and a couple of our people were talking about those last night the one on the left you get the value of G say it's a function on the right you get the VAR containing that value that function G it's essentially equivalent if you are simply loading into an application and running stuff however when you're in a development environment and you want to connect using a rebel and modify code at runtime and do those all those interactive development things that make closure extraordinarily productive if you know how to use those tools and you use the form on the right in exactly the right spots then if you reload the code that defines G for some code in some namespace five levels down in its transitive dependencies then you'll see that result immediately whereas if you use the form on the left you won't and that's a two character change in heads it's a very subtle tripping point for people that don't understand the the correspondence between or that don't understand how VARs and resolution work and the implication of that with regard to interactive development and this one gets me all the time so if you have a type that you define in some namespace and types and records and protocol boil down to host classes and interfaces you can't just import it right foo needs to have been loaded here in order for the type a type to be imported and I I do that on a weekly basis where I hit import some namespace or in this case package and type and it fails what's going on five minutes later all right I don't have a require for that and so that's that that's something I hit every single time it's a point of repetition that shouldn't need to exist and I'm gonna go through these last couple of relatively quickly in larger applications you often have a bunch of utility functions that are coming from internal libraries that you're using and you use them everywhere and you want to be able to have them available everywhere and often you need to just copy and paste here of my namespace declaration copy and paste twiddle a couple of things as opposed to saying my new namespace a should be like my old namespace be with these modifications and again there's other there's alternative implementations of the namespace modification functions like NS and require and things like that that provide this but you need to be aware of them and use them if you want to and this is this is a personal gripe of mine if you load a namespace and some transitive dependency fails to load you've got a typo somewhere now you have a closure environment with half loaded namespaces all over the place and that's always bother me from an introspective and a introspection and tools perspective because now you have VARs listed and like outlined browsers and things like that that haven't been loaded properly or don't have their dependencies available properly and so I've always wanted code loading to be transactional and obviously there's side affecting things especially when you're you know loading configuration files from disk in a top-level form or you're initializing Java classes and things like that but I've always wanted namespaces to be transactional insofar as when you perform or require or use those bars that go into the namespace or either there or they're not in their full form or not and I know there's bootstrapping issues around that but it's something that's always earthly so that code doesn't work right and it doesn't work because closure doesn't support any notion of forward references you in in this case prior to Maine you would need to have a form that says declare helper in order for the compiler to resolve the interned helper bar and this is unfortunate because it's one of the few places where closure forces the programmer to babysit the compiler you know when you are writing a library that you want to be amenable to someone understanding it later on whether it's a teammate or you six months later personally I've always liked to have the highest level functionality be at the top of the file because when you open up your buffer there's your entry point you know maybe it's an API with ten functions you want to see what the shape of the API is not this however many lines of helper functions and implementation details that you often need to wade through that people leave at the top of the file so they don't have to use declare in order to get the bars in turn first and all this drives out of what for a lot of people is the is is closures unintuitive compilation unit so most other languages the compilation unit is the file or the class or something like that whereas in closure it's the each top-level form is a compilation unit dynamic scope and I have a long history and not a very not a very positive one overall I think it's a very common pattern especially in say database libraries so JDBC CouchDB MongoDB database libraries they all have this pattern where there's a function or a dynamic bar that you need to bind with some configurations so you know with Foos with database or with mug or whatever it happens to be and then you can perform your database operations within the scope of that binding form without repeating that configuration over and over and over and that's great you know I'm I'm all for concision I don't like verbosity but dynamic bars the dynamic scope comes with a price in that fundamentally every dynamic bar ends up being an implicit argument to every function that you happen to be working with and you really see this when you look at documentation like if you look at the code completion pop ups and slime or in counterclockwise you're gonna see the arguments to the function right takes this function takes ABC it's not going to have an entry saying oh by the way you need to go bind this bar in order for this function to work and it gets even worse than that when the top level of an API isn't the thing that touches the dynamic VAR maybe it's another bar three levels down in another library and you need to make sure that you've called whatever appropriate set up function needs to happen in order to set up that that's scope and it's this is mutable state right and we all know what mutable state is it creates complexity it makes it very difficult to understand what's going on within a library it makes it more difficult to test functions so in this case if you wanted to test function f you got to make sure that you're setting up your appropriate dynamic scope in order to make that test work out properly and so I found that especially in the past year or so I just stopped working with dynamic scope I stopped writing code that requires it and things get simpler maybe you pay a slight price in a bit more verbosity but I think it ends up being worthwhile in terms of having a clear mental model all the time where you look at the documentation here's the yard here's the arguments this function takes and I don't have to worry about anything else that that really goes to being able to focus at the problem at hand as opposed to understanding implementation details so binding conveyance is this thing where prior to 1 3 if you set up some dynamic scope and then start at a future or sent an action off to an agent that dynamic scope goes away within the context of the evaluation of that function which is which was very disconcerning is very disconcerning you're you're within a you know you're writing this function that's gonna go start a future or send something off to an agent you have a particular notion in your head of what your state is that you're working with and you send that action off you feel like you shouldn't have to think about the fact that this state's coming from a thread-local dynamic bar versus this state that happens to be a local argument right and I was one of the people that was whaling away at rich saying this was this is unpleasant you have to read you have to set up a new scope but with a an anonymous function and bind things out to use the same values as in your current dynamic scope for your future your agent action or whatever and so binding conveyance went in which means that your dynamic scope when you send off an agent or send an agent or start a future etc etc your dynamic scope will go along with you and I think that's a win overall but it ends up causing some problems when you don't want to have your dynamic scope go along with you it the the whole notion of dynamic scope and closures fundamental concurrency operations has been complected in this case so I think it's great for the common case but when you start working with circumstances where you don't want to have your binding your dynamic scope carried along with you binding conveyance can be problematic and so overall I think dynamic scope is sort of kind of considered harmful I don't think there's a lot of reasons to use it a lot of reasons to recommend it in general practice there are a couple of good scenarios where you need to use it for example auxilary returns so if you have a say an HTTP library with a function that you want to return the content of a get if you need to also get back the status code or headers or something like that but you don't want to always have to deal with a response map in the happy case for example then you can set up a binding that clients can opt into you can set up a dynamic bar that clients can opt into binding and then your library can set bang your headers or your response code which the client can then check if when it wants to and that's that's that's breaking things out nicely in in a way that doesn't make the bar an argument it's flowing in the other direction and it's often so software transactional memory is one of the marquee features of closure it is often cited as one of its most distinguishing characteristics certainly when it came around some years ago and was the only widely available and easily easy to use software transactional memory system it was and still is groundbreaking but using it effectively I believe is hard and it's hard especially insofar as it looks easy so tutorials and websites and books including my own have examples about how to use software transactional memory and because of the nature of examples and tutorials they use simple data models and simple operations in order to exhibit the characteristics of this system and you get you start to get a sense of oh this works well you know you have a you have a these six refs and a bunch of operations and here's some data coming in and you toss a bunch of threads in the air and things work out and you start to get the sense that well this is a little bit of fairy dust that you can sprinkle over your state and things will just work out well but it's not actually that cut and dry I mean the STM is essentially an in-memory database that has superior closure integration and when you think of it that way then you realize that there are that there's implementation details and semantics that go along with the STM that don't quite bubble up into the clean API and operations that you look at syntactically a couple examples of this one is ref granularity so Christoph wrote a great blog post about a month ago I think called the world and a ref where he talked about how it's difficult to determine for a given data model what the right ref granularity is so STM looks simple and easy and straightforward if you're using refs containing scape scalars right but if your data model is a complicated set of maps or a single map that represents your entire world that has 150 keys and composite data structures as values where you put the ref if you wrap the entire world in a ref then you're gonna have serious contention going into that for something that needs to tweak one value down here in a leaf on the other hand if you have refs throughout your data structure then you have a serious problem in terms of then you just defeated one of the greatest advantages of STM that you can snapshot you're in transaction value easily you can't just be ref it you have to dear f it and then walk through your map for example unrolling all of the ref so that you finally have a immutable data structure that no one else might have a reference to and be changing something out from underneath you and finding that right granularity is not easy I don't think there is any known you know well known way of figuring that out it's trial and error its testing its load testing it's dependent upon your operations and your data model and the kinds of traffic or load that you might happen might have so I think this is you know STM is great but there but there are significant changes that come in with the data model and one of them is that transactions can be hard non-deterministic there's no guarantees of this transaction will succeed if you have high load if you have long-running transactions if you have a heterogeneous mix then it's very difficult to say that this transaction will succeed where as this one will fail and that's and that can end up producing a lot of very strange results and unfortunate failure conditions when you're in a production environment you have a spike of load but you never tested up that high or you never test it with this mix of operations so I think there's you know STM is a new field overall not just enclosure obviously and I think I think more work in this area so that we can develop some good guidelines about how to structure our reps with regard to granularity as well as maybe have some guarantees around I always want this transaction to succeed this has higher priority of the over this one etcetera etcetera I think that would be beneficial overall I think STM is overused because it is a marquee feature of closure people jump straight to it they think oh software transactional memory I'll do this when honestly two atoms would be fine because there's no coordination going on between the threads of execution oh and then most applications that we write or that I write use an external database they delegate out to a database like a relational database or CouchDB for consistency and coordination and delegating out in that way is a good thing and it's a good pattern and we know how to do that pretty well and a lot of times it makes things a lot simpler especially when like the fundamental design strategy of a lot of distributed application architectures is to minimize the amount of state held in for example compute nodes you want to be able to have a node that if it goes down or if Amazon has a network outage which hardly ever happens then you will be able to bring up another node and not care what was on that first one whereas if you're using STM or other ways of managing state within your compute nodes for example then then you will end up engaging in an anti-pattern of retaining state and coordinating state in things that really should and could be stateless so yeah I use Python for a long time or not a long time two or three years I used Python extensively mostly for web stuff and I never read a single line of Python source ever that's not the case for Java I mean I have the job of sources open constantly for all sorts of reasons so I don't think there's any you know it's not like closure is alone in this fact that you really need to at a certain point it's gonna happen you don't know what's going on you don't understand how what the semantics are of this you just end up needing to read source you need to open up core dot clj or the reader or you know locking transaction or see how agents are actually interacting with thread pools or whatever and you know a couple of examples off the top of my head nobody understands how Chunk seeks work fundamentally out in the world aside from crazy people like me that have read every single line of how Chunk seeks operate nobody understand how they work and so you need to go breed that and the same thing with all the in line stuff and then you know core itself has like 600 public bars of fantastic functionality but literally one person knows all of them right there's a lot of great stuff in there and you should go and read core dot clj because you're probably rewriting half of the functions in there on a regular basis and that sort of points to something I'll talk about a little bit later about you know documentation and what we should be aiming for in order to make closure a discoverable easy easier to use language also with regard to libraries so the JVM is the thing everybody loves to hate and it's understandable I mean especially given the rap that it got over the late 90s and early 2000s and and things like that there was a blog post not too long ago that put pictures to that long-running joke about what what programming languages would be if they were cars and so you know the JVM is a sturdy but boring and slightly clunky f150 and you know Lisp is a DeLorean has the you know has the gullwing doors which no other language still has it still has the parentheses in a line and then the the effect is this and it's not wrong right it's not wrong this isn't a that's that's a very accurate representation of what's going on we all know it doesn't start up very quickly especially people coming from Ruby and Python and other you know in quick interpreters or you know people that are used to compiling to C or whatever and that's getting better I've seen startups startup times especially under JDK 7 loading closure core under two seconds and having a rep already so it's getting better and it will continue to get better but that's that's sort of minor what I think you really should focus on is that the JVM as it's often cited does have a lot of fantastic libraries the flipside of that it has a lot of libraries and a lot of them are not fantastic and especially when you are using libraries as a means to an end within closure we often wrap them even internally you know even if you're not going to put something on github that depends on a particular Java library you're gonna wrap it so that you have a fluent nice to read easy to use API for something that happens to live in a JVM library and it really helps to develop a refined palette for spotting those Java libraries where that is amenable where that's easy to do and where there's there's nice correspondences and where there's no conflicts so if you if you look at the Java doc for a for a Java API you do it enough you'll begin to see oh this isn't going to work out with persistent data structures I see all these side affecting and you know functions returning void everywhere and you run in the other direction as fast as possible and then you see other things like libraries that have totally unacceptable data models like everything needs to be a subclass of an abstract class and so you're gonna be stuck working with proxy and Gen class and you're gonna take a penalty hit and your build process is going to be implicated in the whole front in in the whole effort and it's just not worth it usually so you want to develop that refined palette because there are fantastic libraries gems that are world-beating there's nothing better except what's on the JVM in certain areas but in other areas you need to you need to tread lightly and of course you could go on with issues with a JVM but that's relatively well known the saving graces of it is that it's damn fast it's reliable as hell and it's easy to get your applications once they're built out into the world because everybody can run a Java app one way or the other you can deploy it to however many platforms up in the cloud etc etc one of the key issues with closure being a JVM language is this requirement or this desire among a lot of people to get Java class files and closure supports this supports it pretty well through a process called ahead of time compilation and basically don't you ever use it that's that's that's the that's the top line message it bloats the artifacts but that's not even the significant problem part of the bloat really is that the compilation is transitive through all of your dependencies so if you need one def type a ot compiled because you have a customer that's using JRuby and you don't want to have to force them to go through closure laying our teen or to twiddle your closure functions you're gonna end up compiling closure set for crying out loud down to Java class files in order to get that one and it's to the point where tools like Lanigan have options to go and back into the set of äôt compiled class files and delete out the ones that aren't related to the project that you're actually working on so this is this is an issue and it's an open issue and hopefully will be addressed sooner rather than later but the real problem is that a ot compilation introduces compatibility risk for anything that you compile so if you compile something if you a or you compile something against closure 1:3 it may or may not work against closure 1/4 or 1/2 were 1/5 even if the functions that it touches and their arguments haven't changed because of implementation details that change within closures implementation if you absolutely have to deliver class files only ever do it as the last thing that you do before giving it over to your customer or to your client certainly never ever put a ot compiled class files in a jar up into something like closures or other maven repositories because other people will trip on that compatibility issue down the road when they've been using your library that's a ot compiled that probably has a copy of closure contribute it because of the transitive compilation and they're going to trip on the next version of closure when it when it comes around so I'm gonna have to speed up a little bit but parentheses we we have come to love them other people hate them whether we love them or not you know maybe that's a Stockholm Syndrome kind of thing the nice thing about parentheses and the other literals that are provided for enclosure is that it means that closure is a homo iconic language and that gives you macros but as we've heard from tons of people including myself and Christoph and Michael focus and others macros are difficult to get right they don't compose with other constructs with enclosure the way functions do for example and they're really rarely what you want when you're building libraries and applications my view is that closures are sorry that macros are too easy you know someone reads about macros again one of the main marquee features of closure that you can do this advanced compile-time meta programming and do what you like and people start writing macros upon macros and then they write a macro and they need to write everything else as a macro nor for that macro it's it's it ends up being a disaster in a lot of scenarios and leaves a bad taste in a lot of people's mouths and I'm reminded of something that a lot of people say that aren't lispers but do like macro systems or compile-time meta programming I should say that you don't need to write an ast S in order to modify them and there's lots of instance proofs of this right that groovy and Haskell and Scala coming up soon apparently will be are building these compile time meta programming systems and they are not Homo like on ik and I'm not sure if maybe that's a better balance where the people that really need to have macros presumably with a more with a higher level of expertise you know they need to put in a little extra work in order to get to that point I'm of two minds about that and I'll only say that there are a lot of things that show that homo like Anisa t doesn't simplify a lot of aspects of metaprogramming it so there's this compiler API that you need to know in order to write truly effective closure macros especially if they're going to be interacting with other parts of your code so when you have a great hammer of course everything is a nail and a lot of people like to try to use closure everywhere for every purpose and I fell victim to this way early on I remember late in 2008 I wrote a tag binary reader right so that I could take closure data structures and serialize them out very fast it was faster than Java serialization certainly way faster than the reader and this impulse I think is wrong in a variety of ways because s expressions aren't always superior right you have what closure provides you in terms of the data model you can work with what if you want to work outside of that data model and we have some motion towards that with the with the tag reader literals but one thing that's always gonna come down to and as and a big issue for me is that there's no way to have binary data within readable code also the readers slow let's be honest about it if you're gonna be using it as a generalized serialization and persistence mechanism you're probably going to be very disappointed if you were used to nearly any other person´s mechanism and if you are working with other people that are used to taking in and producing json or xml then then s-expressions generally aren't going to cut it Lisp has been called a big ball of mud and this is either an insult or a compliment depending on how you look at it right so this is an example from the book looking at what you could do with a composition of functions using partial and all that and you can produce far more complicated constructs than this of course but you can dig yourself into a hole pretty easily especially if you get too lofty or loose in the composition of all these generalized pieces of functionality insofar as if one part in your pipeline here produces a return value that doesn't produce an error until three levels down that's going to be a little difficult to debug and the same thing applies to chaining together large sets or a large number of transformations over lazy sequences so I I don't think it's actually a ball of mud it's more like getting caught up in a pile of yarn especially when you start looking at the stack traces that often come out when you've been composing a lot of functions together it's very hard to find out where the real the real issue is I should have made that bigger so lots of languages have different learning curves and closure has its own I I wouldn't want to try to produce one that represents it I prefer the crossing the chasm metaphor from Gordon Moore and there's a lot of things that someone coming into closure needs to understand there's a lot of different hurdles that you need to leap in order to become productive and have a have a happy outcome of using closure and it's all of the ones that you can expect right and I'm not sure what the solution is because for a lot of these you know this codes back to the documentation right all of us no matter how long we've worked with closure no matter how experienced we are we're always going to be tripping over what does that function do again what is the new function do what is the function and then saw their library do how do you how do you discover and learn how to effectively apply closure libraries including core and what are the what are the mediums and resources that you need to do that effectively I think that's an open question there's a lot of tools that are working on doing this there's closure Docs I did one called closure Atlas there's all sorts of other things that are sort of in the air as people trying to figure out what's the best way to smooth this path you know tooling and all that stuff is not a is not the purview of the language itself but obviously it's implicated in whether you are successful or not the language could be the best thing in the world but if your preferred environment doesn't have and easy to setup easy to use easy to maintain and long-lived support foreclosure then things are going to be difficult for you and ironically this this last one is probably the easiest just because we are deploying on the JVM again it's one of its big advantages is distribution and you know there are other there are other hurdles but I think a lot of these are a lot of these are meta and that they aren't strictly about the language but they are about what gets built around the language and how we can make what's around the language be better than what it is today so I think in the in the description for this talk I said I would move through technical social and existential issues and so there's this and not being more of it in any way and I don't want to do that but closures bus factor continues to be one or something approximating one and I think you I think we can all agree given the history of different languages that have come up and faded away or are still with us for various reasons that a singular vision is the only way that a language can be developed and can thrive languages and systems and tool that are built by committees often are the least pleasant to use and so it had to be one at some point but it continues to be one and from the perspective of someone again going back to you know if you're a business oriented user of closure you're building your livelihood off of it that can be a little concerning and you know we can look at look back at what happened with other people that decided to do other things with their life which is perfectly reasonable but the difference between closure and you know dive into HTML or Python or the cumulative works of why the lucky stiff is that they were great things in the world that were that contributed a great deal but no one built a livelihood on top of it or a business on top of their community on top of it and something that really made me think about this in depth was a couple I think it was a couple months ago when it really became evident that it was a good thing that the apache couchdb projects bus factor was not one because it's its original creator Damien Katz who again he moved on to other things but what he moved on to was a company called Couchbase which originally was using couch TV but then made a technical decision and decided to start promoting something that wasn't totally not couch to be unrelated to couch to be essentially incompatible and if couch jeebies bus factor had been won then the project would have been finished right or effectively finished on the other hand because it wasn't because it had been folded into the Apache process whatever it's whatever is it whatever recommends or doesn't that that process it does ensure that a project has a number of committed committers and a number of people stepped into the void and companies pledged support and CouchDB looks more vibrant now after Damien Katz's departure than it did a year ago and I think there's a good story to tell about closures position in this circumstance first of all it's released under the EPO and there's a phenomenal community around it there's not just one or some small number but I can think of probably a couple dozen people that I would trust to make a another closure implementation or start from the base that exists that I would use personally and so I think you when the open source factor and the the community that's surrounded it with phenomenal expertise and intellect I think things are good there more importantly than that is that the ideas in closure are far more important than any particular implementation so we all use roughly speaking the jvm implementation of closure but there are others right there's closure script targeting JavaScript there's closure CLR which is really instructive because it's largely the product of one person one extraordinarily dedicated and smart person but it shows that there is less risk here than we might think and then in just the past couple of weeks or month there have been two other separate implementations of an closure pie circumstance closure running on Python so you have the compiler available or runtime in the whole deal and then close your scheme which I think is based on closure script targeting gambits so that presumably we may be able to run closure script apps on the iPad and things like that but compile down the C and using gambit light anyway the point of this is that the ideas are more important and given a large enough community which I think there exists and given enough expertise which I think exists it ones investment in closure is very safe from a from any existential threat either people deciding to go off and do new things or worse so the final point I'll make is that the thing that most mitigates all of these risks including the bus factor stuff and the documentation the availability of libraries is that we need to continue building a community of power and responsibility of people that are engaged building new things willing to help make the things that are there better and willing to take responsibility and take ownership of the things that they care about and enabling everyone to do that I think is one of the that's that's that's that's the ordinal point of what we need to do in order to ensure that closure is healthy and long-lived thank you

from infoq