Clojurians Log v2

I'll also chime in with Alex. I'm travelling this week too. I'm in Amsterdam for #babashka-conf and Dutch Clojure Days. If you're around, let's chat! I'm always available to chat online too. Feel free to DM me. We can set up a call too. I've been following this thread. There are a mix of issues, and I've been thinking about how to move forward. It's on my mind, and I will have more capacity to follow up after BB Conf and DCD. And yes, please do join us for the Clojure Dev Call on May 26. Feel free to DM me questions in advance too.

it can be observed the more you depend on Clojurescript, the less happy you are with Clojure in general. I understand the arguments from people affected in this area, but keeping any transpiled language up to date with JS nonsense is pure madness. The only "successful" transpiled language is Typescript, everything else is just painful to use and maintain. What I fail to understand is someone being unhappy that Clojure language didn't evolve over the years like other languages, I mean, being a JVM hosted language you can reuse literally anything available for this platform and being a Lisp dialect means you can customize the language in ways that would be impossible for users from other languages. Clojure is literally the only Lisp dialect that experienced users will make you feel bad for even thinking about using macros. This is what I also fail to understand, what is the point of using a Lisp dialect if I'm not supposed to write any macro, it makes no sense for me, not every problem is a FP/data-oriented-programming problem, the lots of macros that already exist in the core lib is a proof of that. I understand that by having FP with nice immutable collections makes solving problems by creating a Lisp DSL with macro less appealing, but that doesn't make macros unnecessary at all. From what I know from other dialects (common lisp in particular), macros are used either: i) to create a Lisp dialect for solving a particular problem in whatever the domain is; ii) to extend the language itself in terms of programming language theory like adding object orientation (CLOS) or adding CPS semantics (core.async). As a Java user, if I'm bothered that Java doesn't have a cool feature that exists for other language, the only option is sending an email to Brian Goetz and hoping he will be convinced and waiting like 10 years for the JEP being proposed/approved/incubated/graduated. In a Lisp language I just add the cool feature by myself to the language with a macro.

> what is the point of using a Lisp dialect if I'm not supposed to write any macro agree, macros are a major, even dominating, aspect of the Clojure value prop (being a lisp). There are great reasons not to use macros, but a consequence of this is that teams are trying to take "Clojure: The Good Parts" and at some point you have to ask, are we sure that the places folks are trying to apply Clojure are even a good fit for a lisp? That's why IMO Clojure's killer segment is "experimental distributed computation architectures" (Datomic, Rama, Electric). It's also perhaps part of why Clojure's outcomes in silicon valley saas are not looking so great now that the results are in. It seems in the end, and I was myself surprised to realize this, there has been a fundamental impedance mismatch between Clojure and the app categories it is often applied to. I never once brought Clojure into a enterprise/saas company, I chose Clojure for my UI experiments, that is the only reason I am here.

(I did champion a Scala adoption in 2012, which I also regretted btw, while it did not damage the company, it certainly did not deliver the 10x eng outcomes we were looking for. And that's also how I feel working with Series BCD Clojure SaaS - like, the Clojure decision didn't kill them, but in retrospect it seems a js/java architecture with midflight upgrade to ts/kotlin would have gotten them to a similar place, except with a lot better future ecosystem optionality / less lockin)

I did a Clojure project at a company once. One part of the system was PHP+MySQL but I got to do my part in React/Reagent and ring. Then I left the company and they probably were better off if they had done all of it in PHP. That's how it sometimes goes...

I didn't push for Clojure myself btw.

Nu may be written in Clojure but Facebook was written in mysql/php

there is a lot you can do with a eng labor budget of 131M/80c = $151 million

At work, we adopted Clojure after a failed trial of Scala. The company was a ColdFusion shop previously. The devs were used to a compile-on-demand scripting language for the JVM so Clojure was a "better fit" than Scala in that respect, and writing multi-threaded code in CFML was possible but hard. CFML is very dynamic and you can have hash maps containing functions because there are closures as first class values, so Clojure wasn't as "alien" as you might think for CFML devs. I used to do conference talks and user group presentations around the world, targeting CFML devs mostly, showing Clojure and CFML side-by-side, to illustrate functional patterns 🙂 Some of the folks in those audiences then became Clojure developers...

what biz domain ?

this is world singles networks?

Twitter went from Ruby to JVM I think, Discord went Go -> Rust, Dropbox: Python -> Rust, off the top of my head.

Twitter is allegedly rewriting their backend in Rust

I think we feel it more when it’s Clojure, and because of the small footprint to begin with, the impact is larger in real terms (of total usebase).

Perhaps the pattern is: dynamic language for product velocity early, then carve out hot services in a faster/typed language

Twitter adopted storm back in the day which was initially written in Clojure but then to Java. Probably because of the same reason some LLMs like to write a Clojure project with a single bash script entirely in bash?

@dustingetz Yes, online dating. But I will admit, we evaluated cljs for the frontend when we started the next gen UI, back in 2013/2014 -- we built some prototypes with Om and rebuilt them with Reagent (which was pretty new at the time), and decided the tooling/ecosystem for cljs was too brittle and "weird" so we went with JS/React/Redux (and I wasn't involved with the frontend stuff again until about a year ago). I've seriously considered writing new pieces in Squint to at least get some of the benefits of a Clojure-like language 🙂

twitter went to scala

I read they replaced storm with heron, something written in C++.

@borkdude I thought the rewrite to Java was mostly driven by wanting a bigger community of contributors?

yes

Rama was also first marketed to Java developers btw (while written in Clojure)

(from the same author as storm)

Datomic also had a java strategy, but they abandoned it

btw, i was working on triaging my list of issues this morning so I can deliver them to Christoph and Alex, and maybe half of them are .cljc issues at the boundary between dialects. So maybe when I say "Clojure is for experimental distributed computation architectures" -- in fact it is not, because Rich doesn't use it for that, and therefore I am trying to use Clojure in a way that is never quite going to be up to par given the way Rich makes decisions. Have I been tricked? Am I a fool for believing in "language of the system"? Have I wasted the prime years of my life working on an architecture that is never quite going to delver the DX it needs to succeed, because of a misplaced bet on a dependency I cannot influence?

Impossible to tell without very concrete specifics.

indeed

you didn't waste your years if you spent them on something that genuinely interested you, would be my take. whether or not the .cljc issues can be fixed, 🤞

I could have worked on something else

But let's not make this about me 🙂

Its jsut, when core tells me to eat shit, I really get this feeling like I am holding a bag (edit: this is slang, and obviously nobody at core has actually told me to eat shit, i choose not interact with core at all)

that was chas emerick's takeaway when he decided to depart (as seen in his tweet i linked yesterday), but counterfactuals are hard, especially when thinking about multiple years of work and learning and growth

counterfactuals are hard - yes indeed and perhaps I should not have even shared

clojure is not about me, i do not want it to be about me

also, it is amazing that electric even works at all, a testament to the phenomenal core design of Clojure. We have encountered no fatal blockers, which is extraordinary

Electric is the kind of thing you’d expect to have to build the language for

(plus grammar)

We may yet have to, but it would be massively cheaper to fund core directly instead (I would need to raise the money for it, but our business case is crystalizing, its going to happen)

But like, Nu already tried that. And Rich quit

Right. In another world, it would have been a research paper entitled “A language where…”

Nu bought Datomic, not Clojure and Rich is still working on that during his retirement

maybe someone else can try to buy Clojure though? ;)

https://building.nubank.com/nubank-acquires-cognitect/

> Rich Hickey will remain at the helm of Clojure, which remains independent

@dustingetz, have you talked to Rich directly? you have valid points.

Rich has been clear. The wine is of exquisite taste, a premium vintage. If my taste is insufficiently sophisticated. I am to see myself out

@dustingetz That is quite concerning.

there has been a fundamental impedance mismatch between Clojure and the app categories it is often applied to

