I fail to see why that would be the case. I myself have been working with Clojure solo on decently sized project for years. There are also a lot of big OSS libraries with 1-2 main contributors.

But to be fair, it's absolutely unclear how one would compare a team size to a code base size. Maybe all the code bases that I mentioned are tiny even when somehow compared to a single person. But even if trying to imagine the extreme, I still don't see how that would be the case. My hunch is that the author of the linked comment was thinking about types and how you can find usages of MyCoolClass throughout the whole project. Well, plenty has been said on that topic and it doesn't necessarily seem that types improve some aspects that are critical to huge code bases.

That’s good to know thanks. I’m learning Clojure at the moment, primarily with the intention of using it for solo projects, so that quote surprised me a bit.

Don't listen to random singular quotes on the Internet. :) For every idea, you can find a quote that would support it - there's little merit in that.

From what I've seen working in Clojure teams over the years is that as one scales one wants a more conservative flavor of Clojure, with a type-like facility (be it spec, malli, schema, w/e) and not too many clever constructs. The nice thing is that one can gradually get there, and with whatever tools you might find best!

From my personal experience Clojure scales just fine from 1 to 110 people. In other places they have a lot more engineers. Scaling teams has more to do with people processes than programming languages anyway, you just want your tech stack to get out of the way. Clojure excels at that without any doubt.

I think as companies scale from 10s to 100s of engineers, it's beneficial to have a statically typed language. It makes it easier for new developers to make changes confidently.

There have been studies on the matter of types. Many. The conclusion is still not clear.

@U0K592YDP, that’s certainly the consistent argument that people (most often static-typers) make about dynamically-typed languages. I don’t know that it’s really true, however, particularly if you’ve architected well and have tests and major data structures covered with something like clojure.spec. I’ve heard of large teams using dynamically-typed languages quite successfully for large projects.

Deps does not have global exclusions

But if a dep is declared at the top level, that is the version used

Top level is special and always wins

Thank you!

with both deps.edn and lein, if a library erroneosly bundles a log4j, its version can get used "by surprise"

in the wild I've mainly seen this happen when libs use AOT / :gen-class

maybe I'm hung up on stack overflow rules, where you could provide "here's a better place to get help" as a comment on a question, but that wouldn't be an appropriate answer

seems like that would be a fine answer

flagging is really for spam and stuff like that

OK - thanks

there's some backstory in a previous question https://ask.clojure.org/index.php/11333/exception-thread-main-runtimeexception-unable-static-field too, same user

yeah, one of the main things I mentioned when I tried to answer on ask is that this is a really weird way to distribute an app and the setup is idiosyncratic...

for sure

and then I realized that as far as actually solving the problem, it was going to be a discussion with the user (unless the answer is just "don't use this it's broken")

ask is a good place for Q&A. slack is generally better for interactive debugging when you don't even understand what the problem is