1/8/2019 11:30 AM Clojure was my language of choice for quite a long time, but all the recent developments in the community[1] and lack of clear publicly available vision of the language's future alienates me greatly and makes me feel as an unwanted member of the community. Because of this I'm not considering Clojure anymore for any new development and don't really want to help growing the community by releasing new libraries/supporting existing ones, mentoring new Clojure engineers, speaking at meetups, or just simply recommending Clojure to people I know :( [1] Drift to being dogmatic and hostlie to any alternative thoughts community (or better say cult?), which started long time ago, reached unbearable level last year and I'm not interested in participating in any community even resembling a totalitarian one, even if the language itself is perfect (which Clojure is not). Disclaimer: my feelings are obviously mine alone and I don't claim it's the universal truth and "Clojure is dead", it's just my personal opinion.
1/7/2019 4:48 PM After using Clojure professionally for 7 years, I am hedging my bets by involving myself in the Rust community. While Rich's comments may be lauded by the greater online community, it has had large impact on my personal consideration on the state of Clojure. On whether this language will ever grow to the point where I can rely on it professionally in the long-term. I am thankful for this language and all that I have learned over the years. I am thankful to Rich, Stuart, David and everyone else at Cognitect for creating a language that I have enjoyed writing every day. But, as a member of the community, my concern is that the user base of Clojure cannot grow larger without this concept of ownership changing. This conflict, at the end of the day, is a conflict between what my hopes for Clojure were and the interests of Cognitect. My hopes being that it would be a lisp, with a set of great core choices, that runs on a virtual machine that real businesses use. I believe this is what allowed Clojure to be introduced at some many workplaces and it is certainly what has helped me convince my co-workers and execs over the years to use it. That somehow this very practical approach would remove of us from the follies of other lisps, namely re-inventing things constantly and not establishing core community libraries for common tasks. But it seems that Clojure has remained what Rich originally intended it to be. A language that he wrote to solve his needs in contracting/products that he works on. Which is perfectly fine, it's his work. He owns his work. He owns the direction of his work. The conflict is simply that, for some reason, I had assumed my interests were in line with Cognitect's. It has becoming clearer, year after year and especially this year, that this is not the case. It's very likely this misunderstanding is a mistake on my part. Looking back, I see no reason that I should assumed this other than it is generally the trajectory of most languages focus on growth. For this reason, I will likely exit this community as many others have. I don't have any hard feelings or regret being part of it. I am very appreciative to all of the hard work that has gone into Clojure and regretful that I did not contribute nearly enough during my time writing it.
1/14/2019 6:15 PM I'm hugely grateful for all the hard work put in by Cognitect and other core contributors. I love using Clojure, I recommend it to everyone I can and it has helped me greatly over many years. Rich and others in the core team have taught me so much, made me a better computer scientist and programmer. I know it's stressful when someone won't stop saying negative things about all the free time you're putting in and the free work you're doing for them. But please, if someone raises an issue, let's not start writing long gists and throwing around accusations of entitlement. Some healthy discussion has been had and there's really no reason for us to start having a meta-argument about how terrible and entitled someone is for raising concerns in the first place. There's no need for everyone to weigh in, to take sides and state publicly how much they support Rich. I've lost count of how many times this has happened. I dream of the day that the Clojure community is large enough and mature enough that someone can say something negative, have some debate on the mailing list or elsewhere, and it doesn't cause a scandal! I almost marked 'Unpleasant community' here as one of the things that turns me off Clojure, but I fear this would be misconstrued. The unpleasantness, in my humble opinion, comes when the core Clojure team dislike something that someone has said or written, and the wider Clojure community then comes, mob-handed, to weigh in and shun the dissenter and state for the record how despicable they are. There's a great imbalance of power here. I hope all kinds of controversial topics continue to be discussed and that the community around Clojure grows stronger for it.
1/8/2019 4:03 AM 2018 was the year that Rich finally explained how he felt about the open source community around Clojure. For many this was disappointing, but I'm glad that he finally explained how he felt, because at least it is now in the open and people can make decisions with full information. Five years ago, Clojure could afford to lose key contributors because the language was growing and new people were coming along. Clojure is now at a very different place and position, and it's no longer growing at the same rate, or has the same mindshare. I've invested many years, and lots of time into the Clojure community. Up until this year, I thought I would have a long career with Clojure, but I am starting to look around at other language communities for ones that are a better fit for my values.
1/23/2019 12:12 AM Biggest draw to the language is that the entire concept is all about trying to write code, in a much better way that is extremely practical (not just academically better). Rich and the entire community should continue being opinionated, solving problems, and advocating strongly for these measurably better ways. It makes our coffee better, our products better, our customers happier, and it makes us developers MUCH happier.
1/22/2019 6:43 PM working in Clojure for many years. love the language. with time learned to dislike the authoritarian views and direction of the top layer of the community. Scala had a lot of that (which I did before Clojure and is one of the main reasons I left it behind). Clojure started having it about 3 years ago. I hope it is going to go away since the rest (majority) of the community are great people. "There is no authority who decides what is a good idea." -- Richard Feynman I like that.
1/21/2019 11:54 PM I find it really gutting that I don’t enjoy Clojure anymore and am looking for something else merely because of Rich’s behavior but it’s just gotten to the point where I can’t in good conscience bring people into the community anymore. Even Linus has had his moment of insight by now.. but for some reason Rich just won’t figure out that it’s not the children who are wrong.
1/21/2019 10:54 AM Clojure is a real pleasure to work with for an experienced programmer, it's quite a leap from what many developers are used to. Whereas with languages like Scala you can slowly introduce the functional concepts, with Clojure you have to learn a new paradigm to really make use of the language, I think the documentation, tutorials and error messages are vital here to help people to make the jump into Clojure, along with learning to program using the REPL. It's challenging to learn but by far the best language I have ever used, it's a real joy to program in Clojure.
1/21/2019 9:38 AM Concerning docs, I'm seldom able to really make use of the Clojure API doc. Since examples help me more to understand what a function does, I rely more often upon the examples provided by the community (https://clojuredocs.org). However, the quality of the examples vary and it would be helpful if there was a set of curated examples.
1/20/2019 11:59 AM Understanding existing source code and its execution is a vital part of what we do. When our mental models are mistaken, underdeveloped, or otherwise insufficient, first-hand knowledge of actual execution can be a big help. We are not always in a position to structure the code in question (e.g. it's someone else's code and they cannot be consulted) nor have the tools or environment (e.g. the debugging features of Cider or Cursive) to support us. Built-in support would be welcome -- particularly something that lets us instrument existing code and not force us to modify source for just these sorts of purposes.
1/20/2019 12:44 AM Clojure appears to have become a company language, serving the needs of Cognitect. While no-one can begrudge the insiders who gave years of their lives to its creation, those outsiders who contributed and those of us who wished to enjoy it bemoan the capture and commercial imprisonment of this hugely valuable commercial/intellectual/engineering resource.
1/19/2019 11:56 AM The missing of a usable full stack web framework like Grails, Django or Rails et co. for the Clojure ecosystem prevented us doing many quick web projects using Clojure, hence the Clojure adoption practically dropped over the years :( . Since http://arachne-framework.org/ turned out to be a total failure, many teams just dropped Clojure :( .
1/19/2019 1:02 AM I fully understand it's entirely Core Team's project (or of Rich Hickey himself) and we're not entitled to anything at all, but the the whole situation is quite off-putting. While recent contributions (in documentation, as far as I'm aware) are being accepted in a more relaxed manner, other areas are still lacking - notably bug squashing/small improvements (tickets not being handled for years) and informing community about language development progress ("Inside Clojure" blog is a great start in this area, but it mostly focuses on tasks Alex MIller did himself).
1/16/2019 6:54 PM I love Clojure, and an extremely grateful to Rich, Stu, Alex, etc for their continuing stewardship and work of this fantastic gift. With respect to recent kerfuffles about community involvement, I simultaneously understand and respect Rich's position, and I am also concerned that some very respected Clojure developers who have contributed a lot (IMHO) feel disconnected and may be drifting away from the community. I don't have any solutions or answers to this situation. I hope that everyone involved will continue to ponder and reflect on all points of view. I do not think the current trend is in ideal situation.
1/15/2019 8:42 PM I wish we had a better documentation generator and a better culture of documentation. I really miss the documentation in the Haskell ecosystem (and five years ago, I never thought I would be saying that!). For example, the Haskell community generally expects detailed documentation of data structures, including detailed asymptotics. E.g., http://hackage.haskell.org/package/containers-0.6.0.1/docs/Data-Sequence.html This complaint extends to many of Clojure's included features, too. Headline features like STM have incredibly sparse documentation (about one printed page with the semantics only hinted at), so I'm left guessing at what I can actually do with these things.
1/15/2019 12:12 PM I'd really love spec to feel a little more complete. Based on some talks and comments by the core team I think there are some changes left to come, and I think there are some significant pieces missing around idioms to spec functions, protocols, and other parts of Clojure in a "standard" way. I've got a lot of love for spec as a project and use it heavily at work, but I feel it's shadowed at the moment by some ambiguity about what changes might be on the way.
1/15/2019 8:46 AM Clojure is fantastic and getting better. I am a little concerned that we are seeing significant developers leaving the ecosystem because of perceived insularity from the core developers - I think this loss will weaken Clojure's advance. More of a charm offensive is required.
1/14/2019 8:01 PM I'm concerned that there is too much of a disconnect between the core developers and the wider community. I think the core team are doing wonderful work, and the direction and stability of the language are great, but I think a curated collection of recommended third party libraries would help a lot of teams. I think it would be great if the core acknowledged some of the work of Clojurists Together. I think the new clj-commons organisation is a great idea and I'd like to see it better promoted and supported. There was some unpleasantness recently about the core team's relationship with contributors, and I think this is mostly due to bad marketing / communication. I think we need to make it easier for developers to find the best libraries, identify appropriate design approaches, and build their applications. Overall I'm really happy with Clojure, loving the improved error messages, optimistic about the future of the language, but concerned about it's popularity, and lack of solid guidance in best practices.
1/14/2019 1:34 AM Overall I'm very happy with the state of Clojure. Many thanks to the core team and community for their hard work. Specific other things I'd like to see are: 1. Releasing spec. I'm also very curious about seeing more details around the "maybe not" thinking. 2. Docstrings on specs. Whilst I understand the trend towards using data instead of API's, e.g. cognitect's recent AWS API. I think it's worth noting that the data oriented approach to APIs currently requires a different way to document your API, which is a problem. I appreciate spec partially answers this, but the lack of doc strings in spec is a problem for useful human facing documentation etc. 3. clojure.test runner integration with spec check etc. 3. Returning to some unfinished areas, e.g. transducers being parallelisable. Also it feels like clojure.core only implements some of the transducible collection functions, not all. Requiring the use of https://github.com/cgrand/xforms.
1/12/2019 9:28 AM Stop calling Open Source and start calling it Free Source. Even communities with BDFF are more open source and community driven that Clojure. Stop saying excuses like "Rich Hickey time is gold and limited", maybe you have to start rely on a group of person if he can't do the work, because losing the time to duplicate work, clj.deps instead of Leiningen, clj.spec instead of Schema.
1/11/2019 11:50 PM The clojure core team is an amazing source of inspiration, but as much as its 100% Rich's right to manage the core development process as he pleases, the commercial viability of the language needs reassurance that bus factor 1 is nothing to fear about. Managing expectations in 2018 is about 10 years too late, please give a signal that the core team recognises not only that but how much the community is worth to clojure as a language before dismissing any critics to the (previously much unclear) contribution / lifecycle process. We all need a more inspired and collaborative attitude towards community as much as we already get it with technology to be able to keep our niche healthy. As a clojure meetup and conference organizer, I've personally pushed many people and companies in the past 9 years towards clojure, please help me out here.
1/11/2019 11:29 PM I was a Clojure fanatic for several years. I still enjoy and respect it, but often reach for other tools. It saddens me when I think about the possibilities early on, and contrast them with the detracting factors at the time. I'm not sure they're all even still relevant, but I know at least a few are: - "Locals Only" mentality. There has been conversation in the community of the sort "open source owes you nothing". This is a poisonous perspective. Healthy projects appreciate their users and encourage participation. Are there "help wanted" signs now? There are calls for testing, but not many for building things together. - Tools and libraries that seem promising get abandoned, and may break your app or tool chain, so you spend more time working on environment or replacements then writing code. Seems to be a lot of one-person tools and projects. Single-point-of-failures. Clojure is an awesome language, and there are many great leaders in the community. It would be encouraging to have some type of push for increasing public engagement. See Node foundation or Cloud Native Computing Foundation working groups.
1/8/2019 5:49 PM The BDFL approach is starting to wear off contributors and it is permeating in Cljs (my main targeted at the moment) as well, where I guess it should not really appear that much Many times patches or proposals are pushed back with zero or little explanation, or never reviewed. Maybe no feedback still IS feedback but I am afraid that in the long run the language will receive very little attention (apart from the awesome Alex Miller). Another big problem is Cursive, for the price not really up to expectations. The clj integration is aweful and bug ridden. Same for ClojureScript where it is not possible to launch a REPL using shadow, for instance. Talking about cljs, the fact that I was describing above is evident: shadow was born because of the stubbornness of both devs.
1/8/2019 12:10 AM Love the language. IMHO still the best designed programming language out there, despite the original sin of the JVM. I feel the pain of some of the recent quarrels - I get that Clj is for expert developers. But even expert developers typically have to work in teams with managers, and you can't be the only one in your team to do Clojure. I've tried for years to push for adopting Clojure in my large enterprise org, as it would be perfect - we do tons of JVM and have lots of interested people, many of us love functional programming and Lisps. But if just one newbie says "Oh I tried it once and I didn't get it", that means the project is a no-go for Clojure in the eyes of management. They're not willing to take the risk, even if 3/4 of the people involved know Clojure pretty well or could get up to speed in a few weeks. Error messages. Please. Good tutorials for basic stuff - I don't need transducers for now, I just need whatever Spring or Rails does in Clojure. How do I make a basic web app with security in place? REST API with React/Reagent SPA? Just basic bricks. I can figure these things out, but my co-workers who don't love Clojure don't have the patience. They google for 1 minute and then conclude it's not worth it. Have you tried Elixir? Even failing at Elixir is fun. The compiler is so helpful. The error messages are nice. There are defaults for everything. Oh yea, default choices - a beginner is incapable of searching and evaluating libraries. IT IS THE RESPONSIBILITY OF THE CORE LANGUAGE MAINTAINERS TO LEAD A BEGINNER TO POTABLE WATER. Later I'll happily find everything myself, but as a beginner I'm just not experienced enough to make these judgements. Ruby? Rails. Elixir? Phoenix. Java? Spring. Just tell me what to do. I'll know how to stop listening once I'm advanced enough.
1/7/2019 10:22 PM Even though I agreed with the substance of Rich Hickey's "Clarity" gist, it is concerning to me that some of the more prolific library maintainers are leaving the community. I'm sure that had it been me, I would have responded even less graciously. Still, there's an element of community management that goes beyond just being correct. The biggest improvement I've seen over the last year (even over error messages) is the documentation. Clojure(script) seems to focus on talks to communicate idea, but personally I rarely watch talks, and they're harder to code with. Doing more along the lines of that excellent REPL tutorial would be great. (E.g., translating Stu Halloway's debugging talk to a guide.) There's a lot of background context that's assumed in the docs that could be brought out in documentation. One of the most disorienting things for people coming to Clojure is finding libraries and understanding the trade offs. (Aleph, Pedestal, Jetty, or http-kit?) Having tables of the most popular libraries with general features and trade offs would be super helpful. (I often go to the ClojureScript page to see what 3rd party libraries are recommended.) I think the documentation does a better job explaining clojure the language than the ecosystem, and it's an ecosystem with more options than most.
1/7/2019 8:28 PM I wanted to specifically note that I think Alex Miller has been doing a great job in the role of community liaison / evangelist type, which I'm sure is often a thankless task. I really enjoyed reading his blog posts about what he's working on; oftentimes what is going on in the core team can seem pretty opaque to people outside of it. I see where Rich was coming from when he wrote the "open source is not about you" post, and I certainly don't wish to seem ungrateful for all his hard work, but I largely agreed with most of what Tim Baldridge had to say about the situation.
1/7/2019 5:37 PM It's been 2 years since the initial release of Spec, and not much has happened since then, even though spec's missing features make it unusable for my work. I need introspection, runtime spec generation, and specs with arguments. New updates mentioned at the Conj sound great, but I'm guessing I'll have to wait another 2 years before I get those features. Overall I'm apathetic about the language, development moves at a snails pace. The core team is working on some important features, but in the mean time other projects have stopped development, see Schema for an example because they don't want to duplicate work. So we have the worst of all worlds, a unfinished Spec and a dead Schema. Since all the development is focused on spec, I anticipate that development on other areas of Clojure will slow even further. Which just means we have a few more years of half-baked solutions to use in our projects. But if I bring any of this up in a public forum, I'll be labeled as ungrateful, and "thinking it's all about you". The community isn't hostile, but the leadership can be a bit passive-aggressive. That attitude makes me want to move to a different language.
1/7/2019 5:04 PM By and large, I've been a happy user of Clojure for around 6 years. I've contributed to the community, given talks, and advocated for the language in my places of work (generally with a great deal of success!). I like the language, its community and its general design principles. I have difficulties with Cognitect's general treatment of its user base. I say user base here because 'community' can be confused with the conduct on slack, twitter, and other venues where discourse occurs. It seems very clear to me that the Clojure user base has contributed very heavily to the success of the language and its ecosystem for years and the role of users seems to go unnoticed when representatives of Cognitect address users. I acknowledge that Cognitect is a consultancy first, and as a consultancy it has a responsibility to its workers and customers first. I also think there are a number of libraries maintained by Cognitect that the consultancy does not have the resources to maintain. core.async is one example of a library that: - Doesn't require any new interface work - Does require fixes in the code-rewriting and exception handling machinery - Has enough small bugs with its abstractions that developers are required to know enough about core.async that the use of a concurrency library at all seems like a dubious tradeoff. When Cognitect introduces a new tool or library, my tradeoff evaluation centers around how long this new tool or library will be either interesting or necessary to the consultancy. If I don't think it will, I'd much rather use a tool maintained by the userbase or a tool written in-house. And ultimately, I don't have a significant problem with this, but I do have concerns when cognitect tools displace existing efforts and live in the core of the language. This is often a poorly communicated (spec excluded, spec has advocacy has been consistent) and looks often like blithe disregard of the years of effort that existing libraries and toolchains have invested. When complaints of this nature are raised, those who raise them have been cast implicitly as non-helpers, and venues of conversation are labeled generally unproductive. On the one hand we have people accused of ad-hominem attacks or disrespect of work by Cognitect representatives, while simultaneously representatives say things like "Not everything is awesome" and participate in frankly puzzling attacks on language features that aren't relevant to Clojure's design space. I don't really expect any of this to change but I hope the feedback helps in some way.
1/7/2019 3:46 PM I continue to be grateful for Clojure and for the work of the community, which has put food on my table for five years now. I have been a little saddened by harshness of tone of some of the writing done around the subjects of openness, contribution, entitlement, etc., especially before this year's Conj. I hope the leadership and the community at large appreciate how interdependent we all are -- all the more so given our relatively small size. Here's to many more years of growth (or maturation?) of Clojure to come!