With vanilla Clojure whenever I find something I disagree with Rich or the community I realized I can do things my way by writing Java code and macros. People that are allergic to writing Java or are too dogmatic against macros will have to be content with the way the language is. Cannot say anything about Clojure script though, I don't use it.

there are many earlier stage startups very happy with Clojure, and especially boostrappers / solopreneurs too

there are many later stage startups very happy with Clojure too especially those with old timer clojurists in leadership roles

at enterprise i think there are many, many small teams inside larger enterprise that are very happy with clojure. netflix has a diverse existing stack and uses clojure, apple has a very siloed/fragmented org (each team has autonomy) and has pockets of clojure/datomic. There are also companies and teams inside companies who quietly moved on.

Personally, I'd love an exit interview with every company that moves on. I don't think all churn is avoidable, but I would like to start tracking reasons. I'd love the data. I want to see what can be affected and what cannot.

Of course, for anyone reading this. Feel free to send anyone my way. I'm not here to try and talk people out of it. I'm here to hear why.

Maybe it's still possible to get on calls with companies who exited in the past

And ultimately, I want to drive change for patterns we can affect.

@borkdude Yes, I'm working on that right now, but I'll take any referrals I can get.

@neumann we have done more than 30 projects from scratch in Clojure(script) so far (since 2015) for a variety of companies, usually traditional (and solid) companies with a turn-over between 50 to 1000 million euros, and also for three startups (these have been the most problematic projects). Many of them are still in production, some of them were canceled due to lack of product market fit/funding, and one of them replaced by next.js stack. These days we are working on several highly challenging projects. If you want to talk, let me know.

@asier.galdos I want to talk. DM me, and we’ll set something up.

Will do. I am going to bed now. I will DM you tomorrow.

> And Rich has every right to work the way he wants, keep his sanity and not give in to the pressure of a large following. The clojure community also has every right to question Rich's authority.

I'm not sure what you mean by that. Question that he is the author, copyright holder and owner of a language he created?

Imagine you've invited some guests and after getting comfortable they start demanding a remodeling of your living room. :D At least that's how that argument appears to me. But different from "it would be nice if"s, of course.

that's not an accurate description of the situation

In terms of human rights: we can question whatever we want. Rich is also free to ignore that. For me, it feels like there are emotions that possibly distract from the more constructive question of: how do we work well together as a community to improve the language we love (or at least have chosen). The governance process is what it is, and the core team is pretty clear on how it works. On the other hand, there are emotions around this for a reason, that the core team will probably want to listen to. From what I’ve seen above, they are interested in that.

that's not an accurate description of the situation

Even if those points are written from a place of frustration and kind of half formulated, there can be something to them. “Business reasons” can matter to Clojure: the idea, the effort, the phenomenon, even if it doesn’t concern Clojure: the lines of code in the repo.

No doubt about that at all! But while that "something to them" remains not reified, it's all the good old "the sky is falling" I'm afraid.

And, just to be clear - by "Clojure" I didn't mean "the lines of code in the repo". I meant the whole ecosystem. That's the meaning I put into "Clojure in general".

The clojure team does a lot to stay in contact with the dev community. They even have a dev advocate now. They are putting out videos now with Q/A about the dev work they are doing (I think)? They are doing far more than required. Calling the people who work on this "human shields" is a bit insulting. Yeah you have "every right" to say what you want, but come on.

This thread is mostly therapeutic I think. It might be a bit much to ask for immediately actionable items from here. But the fact that there are frustrations shouldn’t be dismissed, IMO. The nature of frustrations is that they might not be eloquently expressed or immediately actionable, but they’re a canary for something.

There are frustrations in every dev community -- but not many communities where there's a concentration of devs in close proximity to the "core" team, such that those frustrations can easily be expressed to that team 🙂

Right. I also think we are at point in time where we might have a bit of sympathy with people who feel like the sky is falling. The frustrations might have been held previously, but there’s probably a reason why they blow up right now.

Why do you think they "blow up"? Quoting Alex: > I've been in this same conversation 3-4 times per year for all the many years I've been working on the Clojure team Occasionally different unrelated fluctuations can all coincide and appear as resonance. And a thread with 100+ replies on something meta-Clojure is far from unheard of. Although this one might benefit from a multiple testing correction.

Probably a confluence of things going on in the world right now. Some are probably of very indirect nature, affecting the person, and therefore indirectly affecting Clojure (the community). Some with a more direct bearing on Clojure (the effort/phenomenon). Right. It’s comforting to hear from someone with experience that “this too shall pass”. That’s useful.

The concern over larger, VC backed companies leaving clojure does mean that selling clojure-based libraries or services will suffer economically. While these large teams will likely learn the hard way some languages aren’t sound for scaling unless hiring is your only concern, I’m interested to know what features does ClojureJVM needs to support that a fork of some sort cannot do?

Yeah, I don’t know what to make of that. I wasn’t under the impression that Clojure was a VC darling to begin with. But companies switch languages sometimes, and we only care when it’s our language that’s being left behind.

selling clojure-based libraries

> Why would the details of the implementation of a service worry its users? because of perceived maintainability, I was under the impression the same mechanism prompted the Nubank move.

I’m just interested to know what these C/D series companies are giving as reasons for leaving clojure beyond hiring

It often happens that before the companies give up, teams do, and either rewrite existing services or write new ones in whatever language they would like, either because they find it easy ir because of hype. This cultural drift accelerates over years before the company just acknowledges the existing state and declares previous language is in maintenance mode and to be replaced / deprecated

This dynamic is not particular to Clojure, but Clojure is more susceptible to it since it is niche, so many developers come to it not as Clojure developers (such as Java developers can move as Java developers between jobs) but just as usually backend developers on a new project.

I've also seen this happen at companies that had a small Clojure team, eventually people leave and it gets replaced with a mainstream lang

Clojure has a lot going against it from the perspective of the biases of the average programmer - immutability, lisp, functional, JVM, niche. All properties make it icky, strange and turn off. It's childish and unprofessional, but that's what you get. Another factor is that when an experienced programmer has a bad experience with Clojure, they bounce off hard because no one likes to suck after they feel competent.

It happened to us. We released the initial product in 6 months for a VC backed company and then we were replaced by their Nex.js team.

But we also replaced many failed projects with our Clojure tech base.

@p-himik said: > I wasn't addressing that, I was addressing "questioning the authority". my apologies, this is the situation to which i referred. rich has made his perspective abundantly clear, through his many public statements as well as the treatise "Open Source Is Not About You". as i understand him and his stance (and please preface all of my "statements of fact" with this phrase), he believes that there is not and should not be anything more than one person saying "i made a thing" and another person saying "i use the thing you made". he does not believe that people building companies in Clojure are owed anything, hat devs who use and/or love clojure are owed anything, and he seems to believe that there is not and should not be any level of expectations from the community towards him. he endeavors to be a good steward inasmuch as it pleases him; he cares deeply about some core values (strong backwards compatibility guarantees, certain performance characteristics), and he likes to work on the parts of clojure that interest him (spec, datomic, core.async), but he acts like all other development cannot be expected, nor should it be. i believe that this is not a healthy way to run a community, and i think that it is only "good stewardship" when we're talking about small projects that don't have globally backed companies, multiple conferences a year, or developer advocates. it feels disingenuous to treat clojure as a pet project, one person's little toy, when we have hundreds (if not thousands) of people saying "i use this professionally" or "i'm building a business on this". "https://en.wikipedia.org/wiki/T._M._Scanlon" is an age-old question and i am not claiming to know the One True Answer:tm:, but i think that Alex saying "i've had this conversation 3-4 times a year since i got hired" points to something that is not covered by the existing dynamic. there are many ways to run a community, to develop a programming language, to build trust with other people; the current one leads to many folks saying (year over year), "this process hurts me and leads me to want to move away from clojure (the language, the ecosystem, the community)". chas emerick's https://x.com/cemerick/status/1067111260611850240 in 2018 stands out in my memory, but this thread shows signs of other prominent members thinking about stepping back/moving away as well. i think alex and the other core team members do a good job acting as Rich proxies, running interference for him, taking his position publicly as their own (or as the Official Stance), while also talking to us, helping us out in their own ways, and providing a significant portion of actions that gain the core team good will and a dedicated group of loyalists who will defend them at all costs. i deeply care for alex specifically, as i've interacted with him the most, and i cherish the work he's done on the language and on the community. i don't want rich to step down, or alex to take over, or for any big changes to happen. what i want is for the community to feel like they have more input in the development of the language, for bug fixes and minor optimizations to be easier to land, and for it to not feel like they have to make a burnt offering to the Oracle of Delphi to gain insight into the process.

@nbtheduke What would make it healthy in your opinion?

As someone with a compiler and language design background, I think a lot of people really underestimate both the work involved reviewing and successfully integrating these "bug fixes and minor optimizations" as well as the often unexpected impact of these things. We've seen several such things get reverted due to unexpected corner cases and regressions. Even the core team's own work sometimes leads to a reverted change, because they'd rather revert a fix/improvement than declare the breaking change "the new normal". When you have a baseline expectation of stability and robustness -- for which Clojure is almost unique out there -- you have to move extremely carefully and try not to break things. We're so used to the "move fast and break stuff" approach in other language communities that we really shouldn't be surprised (or upset) that in order to maintain those things we value in Clojure, the project has to be run differently. Yes, I get how frustrating it can be if you have a particular bug, optimization, or "improvement" that you care about deeply and it just sits there for years. But that's your trade off for all the good stuff you get for free.

I am no one. I only know that we are so lucky for having the Nubank core team work on (and fund!) a piece of technology we all use to build products and make a living. You are all drama queens. 🤣

Folks, I would love that this thread would open the eyes of some of the problems that some users (me included) feel with Clojure. But I feel we're somehow failing to convey the issues. For example: I mentioned problems in CLJS, including tickets that got no attention; one answer was that "major" is the default priority, so we should paid no mind. I wish to focus on how this is damaging to the language - somebody opened up a ticket, it's on Jira for 3 years, and nobody reviewed even the priority? For 3 years, we have literally nothing - no interaction at all? Other dismissive comment was "how is this related to Clojure". So... one of the selling points (for me, at least, but I know lots of other people that used that) was to share code. That we could use our beloved libraries on both Clojure and ClojureScript, and reuse most of the code. This is still true... so CLJS not integrating with new libs is really losing a big selling point in my view, even for Clojure.

Mentioning a ticket in clojure-dev or cljs-dev when it re-annoys you helps too. At least from my experience. Who has the time to review 3 year old JIRA issues every day when there's so much other stuff to do?

If the only signal we’ll accept to mean that “they’re listening to the community” is that they prioritize the particular thing I’m focused on, that’s unsustainable. If we can agree collectively on what’s priority, that’s different. It’s still someone’s decision whether to work on/include that or not, but it’ll warrant attention at least.

no one said anything about clojure.core development being easy. if fact, many folks have expressed an understanding that core development is hard and have a desire to help anyway (including improving the process), through testing RC, creating https://github.com/NoahTheDuke/core_regression/ (which the core team used as a foundation to build their own regression testing suite), writing patches, discussing and triaging issues, etc. the core team has spoken at length (especially alex) about the challenge of getting core contributors to approach problem-solving the "correct" way, but there is not an onboarding process of shepherding newcomers, building trust with long-time contributors, or spreading the work among a larger group of people. the funnel is as it has always been: core team (4 people by my count: alex, jarrod, ghadi, fogus) triages a small number of issues, rich oks a subset of those. no matter how many people in the community write patches or clean up issues or discuss potential solutions or vote on asks, the limiter is alex -> rich. the reason for this is that rich is the only one who oks patches (alex is now the one who does the actual merging/releasing), and as far as i can tell from the outside, alex is the only one who can say "this patch is worthy of rich's review" and then get him to look at it.

I also don't feel it's too productive to say "business problems". These are real problems: supposing I am a CTO, never heard about Clojure, some developer that I trust mentions that we could make a product in it. I see Jira, see tickets marked "major" with no activity for years. I see posts of people that moved away from Clojure dated 7 years ago, mentioning the same problems of posts dated 1 year ago. I try a simple app and get back a horrible stacktrace and error messages; then I look at State of Clojure interview, and see that 2024, the biggest "area of improvement" was error messages; and that 2025, this question (area of improvement) was removed. Now, as a CTO, it seems clear that the same problems the language had in 7 years exist today; that people don't feel their problems are being addressed; and that this is a big risk for my business -supposing I have a bug that might be game-breaking, will it be addressed? I, as a Clojure developer with some exp, know that there are no game-breaking bugs in Clojure (not so in ClojureScript) but will a CTO with no prior knowledge know?

Java has major tickets open for several years too if I'm not mistaking. It's much much harder to get in touch with those folks :).

Has anyone ever been in a company that maintained a Clojure fork (which is easy to do) with bugfixes that couldn't be dealt with in user space and were mission critical? I haven't but it would be interesting to hear those data points.

is it? the https://mail.openjdk.org/archives/list/compiler-dev@openjdk.org/ is public and anyone can email it, and they use https://github.com/openjdk/jdk so you can open a PR or leave a comment on anything you want. i don't know if it's open to the public like that, but it's certainly more open about the ongoing development than clojure

assumption disproven, thanks Noah :)

re: forks, i know @seancorfield used a fork of core.async for a while (maybe still?) due to certain bugs not being addressed/patches being rejected

but that's not clojure.core which is a much bigger switch lol

(I was just going by my experience of submitting a bug to Oracle through some form of which I never got any feedback except that it was fixed at some point)

@nbtheduke Thank you for the detailed write up. It focuses on one specific thing from that list, and it's helpful. And yes, it seems that at least you and I don't agree on what's healthy for the community. :) I cannot say that the current state of affairs is the best that it could be, but at the very least it's a local maximum with no other maxima in my sight. As I mentioned, I've paid close attention to how it's managed in some other languages, and I am definitely not a fan of the outcomes. Even if the community might feel better. But of course, that's all conditioned on the limits of my own purview. Maybe there's some language that I don't know much about where the approach is different and the results are better. It would be good to learn about it. > what i want is for the community to feel like they have more input in the development of the language, for bug fixes and minor optimizations to be easier to land, and for it to not feel like they have to make a burnt offering to the Oracle of Delphi to gain insight into the process. And how exactly could this be achieved, by what alterations to the existing process where you already can contribute (albeit with no obligation from anyone to accept that contribution)? > there is not an onboarding process of shepherding newcomers, building trust with long-time contributors, or spreading the work among a larger group of people That would increase the number of contributors, and probably even increase the amount of meaningful contributions. Which, in turn, would increase the load on the core team. Which would be an opportunity cost. So in essence it's the same as prioritizing specific issues over other issues. Perhaps there could be a hypothetical new team of people who focus on a high-impact low-potential-for-problems issues. But who should make the call whether an issue matches those criteria? A natural reaction to that is that the core team should be expanded. And maybe, but I'm not in a position to properly assess that. :) @mauricio.szabo My writing can be blunter than one's used to, I'm sorry. > I mentioned problems in CLJS, including tickets that got no attention; one answer was that "major" is the default priority, so we should paid no mind. I never tried to insinuate the last bit. I only meant to say that an issue being marked as "major" is not a data point at all. > somebody opened up a ticket, it's on Jira for 3 years, and nobody reviewed even the priority? For 3 years, we have literally nothing - no interaction at all? Could it be because nobody was interested, apart from the people in the original interaction? The linked "ask" has a single upvote. Why should it be properly triaged, why should there be more interactions? Why this specific issue and not dozens and dozens of other issues with a higher upvote count? Genuine questions. > Other dismissive comment was "how is this related to Clojure" Not a dismissive comment - a question. > share code. That we could use our beloved libraries on both Clojure and ClojureScript, and reuse most of the code. This is still true... so CLJS not integrating with new libs is really losing a big selling point in my view, even for Clojure. I'm confused - how goes not being able to use a specific NPM library go against sharing the code between CLJ and CLJS? If a library is for both CLJ and CLJS, surely it won't be on NPM. > supposing I am a CTO, never heard about Clojure, some developer that I trust mentions that we could make a product in it. I see Jira, see tickets marked "major" with no activity for years. I see posts of people that moved away from Clojure dated 7 years ago, mentioning the same problems of posts dated 1 year ago I believe you can do the same thought experiment in pretty much any area. Like with my "beloved" Python - plenty of people have switched from it due to GIL. Uncountable hours have been spent on discussing GIL by the community. And even the BDFL and the core team have somewhat participated in those discussions. But what do we have on the Python's wiki? "Getting rid of the GIL is an occasional topic on the python-dev mailing list. No one has managed it yet." Same with their package management. Same with consistency. And so on, and so forth. > I try a simple app and get back a horrible stacktrace and error messages; then I look at State of Clojure interview, and see that 2024, the biggest "area of improvement" was error messages; and that 2025, this question (area of improvement) was removed. This is an interesting point. I think I remember Alex saying that it's because that area already landed "into the hopper" and is being worked on. But I could be misremembering. > supposing I have a bug that might be game-breaking, will it be addressed? I always wonder why it's such a big deal. If you have a bug in your setup that affects you, you can always go and fix it. Clojure is simple, it's trivial to fix bugs in a way that makes things work in your particular setup. > not so in ClojureScript Our judgement of bugs could differ, but from my perspective all such issues in CLJS stem from GCC. And fixing GCC is like fixing JVM - at least the way I see it. Incomparably harder than fixing some issue in CLJ/CLJS. But a fair point when it comes to discussions on whether to bet on CLJS or not.

@seancorfield As someone currently working on a compiler and language, I can only agree with your point of view and I believe too that such projects must be run “differently”. However: > that’s your trade off for all the good stuff you get for free I read this as both dismissive, and a false dichotomy. I’m thankful Clojure can be used for free and grateful of the effort you and other admins of this community are putting in. But this free access and free usage are not my decision and not my responsibility. Freeness doesn’t force me to accept an implicit dichotomy in management practices. I’m free to leave and I’m free to contribute. Multiple answers in this discussions pointed out to what, IMO is a recurring issue: many aspiring contributors get pushed back for the wrong reason. It’s perfectly fine to disagree on priorities or perceived impact of some changes. Those are pragmatic reasons. What I find damageable to the community is to hear again and again from many people a rethoric that I percieve and will caricature as so: (Note I’m not pointing at you nor attributing this to you in particular) > “We know things are not great but you don’t realise how hard it is, we are the experts, we owe you nothing, and we don’t believe you understand the problem correctly. This is a made up issue, things are fine as they are. Please let us do our stuff, it’s working for us. Anyway it’s worse out there”. I find this rethoric fallacious, damagable, and from an external point of view it looks like an echo chamber. • Yes “it’s hard”. Dealing with people who do not understand the problem domain deep enough is to be expected. • “We owe you nothing”. Correct. But there’s a community and people willing to contribute. Implying prior or current decisions and practices are open to productive criticism. • Yes “it’s worse out there”, but it shouldn’t prevent us to improve. • “we don’t believe you understand the problem correctly” – maybe, or maybe I do and the problem is hard enough for communication to fall apart immediately unless both parties invest in understanding the issue.

@p-himik I agree with your last answer. Framing this as a resource issue makes sense. > Which, in turn, would increase the load on the core team. Which would be an opportunity cost. > So in essence it’s the same as prioritizing specific issues over other issues.

if you have a "bugfix that couldn't be dealt with in user space and was mission critical", we absolutely want to know about it, please make a fuss. in reality, that is not the realm of most things in jira. There are about 330 https://clojure.atlassian.net/issues?filter=10183 in the Clojure jira right now. Maybe 5-10% of those already have https://clojure.atlassian.net/issues/?filter=10003&jql=project%20%3D%20CLJ%20AND%20status%20in%20%28Open%2C%20%22In%20Progress%22%2C%20Reopened%29%20AND%20Approval%20%3D%20Prescreened%20ORDER%20BY%20issuetype%20ASC%2C%20priority%20DESC%2C%20key%20ASC patches (dev team has reviewed closely) in the queue for Rich to look at in 1.13. Ask Clojure is the mechanism for people to file problems and vote on what's important and we look at those votes to find signal of what's important to work on. However, there are only about 60 https://docs.google.com/spreadsheets/d/1_E5ZjQHZipUAdtPL2qFlUzTMOwkINPVqym9QEK0Gsgc/edit?gid=0#gid=0 that are Clojure problems that have more than 1 vote and the highest is 9 votes (that data pull is circa our last dev call in March). All of you can be involved here by voting on what's important to you. (Voting on everything yields no signal - choose wisely.) There are of course many more things that are improvements or addition ideas. Many of those, while good ideas, are ultimately not going to be incorporated. Clojure is a small language and intends to remain so - you have enormous power in Clojure to do things outside the core language and library.

@ggaillard "I read this as both dismissive, and a false dichotomy." -- it was not intended to be either. I meant it in the spirit of the trade offs we make in any technology decision -- we have to decide whether the benefits we get from the choice outweigh the negatives. With Clojure, we get stability and robustness and very careful development/evolution with a focus on backward compatibility. The downside is a very slow, very tightly-controlled development process. It won't work for everyone, and some people are still very vocal about the downsides but stay because of the benefits.

@p-himik to address some of the points: > how goes not being able to use a specific NPM library go against sharing the code between CLJ and CLJS No, not this. Suppose I have a code that does complex data validation. I can reuse that to validate on my backend and my frontend. But in the frontend, I want to use SolidJS - which I can't, because the two ways of working with it - JSX and Tagged Strings - are not supported (and hyperlink is way slower). It gets hard to defend the usage of ClojureScript when I can either do everything in JS (and duplicate code on the validation) or do a weird "compatibility layer" both in CLJS and JS to make both languages communicate. But also this - suppose I have hiccup, and I want to generate static HTML (on the backend) but also use the same structure to generate dynamic HTML (on the frontend). It could work by wrapping up a library in the backend, and a NPM in the front, but if the NPM is not supported...

> Why should it be properly triaged, why should there be more interactions? At least a "not a priority right now, but we accept patches" shows at least that someone acknowledged that issue. I really don't understand this argument, to be honest - people don't like to be ignored, and even a "won't do, out of scope" is better than literally nothing. > But what do we have on the Python's wiki? "Getting rid of the GIL is an occasional topic on the python-dev mailing list. No one has managed it yet" But you see - there's an answer. There's an "we know it's important, but we still can't do it". In Clojure, it feels that the answer is almost always "it's not a problem", or "you can do it userspace" (which sometimes is not true or introduces friction) - it's dismissed as "not a real problem", not even "not important" I feel.

> If you have a bug in your setup that affects you, you can always go and fix it Yes, but does my company really wants to keep a fork of the programming language? It's just another point of friction in the adoption of a technology.

side-note: they did address the GIL in Python eventually right

sometimes (oftentimes), it is not obvious even to say "won't do, out of scope".

@p-himik > A natural reaction to that is that the core team should be expanded. And maybe, but I'm not in a position to properly assess that. 😈 yes, we understand each other lol

@borkdude No clue, I quoted the wiki as of today. :)

@mauricio.szabo But... that very issue was explicitly acknowledged by dnolen? He himself created the issue. No questions were on Ask that were unanswered. What more should've been done, short of implementing it?

my 2 cents 1. 4+ years ago I had no professional clojure experience and could easily find a clojure job. The job boards had a couple new postings every month and I landed a job in <1 month. Today I have senior experience and there's 0 options for me. I have to switch languages. Blame the market and AI if you want, but there are job postings for javascript, typescript, java, kotlin, swift, go, c, c++, rust... Clojure's unpopularity is indirectly forcing me out of this community. I don't want to leave, but I have kids to feed. 2. these show-me-your-actual-issue are missing the point. It's not the right question to ask. The community wants to engage. They are willing to spend their free or paid time to contribute. They are denied of this option from Rich. He has every right to do so, it is his project. But that is the reason, period. The "we haven't had time to look at your issue", "your issue is not on ask", "your issue has 1 upvote" are consequences of the choice. The community is not unhappy because of that 1 bug, they are unhappy because of the locked process. Again, it's Rich's choice, nobody has the right to deny him of that choice. I respect his choice, and more importantly, he doesn't even have to care if I or the community respect it. But don't ask me "which issue needs fixing". The community takes issue with the process. That is the tension point. If the core team is not willing to discuss it, fine, but don't be surprised (the core team) that people are unwilling to go through your processes, because they don't like them. You want them to fill tickets, engage, and help out your way. You're asking them for extra effort, with uncertain results. The value prop is very one sided - you reap the benefits of their effort but they might not. They see it, and they ask for better balance of power/reward. 3. I see a parallel here with Linux. There were times when people said "Linus is the bottleneck". I read he was re-typing every character of every patch so he fully understands what code lands. But looking at Linux today, it solved the bottleneck, it is evolving rapidly and it has tremendous backwards compatibility. So, if the argument for keeping the status quo is to keep the project under control, with stellar backwards compatibility, there is at least one great data point that disproves the core of the claim - Linux is a millions-loc codebase with much more complex stewardship issues and it seems to work. I'm sad for clojure for the reasons above. I'd like to see it grow. I'd like to keep using it. I'd be willing to help with my limited resources. I feel powerless to do something about it.

> The community wants to engage. They are willing to spend their free or paid time to contribute. They are denied of this option from Rich. I've written a lot of clojure and never had to ask permission. I don't understand the idea that the best way to engage the community is by making changes to the clojure core library or compiler. The good news is that if you want to get involved there are several open source projects that want help and will also provide mentoring. #jank , #cljdoc, and https://scicloj.github.io/ come to mind.

If you have particular interests, there are also many other projects that might be a good fit. I'm happy to suggest a few.

It's not the only way to engage with the community, but it is one way that would have an outsized impact and in some cases directly benefits your own existing code

I'm fairly convinced that encouraging more contributions to the core library and compiler is not even a good way to engage the community. In part, because the core is designed to be small. Other languages and tools are designed to be batteries included. Clojure is not. Other languages and tools aren't built using primarily immutable data and pure functions which makes it easier to build software in small, decoupled, reusable parts. Clojure is. I'm having trouble thinking of a problem I've had where making a change to the compiler or core library would be the best approach. There are other things besides working on the core library and compiler that can help engage the community. The core team is doing those things and nubank is supporting them.

> I don't understand the idea that the best way to engage the community is by making changes to the clojure core library or compiler perhaps you don't care about better error messages, hot code reloading issues, improved jvm interop, access to new jvm features, bug fixes, performance improvements, the list goes on. How would you fix these in cljdoc? If clojure works for you as-is, I'm happy for you. But let's not pretend it works for everyone. "Open source is not about you" was at least a direct answer. What you said is not and is unhelpful and derailing the discussion

To be clear I don't expect a change, just trying to properly frame the problem so we stop derailing

I do care about https://clojurians.slack.com/archives/C03S1KBA2/p1756162447266729, but I don't think improving error messages is best solved by making changes to the core library or compiler. For JVM interop, I've been using the new method values and they're great! If you're interested in performance, the #performance channel is great. I don't understand enough about what you mean by those other problems to know why they are best addressed by making changes to the compiler or core library.

to be fair, core has put a lot of effort in better error messages in clojure 1.10. the last release 1.12 got some serious JVM interop improvements. the list goes on. hot code reloading: there's been a few libs around this. e.g. tools.namespace.refresh and recently Niki's reiteration of this which solved all of his personal problems in user space. zero changes to the compiler.

@smith.adriane I'm so looking forward to your IDE presentation at DCD ... and your phone REPL talk too :)

edit: removed at mod request, ad-hominem in their opinion

"Solving hard problems starts with respectful dialog" — Stu Halloway

@dustingetz I don't even put "Rich" actually. Time after time, I had to explain why core.async is the bad choice for ClojureScript. It's always "you have to prove it" and when I do, "this doesn't affect most users", and then "you failed to convince me". Heck, there are even examples on this thread of this behavior of "nothing is wrong" <shows what's wrong> "this isn't a problem" <shows why it's a problem> "Well, it works for me" 🤷

I think there's a difference between being "unconvinced by a proposal for the core team to work on a particular problem or accept a particular solution" and being told "you're wrong and this isn't it a real problem" that seems to get lost in the retelling. I've read several of the threads that were supposed to be examples of the core team ignoring the community, but every thread that I read, the core team engaged thoughtfully and respectfully. Maybe I'm missing something, but I don't see any communications that can be characterized as rude or dismissive. As far as I can tell, every problem and suggestion was followed up with requests for more information to understand the problem. Not every problem was addressed the way the asker wanted. I'm sure there's room for improvement. But to say that the clojure core team is abusive seems like a gross mischaracterization. I'm sure I have different problems than others, but I really appreciate the work the clojure core team does (and doesn't do).

> error messages would best be addressed by improved tools When Sentry fails and prints me a stacktrace, the tool won't solve; when the web handler catches and throws the error in the handler, the tool won't solve it; when I am running my test and I see expected <insane-big-nested-map>, got (not= <same-insane-big-nested-map>), the tool won't solve it. Yes, it can happen in development, but only in the very narrow case of "evaluating a code in my editor".

I will agree to disagree about the error message issue since I do think that would be truly offtopic. If you are interested in solutions that could solve your problem without changes to the core library or compiler, ping me in another thread.

It is off topic and derailing from the core of the discussion. Yet again, narrowing scope and trying to prove through that narrowed scope the core argument is wrong. I understand the intent and appreciate it, but it's another proof of the communication barrier. I was misunderstood but I don't know how to make myself clearer. Points haven't been addressed, some were cherry picked, and the thread dilutes

One thing I notice makes it difficult is these complaints are the results of dialog that has occurred "off screen" for other participants. There are conclusions and experiences that you've reached and take for granted and the other members of the conversation have not gone through the same steps so these come off as logical leaps. I'm not sure how this gap can be bridged besides one of two - Dude Trust Me or story time over drinks.

We need a venting session at the conj maybe? ;)

Maybe scicloj can organize an airing of grievances.

lol my goal is to cause change

it goes both ways ;)

drinks are on me

For me it's still on-topic. The thread was why people feel the language is falling apart, and is distancing or repelling users. For me, this is a clear example: address a point, gets dismissed. Sorry, but I can't shake this feeling that my argument of "we need better error messages" was dismissed with "no, that's not valid, better tools will solve it". Happened a lot in the lifetime of the language too - spec2, Socket REPL, ClojureScript REPL integration (that was indeed solved by Shadow, but if I'm not mistaken it did require patches from core, so it wasn't 100% true anyway)... but I think we have sufficient examples anyway. I hope things change, because again, I love the language. That's all I can hope for, that somehow we can understand that being told, over and over again, that "this is not true" isn't sustainable (even if that's how we are, indeed, feeling). As an insane counter-example, I always ask in #shadow-cljs the most insane and bizarre things (how do I integrate with the WebSocket that Shadow uses? How do I wire up some tool that runs between compilation steps? How do I re-route the hot-reload process? How do I essentially break the compiler you so carefully made? 😆) and I always get a satisfactory answer.

> and I always get a satisfactory answer. You got lucky, that's all. :) Thomas has thrown around quite a few lines with the general meaning of "the way you want to do it is wrong and I won't do anything in shadow-cljs to make it right". :D

> Sorry, but I can't shake this feeling that my argument of "we need better error messages" was dismissed with "no, that's not valid, better tools will solve it". I'm not sure if you're referring to what I said (it sounds like you are), but this is not what I intended to convey. • I agree error messages can be improved • I would like to help the solve the problem • I think the best approach is by improving tooling • I am unconvinced that the best approach is to make changes to the core library or compiler, but I could be convinced otherwise. I have read your messages and the links you shared and remain unconvinced. If you're interested, I could provide lots of details that I think would be too long to be appropriate in this thread. "I am not convinced by your proposal for other people to work on it" is not the same as "you're wrong and this problem is invalid".

But I feel Thomas always at least pointed me to why it was wrong, and what could I do to make it right. It was never a "this is not a problem", maybe a "this is something we can't and won't solve, you can use <X> and <Y>". He also throw a fair share of "this is a problem only you have" to me too, but... well, he was right in those cases hahahhaha 😄

@ben.sless the core argument / pain point is simple, there's a categorical denial clojure's development process hinders itself. The ones that deny it resort to cherry picking a problem and "proving" you can solve it yourself, after which the questioner says to feel unheard. This thread is another example, you can see multiple users voicing their frustration, feeling their thoughts / ideas have been distorted

I don’t really understand the general problem here. Is it: 1. “I don’t want to maintain a custom fork of clojure with my fix” 2. “I really want everyone to have the benefit of this fix” 3. “I don’t know what the fix is, but there is a bug here and the core team should fix it” To which there may be different solutions to solve issues regarding visibility, action etc?

There are plenty of fixes, sometimes people have multiple competing patches on jira

i've written somewhere between 2 and 5 patches in the last year alone, i know ambrose has written... 10 patches? most patches are not looked at, most tickets are not looked at

Engaging with this topic in this thread context is not really feasible for me at this point (and I am traveling for the rest of the week), but I am happy to chat about these topics at length in other contexts. If you want to join the next Clojure dev call (which we are now doing quarterly-ish), we should have time for q&a. Magda will post an invite soon but it will be on May 26

If you have a question about a specific ask Clojure / jira / issue, #clojure-dev or #cljs-dev are good places to post those for discussion (1 thread per topic)

lol that's kind of you, alex. i don't think anyone is expecting you or the rest of the team to respond in here.

No idea what means, nothing is falling apart. The Clojure team at Nubank has more people, budget, and projects than it has ever had

I heard something like that before, not sure when or from whom. IIRC, that time that feeling was driven by two factors: • A perceived lack of velocity • Old open issues (pet peeves) So for that person whom I remembering, that feeling would go away if the core was objectively falling apart. :D Churn for the sake of churn does add to the feeling of "things are being done".

When our company bet on Clojure(script) back in 2015 or so, I was a bit worried about Clojure's risks. For a long time, Clojure is alive and kicking ass. I never worry about it. I worry about global economic or energy collapse.

i think there are many instances where there are bugs or "undefined behavior" (garbage in, garbage out) that are not given attention by the core team even tho there are potentially useful patches, bugs that folks have to work around and the community learns to help steer folks away from. bugs that in other languages would see fixes much faster

that can lead to the sense that the language is not well maintained or that the folks in charge don't care

for better or worse, this is the effect of the "open source is not about you" approach to software maintenance. clojure is rich's project, no one else's. he decides what is worth spending time on, what should be fixed, what should be developed. nothing enters clojure core unless he says so.

most of the time, it doesn't matter, but when you hit a bug and see that the jira ticket is 10 years old and has a patch and hasn't seen movement, it can feel like the folks in charge don't care

As I said in a reply to Dustin in that thread, Clojure is the most stable and robust language I've ever used, and we've been using it in production for 15 years. I asked him to expand on his "falling apart" comment. I have no idea what he means by it.

I guess we could ping @dustingetz here as well

Since talking to Christoph about this topic last summer, I started an internal list of Clojure-layer issues that I encounter (1) when helping Electric users debug their apps, and (2) in client projects, in particular ClojureJVM projects on large Clojure codebases. I can publish the list, but it will take some effort to clean up because the list is going to be attacked and come under scrutiny.

As an aside, I am aware of several Clojurescript to Typescript rip and shifts (it comes up in Electric sales discovery, the most common pass reason I get is "we just haven't had a good time with cljs and don't want to invest more in that direction"). ClojureJVM is harder to rip, I am only aware of one company that actually pulled the trigger on that (Reify) but I am aware of two others (a Series C and a Series D) where ClojureJVM rip is on the roadmap.

Core is in denial, the numbers have been trending down for years

The only reason I know these things is because I have direct financial incentive to talk to my customers and prospective customers and actually understand the ground truth

Aside from your specific issues, which I'm curious about; Even if it were true that Clojure's usage is declining (which is very possible), would you expect Clojure to follow wherever the software dev trends of today are going? :)

my previous job was at a place that was moving to typescript from clojure jvm, but they weren't tearing out the clojure because no one knew it well enough to rewrite it lol

I think CircleCI is one of those companies that's ripping Clojure too

nowhere did dustin say anything about following software (dev) trends

oh sorry, I was misunderstanding "trending down". I'll await further clarifications and hope to see a fruitful discussion

internal lists of issues don't help the dev team prioritize efforts, so would very much like to know about those. if it's easier to connect privately to Christoph or me, happy to receive feedback that way too. I don't think anyone is "in denial" about the state of the world. We're investing significantly more this year in marketing and research (Clojure documentary is the most obvious part of the marketing efforts, more things in the hopper).

As a new member to this community and who is looking to adopt Clojure, it is a bit concerning to read that businesses (Series C and D) are looking to move away from CLJ/CLJS. It would also help to know what the reasons are and how they can be addressed. It is good to hear that the Clojure team are open to reviewing the 'Clojure-layer issues' and hopefully Dustin's 'ground truth' experience can be addressed. Beneficial for new comers like me (and others as well I'm sure), who are considering Clojure for their business.

Three more comments from me. 1. Everything is "trending down". We are in a historic crisis. Everyone is extremely worried. 2. Internally we don’t have issues with our Clojure full stack, and we are doing complex stuff in many projects. 3. People like to complain a lot. And they lie too. Maybe they use Clojure as an excuse not to buy your product..

It is not all Clojure's fault, the American tech economy got kind of "corrupted" by the venture/saas boom which has installed very problematic management practices. But it is also true that the two subsegments i mentioned (big ClojureJVM codebases, and ClojureScript codebases of nontrivial size) are frustrated

as another counter-anecdote, I sit inside the company with the biggest ClojureJVM codebase and deployment, and Clojure/Datomic are a critical reason why we can operate at high scale for low cost. As of our last https://api.mziq.com/mzfilemanager/v2/d/59a081d2-0d63-4bb5-b786-4c07ae26bc74/a92788ef-9064-8a32-845d-aa71dc6cb506?origin=2, we had 131 million customers and our cost to serve per active customer was $0.80. I am not saying this to dispute what you are hearing Dustin and we are keenly interested in knowing what's not working where it's not.

I have an NDA w/ Nubank and cannot really talk about it here, but suffice to say that I am aware of some of nubank's "problems" even just through Rich's private statements on the matter. Nubank has big numbers because selling american-style credit cards into a historically predatory and unbanked market is a great business

Stripe is built in Ruby, same ballpark valuation last I checked

so you agree that you can build highly successful market competitive businesses on Clojure :)

yes

at scale, every language and code base has problems. scale is hard. give me the levers of Clojure over any other language any day

It's quite telling that Rama was built in Clojure, I guess?

Clojure is world class at experimental cloud infra and experimental distributed computation, but the companies who are trying to shift off are not doing that

datomic, rama, electric - arguably impossible or unfeasible on any other stack, that is the reason I am even here

there are truly hard (non-technical) problems with the vicious/virtuous cycles that exist in choosing and succeeding with technologies in business. as you know from talking to Christoph, we are trying to work on this. if other people are in this CTO level or doing that kind of technical evaluation, please reach out to @neumann, he'd love to talk to you

is Rama a successful business?

I guess they only need one high scale customer to be successful :) Hoping that they'll get there

I hope so too. I have problems understanding their product (it’s an alien) and we have not explored more due to their business model. Clojure requires effort at the beginning and these days people want easy, quick wins. I would say that the entire sector (software engineering) is "trending down". I have also noticed that before social media was more “meritocratic” or "organic" and unexpected trends could arise from nowhere. Now only big players can create the “network effect”. Probably I am talking bollocks (like the British say), but that’s my honest feeling.

> I would say that the entire sector (software engineering) is "trending down That's kinda what I was getting at before ;)

I'm sorry, but I don't share the optimism on this thread. I can't talk about Clojure, but it seems that it's more or less stable; but ClojureScript situation is not good at all in my own view. For example, modern JS features are not supported for ClojureScript. We still can't inherit classes, we can't make generators in CLJS; we have absolutely no support at all for async generators (not creating one, nor consuming easily), and only recently we added async/await. Some JS code isn't supported and can't be transpiled/imported in CLJS (I remember having problems with #privateMethod() in the past, for example). There are some problems with interop in the JS world that need special configurations (on shadow, for example, it sometimes mean we need to set the resolutions of some dependencies to nil), there are issues with bundling (tree-shaking is not that better than modern tools in JS, and advanced compilations sometimes fail for no reason (to the point I have a test suite with smoke tests for the final, compile product).

> modern JS features are not supported for ClojureScript That doesn't really make anything unstable. And the same things can be said about Clojure and JVM as well. Java modules can be a PITA, same with annotations, same with other things. Plenty of cases where someone asks about "how to do X in Java but in Clojure" in #clojure and the responses are basically "just write it in Java". > There are some problems with interop in the JS world that need special configurations So much so that those problem surface even when there's no CLJS involved at all. :D

Well, when I can't upgrade any npm library because it'll break my code, and I am severe limited on what libraries I can use, then this is a problem. Maybe not "make it unstable" but more like "I'm stuck in a past version of this library", which is a risk that lots of people are not willing to take

As for "just write in in Java" - here's the point, in CLJS, this won't work. If I can't import something that contains #privateMethod for example, I can't write a JS wrapper that exposes the API in a CLJS-friendly way. I could, in theory, transpile with Babel, then import the transpiled version in CLJS, but now I have a two-step build, which is not ideal and adds quite a lot of friction to the idea of a "hosted language".

> when I can't upgrade any npm library because it'll break my code, and I am severe limited on what libraries I can use, then this is a problem It's still the same case with Clojure on JVM. But I agree that with JS it's a more frequent issue.

When it's the case that I can't import a java class in Clojure? Can you give me an example? Not use, import.

I can share some personal experience regarding the dynamics in large orgs in late funding series which I also shared privately with Christoph - as these orgs enter the stage of VC backed growth, they hire new employees faster than they can on-board them, both technically and culturally. The kernel of programmers who are bought in on Clojure and are competent at it gets diluted by hires who're there for just another job. That's the first iteration. When the second iteration gets on boarded by the first, you'll start accumulating a critical mass of employees who had a bad experience onboarding and have bounced off Clojure completely and are chomping at the bit for an opportunity to tear it out and replace it with whatever they're comfortable with.

(TL;DR It's a property of VC backed growth in my opinion)

nothing about that is unique to Clojure

True, which is why I wrote it was a property of the business structure not the language

> Feel like it's falling apart > Reminds me of Rich's rules for the original message board. Sounds like another flavor of "the sky is falling".

I think there's a general "the sky is falling" feeling around the global software developer sphere now

Understandable. And given those feelings, it's likely very hard to be objective.

It's a weird time. My personal take on the most important problems that our company is dealing with is that the choice of language is very, very far down that list. If anything, LLMs have pushed that further down. I'd love to be in a situation where choice of language would be our highest priority item (meaning that all other things that are language neutral would be solved already).

I've been in this same conversation 3-4 times per year for all the many years I've been working on the Clojure team. Clojure continues to evolve, interest new people, and be a rock solid platform (see https://www.youtube.com/watch?v=gJ9UZlr6C6M) - it's the one thing that is not "falling apart". From the numbers I have access to, I do not think the absolute size of the community is declining, although it seems ~flat. There is more new stuff coming out for Clojure - libraries, tools, dialects - now than at any point in Clojure's history (except maybe the peak in 2017 era). Clojure's interactive REPL approach has real cost and efficiency advantages in the new AI era that build on the tooling we have created for humans. There are groups of people working hard on a variety of important issues below view to increase the stability and longevity of the ecosystem. Clojure is not going away, yet also it's not ever going to be Java or Python, it will just continue to be the most popular LISP ever released. And as always, there are problems to solve, bugs to fix, marketing to write, tools to build, stakeholder convincing to do, same as it ever was, and same as it is in every language community.

As Alex was saying, I'm always happy to talk with anyone about struggles with Clojure--especially on the business side. Please do feel free to DM me, and we can set up some time.

I'm not quite sure how to interpret @dustingetz's comment about "falling apart", but yes, Dustin and I have been talking, and I am aware of companies that have moved away from ClojureScript and to a lesser degree, Clojure. @ben.sless I found your comments particularly helpful. If I were to generalize what I've seen into two categories: 1. a Clojure company tries to scale up their team quickly and runs into obstacles with training or enculturating new devs 2. a Clojure team gets absorbed into a larger company where Clojure is not used and is seen as a liability since it is niche. As for @alexmiller comments about the stats, the numbers we have indicate flat or slow growth in the community. I don't see a decline. We're experimenting with different ways to attract more attention to Clojure (like the Documentary).

Of course I think there are ways we could do better with attracting new developers, teaching Clojure, supporting projects, collaborating in the community, supporting business needs, etc. I'd love to hear about it. A big challenge is prioritizing the work given the resources we have. I'd love to work on the most effective stuff first, but we can't know what's effective without trying things, so we're definitely going to try some things that don't work as as well as we hoped.

How do you propose to help people who run into clojure.core bugs/footguns/points of friction early in their clojure career that the language is worth sticking with even tho there is no indication those "bugs" will be fixed?

i'm saying this as someone who's onboarded multiple people to clojure across multiple jobs

@alexmiller I would appreciate if you would please not invalidate my experience report or otherwise attempt to "re-educate" me, it is rude

My personal take is that the Clojure ecosystem is in more of an equilibrium. It's relatively slow growth. We have examples of adoption and examples of churning out. Because of Clojure's stability, the ecosystem can plug away like that for a long time, but pushing through that ceiling will require trying new things.

@nbtheduke I'd love to hear more about the bugs/footgus/points of friction you've seen. Feel free to DM me about it too. I know they exist, but it is helpful to know which ones are the common ones.

@dustingetz as I've said, I am not trying to invalidate your experiences and I am extremely interested in hearing more about them

> but it is helpful to know which ones are the common ones. this is why we have upvotes on ask and jira, it would be nice if we could keep using that in addition to DMs :)

That's a good point. If someone is experiencing a pain point that is documented in Ask, please add another comment noting the specifics of the new encounter and upvote it.

Those new examples and upvotes really do make a difference.

In business, you usually have one of two problems: stagnant sales or hiring new team members with no skin/soul in the game. These bring their own agenda and things start to fall apart. A lot of developers suffer from chronic FOMO and I guess that if you are in the “developer tools” sector, Clojure’s lack of coolness makes it harder. For the rest of us, many times we don’t even have to mention Clojure to the client, it’s just our secret weapon. Anyway, I always think that turning off the light for others won’t make my business shine brighter.

I also have to agree with @dustingetz - I have a strong feeling that every time we discuss things that repel users from Clojure(Script), I see the "pain points" that are shown are immediately dismissed. But also because I feel there's room to improve, these are some of my recent experiences: I love REPL-driven development, and that's also why I tried to replicate the experience in Ruby (the language I'm working right now). The REPL-Driven experience got very similar to Clojure, but: errors are better; stacktraces are better; testing is way better, no comparison. These are pain points that exist in Clojure since I started, and it didn't seem they are getting better over the years. It takes quite a bit of mental toll to read stacktraces in Clojure, especially with syntax errors, for example. This exists since forever, and I saw multiple posts trying to say "this is not a bug, it's a feature". Then I tried Jank... and oh gosh, it's such a beautiful experience!

A bit of an aside: I saw Matz is now also heavily into LLM-driven development and made some kind of https://github.com/matz/spinelC compiler>. lol

Mauricio, have you submitted asks or jira issues for any of the CLJS interop pain points you described above? Seems to me like you are describing valuable symptoms that should be analyzed for root cause. Your comments give me more to go on than the original hacker news thread.

Definitely not a guarantee for an opinionated "fix", but the more symptoms we report, the better diagnosis can be done.

I don't know if I would use ClojureScript in a new project, for example, if I had a language that could support a REPL-Driven experience, and I did implement a custom tool specifically for Shadow-CLJS such was my love for the language...

I have only done 1 Ruby on Rails project and I will never go back if I have the choice. The magic hidden monkey-patched things compared to the logical flow of clojure data through functions is what is decisive for me. The rest (stack traces etc) is secondary. Disclaimer: I only did that Ruby project in 2013 but I don't think Ruby (on Rails) has fundamentally changed.

Ruby on Rails is a framework; Ruby is a language. Sure, it's hard to find Ruby without Rails on the wild, but I don't think this is a valid comparison....

Ruby on Rails style programming isn't fostered by Ruby as a language per se I guess?

But when you must use Ruby, I guess it's nice to use it in a more Clojury way

@lambeauxworks no, I didn't; because this was pointed multiple times over the years. https://clojureverse.org/t/async-generator-functions-in-cljs-requesting-feedback/, is from 2018, mentions the same pain points I'm mentioning... and this is one of the responses (not mine, btw): > it is a bit frustrating that I keep pointing out the two main disadvantages of user-space solutions and then folks follow up with responses that ignore these points

async/await will land this week. generators can be added after that based on the same work. it was only recently that CLJS started targeting ES6 as a baseline and I noticed that David started to be more open to adding async/await (which was dismissed a few times earlier as too complicated and not adding value). but finally we will have it. As they say: no is temporary, yes is forever :)

I do agree with the throught that async/await is not critical to CLJS though, but it sure makes things a lot easier.

Btw, I've seen David use CLJS at Vouch in a way that kind of surprised me: they used TypeScript to write React components and only used CLJS for the pure business logic. I guess even he is super pragmatic and uses what works best for the project and the team, without making Clojure an ideology

and ask.clojure is running in PHP... lol

As someone that always have to debug insane stacktraces with munged Clojure symbols names because they are generated from macros that generate callbacks that are sent to promises, await is adding much more value that most people think....

yeah. that will surely help

(sidenote: I also rewrote core.async in CLJS based on async/await: it was an easy rewrite but it performed worse, the scheduling based on callbacks performed better).

But... 8 years. This counts a lot, honestly. Not trying to be negative, really, but for someone thinking about adopting a language, it can be a game breaker

David spoke at the conj. His sentiment was that it was good to wait 10 years before adopting a new feature (like Proxy) since it often takes that long for features to become fast enough and to mature :)

async/await is now 9 years old in JS, sounds about right then ;)

as someone who has expressed frustration with clojure before, i think it can feel bad to voice those frustrations and be met with a chorus of "you're wrong" or "no that's not true" or "i think it's fine actually"

I am sorry I snapped at you @alexmiller, momentary loss of composure, now that it has happened it will not happen again

Thanks for the thread @mauricio.szabo that was an interesting read. Per that thread, I didn't see any evidence that the proposal was impossible to implement in a library. Assuming it was possible back then, I think releasing a semi official cljs.promise library, to ease the JavaScript --> ClojureScript adoption path would have gone a long way with the JavaScript community.

But I definitely share the general sentiment of the thread that maybe (at the time of the post) it's not time for it to be in core proper.

Does the core team have any way of tracking library popularity? I'm reflecting on promesa and maybe the story would be different if they got a tiny bit of support from the core team? I'm not sure I'm just throwing out ideas.

The actual root cause of all the recurring pain and consternation and discord in the community, is that the way Rich mediates himself to his community (via Alex as a proxy/human sheid!!!) is deeply unhealthy, though I understand that Rich's emotions are not in anyone's control to deal with but Rich, so we are all constantly working around it and ignoring it and pretending that this is okay. He has a powerful ego, Clojure would not exist without it. But the consequence is, to be a Clojurist, is to have a choice between total submission (you must kneel), or excommunication. Every high agency programmer who climbs high enough in Clojure must face this choice.

@neumann

As a trusted advisor, you can still kneel before the king while also telling him the truth (happens all the time in history, it's literally what the advisors did)

that's a great description of the situation

as i said to christoph earlier in a dm "and i know it all flows through rich so at a certain point you just gotta practice radical acceptance haha"

Whatever the proposed alternatives might be, I have a feeling we have already seen them implemented in other ecosystems, and invariably all the impls that I've seen suffer much greater from various things. Python constantly comes to mind in this regard.

I don't fully agree with these strong sentiments. There's ample evidence of people creating their own Clojure dialects or Clojure with tweaks for special purposes. E.g. flowstorm has a clojure with small tweaks. I have a new project which uses a fork of clojure that I'm not going to annoy the core team with until I have proof that it's going to be necessary long term for certain things to work. Squint is another example of a testing bed for new CLJS features. I think it's good that Clojure moves extremely slowly and carefully. And Rich has every right to work the way he wants, keep his sanity and not give in to the pressure of a large following.

It's been very clear from the start how the project is run, and the documentation around contributing to Clojure is explicit about this. Contrib libraries are less restricted. http://clojure.org itself even less so. And then there are community libraries that anyone can build. I think you @dustingetz are being deeply disingenuous about Rich's involvement, almost to the point of ad hominem, which really doesn't move this conversation along. As others have said, if you have specific, actionable issues that you think would improve Clojure/Script for you and others, there's a clear path: http://ask.clojure.org where the community can vote on things to indicate how important it is to them.

(Another example that comes to my mind of improvements coming from other Clojure dialects: Rich was impressed by performance enhancements that the Clojure Dart team made in their persistent data structures and likely wants to have this in Clojure)

I think this tweet was created by Brian Goetz after similar rants:

Although, thinking back to my advisor analogy, there were some advisors that were honest but the king still said "off with their head" because he didn't like their advice. But nothing I've seen leads me to believe Rich will decapitate me for disagreeing so I think I'm safe.

Don't hold on to your head

Good thing I subscribe to "strong options loosely held". Good for my head.

@lambeauxworks it's not that it's impossible to implement as a library. It's because using await makes stacktraces better - and emitting await is not possible with the compiler as it was at the time. As for async iterators: https://ask.clojure.org/index.php/10896/how-to-work-with-asynciterable-interface-in-cljs. See that we have to manually emit JS code, there's no interop at all. That generated a ticket... in 2021. Marked as "major".

Thank you for the additional context.

IIRC it's been mentioned that the Priority field should be paid no attention on the Clojure's Jira. Major is probably the default value.

lol this sums up my feelings on clojure dev. i don't ever see myself loving another language like i love clojure, but i'm also quite aware of how it could be better and i want to help it improve. i don't think these are incompatible views

@lambeauxworks never read the evil overlord list? > If my trusted advisor tells me we're losing, I'll listen. He is my trusted advisor, after all. > On a more serious note, having tried to promote some contributions to Clojure in my pet area (performance), I understand the desire for rigor and that priorities may not align with mine. I won't lie and say it isn't frustrating and I'll need to muster some energy to pick it up again, but I get it.