19 ms·

Clojure Turns 15 panel discussion video

299 points by fogus 4y ago

gemstones 4y ago
While I like Clojure as a language - I have never seen a language that engendered such hatred in PMs, EMs, sales, etc. I don't know that it survives long term (in industry, it'll survive for a long time as a hobby language.)
- pelasaco 4y ago
  I like Clojure, but unfortunately for web development, there isn't a great stack and for data science/ML/AI (which is a great fit for clojure), python dominates the market. What is the niche for Clojure, or why should keep using it in 2023? P.S: I like it a lot, but either I do golang or ror for web dev, or python/pytorch for data sciences/AI stuff, C# for game development. I don't think i can get more productive with Clojure in any scenario, that I'm exposed too, what I'm missing?
  - ARandomerDude 4y ago
    It is actually a great choice for unopinionated server-side web development. Frontend development is simply awesome in ClojureScript. Give me Reagent + Shadow CLJS over plain React (or React Native) any day.
    - moonchrome 4y ago
      >Frontend development is simply awesome in ClojureScript Is that still tied to that google closure abomination ? I've not been in CLJ ecosystem for >5 years now but last time I used CLJS I remember they went all in on google Closure and it was a major PITA to use the rest of JS ecosystem because of it. Every time I use React I think how it would be great to use Clojure for that, but last time I tried the tooling overhead just killed it for me.
      - lgessler 4y ago
        > Is that still tied to that google closure abomination ? I've not been in CLJ ecosystem for >5 years now but last time I used CLJS I remember they went all in on google Closure and it was a major PITA to use the rest of JS ecosystem because of it. This has been solved now--there's a blessed CLJS solution[1][2] as well as a third-party compiler with NPM support[3] which many prefer. [1]: https://clojurescript.org/news/2017-07-12-clojurescript-is-not-an-island-integrating-node-modules https://clojurescript.org/news/2017-07-12-clojurescript-is-n... [2]: https://cljs.github.io/api/compiler-options/npm-deps https://cljs.github.io/api/compiler-options/npm-deps [3]: https://shadow-cljs.github.io/docs/UsersGuide.html#npm https://shadow-cljs.github.io/docs/UsersGuide.html#npm
      - simongray 4y ago
        Shadow-cljs makes everything very easy these days.
    - ndr 4y ago
      For you and anyone else with experience, is that the most common/battle-tested cljs stack? What about servers-side, any equivalent Django or FastAPI?
      - dgb23 4y ago
        If you want a complete, integrated "stack" that stitches some of the most common libraries together in a uniform structure you might have a look at kit: https://kit-clj.github.io/ https://kit-clj.github.io/
        cutler 4y ago
        If you're coming to Kit from Luminus make sure you understand Kit's use of Integrant which involves passing `query-fn` down from the route to every function which accesses SQL. It was a deal-breaker for me.
      - dack 4y ago
        The cljs stack I hear about a lot (and use) is ShadowCLJS with reagent (https://reagent-project.github.io/ https://reagent-project.github.io/) and re-frame (https://day8.github.io/re-frame/ https://day8.github.io/re-frame/). ShadowCLJS is more of a build tool, but is really well documented and easy to use. Reagent is basically react but a simpler API, and re-frame is a layer on top of that kinda like redux. It's overkill for some apps but I find it's actually super easy to work with and not as much complexity as I thought. For backend there is luminus (https://luminusweb.com/ https://luminusweb.com/) or Kit (https://kit-clj.github.io/ https://kit-clj.github.io/). They are basically project templates that wire together a ton of popular solutions for various things - database access, migrations, security, html templating, etc. Also includes frontend frameworks like re-frame if you want. edit: forgot to mention fulcro (https://fulcro.fulcrologic.com/ https://fulcro.fulcrologic.com/) which is an interesting full stack solution. I haven't used it though so can't comment, but it sure seems documented well!
        ndr 4y ago
        Thank you. What about leiningen vs boot vs deps.edn? Did any of this come ahead as a winner in the recent years? It's been a while since I've looked into this.
    - pelasaco 4y ago
      Yes, ClojureScript is definitely on my learning list, we however decided to avoid one more transpilation tool, and accepted the fact that we have to write typescript. > Give me Reagent + Shadow CLJS over plain React (or React Native) any day. So that is for heavy js based applications, not for something light like rails + stimulus.js, right?
  - lgessler 4y ago
    > I like Clojure, but unfortunately for web development, there isn't a great stack What do you feel is missing? Certainly there are options (something as frameworky as Fulcro, something as barebones as a React wrapper like Reagent), so there must be some itch you can't scratch?
    - pelasaco 4y ago
      wow, first time seeing Fulcro, and it has a great documentation https://book.fulcrologic.com/ https://book.fulcrologic.com/, definitely will play with that, thanks!
      - lgessler 4y ago
        Yeah, it's too heavy for some things, but it's situationally very awesome. Fulcro takes the fantasy of "reusable components" very seriously, more seriously than any other frontend framework I'm aware of, and designs from the ground up to allow for that. Be sure to go to #fulcro in the Clojurians slack with any questions/comments--it's a very friendly community in there.
  - Heliosmaster 4y ago
    Check Clerk (https://clerk.vision/ https://clerk.vision/) for the boundaries between data science / data viz / moldable programming
- dgb23 4y ago
  Clojure is not a hobby language.
- taeric 4y ago
  I'm intrigued, why do the PMs and such care? (I'm assuming EMs is Engineering Manager?)
  - gemstones 4y ago
    Clojure is really good at self-selecting for people that really care about innovation in programming languages. The other jobs in a tech company care about innovation in their domain. They rarely align. So for every weird, cool innovation you see, the productivity is immediately lost because people equally care about how you deal with state on app startup, or routing, or database interaction. And since none of those other things move the needle much in how you compete in your business domain, competitors who are not concerned wind up eclipsing you. While you're arguing integrant vs. mount, people are just running dotnet new and bikeshedding over things closer to the business domain. PMs/EMs/QAs/etc. may not have technical knowledge, but they smell something off about programmers arguing about what library to use for routing. Why didn't people complain about this at their past jobs? Surely if it was important, it would have come up. They just perceive you as having hired a bunch of senior people who are incredibly slow relative to their past companies. It really breeds resentment. I have seen clojure-first companies creatively hive off parts of their engineering org to have a separate org that is allowed to use a different stack. They're not super transparent about it to avoid a big exodus of people, but I've personally seen it happen more than once.
    - dgb23 4y ago
      > Clojure is really good at self-selecting for people that really care about innovation in programming languages. The other jobs in a tech company care about innovation in their domain. They rarely align. To me it seems people typically like Clojure because of its simplicity, stability and productivity with the REPL. There are innovations in Clojure (its data structures, transducers...) but overall it is a pretty conservative and minimal language with laser focus on pragmatism. Also in terms of slowness it seems the opposite is the case from my limited knowledge. OS authors and contributors seem to be extremely productive and creative. There are some notable Clojure shops (see: OP) that have been growing at an incredible pace. Maybe I see this differently because I come from a [insert two very popular languages] background where everything breaks every couple of months and the culture is severely fad driven. To me Clojure is refreshing, calming and more powerful on top.
- eduction 4y ago
  This is a reasonable comment, even as a Clojure fan, I think this fits with how the community thinks of itself to some extent. I can't provide a specific citation but I know there is at least one talk (maybe Simple Made Easy but don't quote me lol) where Rich Hickey talks about the fact that one reason "easy" tools -- which in his view provide fast uptake but more problems down the line due to being "complected" in how they deal with various concerns of the underlying problem -- are so popular is that people who manage programmers (like some of the positions you mentioned) want to be able to easily put butts in chairs, to readily replace engineers like they are cogs in a machine, so they are very willing to make this trade of short term ease for long term pain because less training is required to get to a near term deliverable. It's also clear (see Hickey talk Effective Programs, 10 Years of Clojure, where he surveys the room) that Clojure programmers tend to be senior (real senior not 5 years experience "senior") and a little grumpy about the state of the art, opinionated, and don't want to be cogs. This may also explain the allergic reaction among people who manage programmers/engineers. Managers as a rule (especially at certain orgs) tend to want people who are more compliant and less free thinking and likely to push back. Anyway I think you make a good point except I disagree about its survival long term. I think there's something to be said about the value of being more popular among older more seasoned programmers vs PMs. How many PMs in the 90s foresaw the rise of Linux (vs proprietary unix and Windows), how many go overboard on "agile", how many were into ruby on rails before it picked up among programmers, etc. Managers tend to be a lagging indicator (speaking very broadly).
  - munificent 4y ago
    My impression is that Clojure (and Lisps in general) are about maximizing the productivity of an individual where other languages try to maximize the productivity of an entire team. There are trade-offs to be made in either direction and much of what affects the feel of languages on either side of that comes from the choices they make around those trade-offs.
- sanderjd 4y ago
  Why would PMs and sales people have any opinion whatsoever on this kind of detail?
BaculumMeumEst 4y ago
I love Clojure the language but I’ve never seen a more fragmented ecosystem. There seems to be a pattern in the language of “a problem emerges > a community solution gains traction > Cognitect develops their own solution but its weird and undocumented”, like deps.edn over leiningen, spec over malli, pedestal over ring, etc. Many prominent clojurists recommend deps.edn over leiningen and socket repl over nrepl, but I’ve seen very little guidance on how either actually work or how to use them. Spec seems kind of weird and not well thought out either. And Clojure CLI tools also seem like a total shitshow compared to go or rust’s tooling. As a result working with Clojure feels puzzling and unpleasant, and I feel hesitant to use any community library or project in the language.
- dgb23 4y ago
  > deps.edn Deps is well documented. The issue I personally found is that I needed to look at a bunch of OS project's deps.edn to see how people commonly structure things. Other than that it is a simple tool. > socket repl over nrepl I personally use Calva (VSCode) which just starts an nrepl based on deps.edn. When writing babashka scripts I start the repl manually and connect to it. Very pleasant experience so far. > Spec seems kind of weird and not well thought out either. I didn't like it at first, but once I got that everything is bottom up I had an AHA moment. Function specs and instrumentation are very powerful. Conform is basically a parser, which can give you a lot of leverage. What bothers me about spec is that it is still not released though.
  - billfruit 4y ago
    Deps may be well documented, but lots of introductory material seems to use lein. Having two systems is more confusing.
    - seancorfield 4y ago
      Because a decade ago there was only Leiningen -- so all the books and tutorials (and videos) created in the early days of Clojure had to use it. At work, we started with lein (back in 2011 for our production code), then we switched completely to Boot in 2015, and then we switched completely to deps.edn in 2018. build.clj (tools.build) is a "recent" addition (less than two years since the very first 0.0.1 commit). More and more introductory material is appearing these days featuring deps.edn but given there was a decade of Leiningen usage out there before deps.edn even appeared, the current state of affairs shouldn't surprise anyone. As for more than one system, lots of languages have that situation: consider make -> ant -> maven -> gradle etc.
revskill 4y ago
I tried Clojure, but when i look for a good ORM, what i see is a paid library.
- snorremd 4y ago
  In Clojure ORMs aren't really that popular considering most Clojurists just use the built in datatypes (e.g. maps) to represent data. There are no classes as such (unless you use Java interop). If you need a query builder the honeysql library is really nice.
  - rawoke083600 4y ago
    Lol yup ! "It's Maps All The Way Down"
  - danuker 4y ago
    > just use the built in datatypes (e.g. maps) Well, then, MRM: Map-Relational-Mapper.
    - Zak 4y ago
      There's https://www.hugsql.org/ https://www.hugsql.org/ for example. It takes maps for inserts and updates, and returns maps for selects. Other database access libraries over the years have typically shared that characteristic. If you want to convert between maps that map directly to tables and some other structure, manipulating maps in Clojure is easy.
  - camdez 4y ago
    Expanding on this a bit, Clojure, as a language, is fundamentally against the idea of ORMs in its design. Objects / classes are not so much the problem, per se—it's specifically that ORMs fundamentally involve scattering uncoordinated mutable state throughout the application. A foundational thesis of Clojure is that mutation is a tremendous source of bugs, and should be avoided / thoughtfully limited. Once you let the unmanaged mutation genie out of the bottle, it's almost impossible to put back in. More concretely, I used to work extensively with Rails; I loved ActiveRecord (ORM) when I first started out—it makes basic things so easy. Later I worked on a large Rails app supporting millions of users...we used ActiveRecord extensively, and had a very talented team. ActiveRecord worked fine most of the time, but I have bad memories of spending hours or even days tracking down user-reported bugs. I'd try to figure out how to recreate the user's state locally, even cloning pieces of the production database to work with their exact DB data, but whatever state the program had gotten into was a large graph of (all!) mutable objects. How was that flag getting set? What code could have done it? When? And the answer is basically ANYTHING at ANY TIME that could possibly get a reference to the object. And web applications are far from the worst offenders in this space because the request / response cycle is (usually) fairly globally stateless. Clojure is the exact opposite of that experience. The state of a Clojure program will most likely comprised of data literals (think JSON data types, if you don't have experience with Clojure / Lisp data). Printable data literals. Connect to the errant server, serialize the state, read it from your machine, and you're there. It's coherent, stable, serializable, transmittable, simple. Who can mutate your data? No one. You have an immutable reference (maybe others do too, but reading is a fundamentally safe operation). How does it change? Only along the explicit path of computations you're working through (it doesn't change, actually, you choose to hold onto a new reference to derived data when you want to). Or, if you really need a mutable escape hatch (like, say, you're holding a handle to a database), every type of mutation in (core) Clojure has defined (and thoughtfully so) concurrency semantics. You won't see a bunch of notes in Clojure API docs that say things like "not thread safe" like you see in JavaDocs. TLDR: Clojure will happily give you object-like read-only views into your database (like Datomic's `datomic.api/entity`), or help you write queries with a knowledge of your database schema, but most Clojure persistence solutions will explicitly coordinate mutation into a single 'site' because that's the only way maintain a coherent view of state-over-time. And that single-mutation-site story is the opposite of what ORMs (as commonly defined) do.
rawoke083600 4y ago
I've started learning Clojure about a year ago, couldn't say it was easy (the fault might be with me and not Clojure) Clojure has a lot a faults (just look at some of the comments here) BUT and it's a BIG BUT for me... Clojure is SUPER FUN :) Over the years(15+), I've been coding in PHP (suck it haters), Go, Rust,Java,Python AngularJS+, Svelte and I can honestly say for me, nothing is more fun that coding in Clojure. It's fun testing a function in "realtime" by just "eval" it on the spot. I don't even code "in the REPL" I just use Calva and eval inline in VSCode Maybe it's cause it's my new toy but it really does bring back the "joy of coding" I've been missing in the other languages. *Learning Clojure became much more easier, once I told myself "It's Maps All The Way Down :D" Sure there are stuff like atoms that make it possible to code around the "immutability" but that is like using a cheat-code to go back to the old ways. Yes there are many times when mutable-data-structures are required, but while learning, don't grab for them as a first solution ! Anywhoo YMMV but once you get over the warts (many there are), much fun and insights awaits :)
- kelseyfrog 4y ago
  Clojure user here since 2010(my earliest Clojure project on Github), and while I agree with the fun point, the iceberg wart for me at this point is the inelegance of the interface hierarchy and its structure behind the scenes. Clojure's forward-facing interface (a hundred functions that operate on one data structure) ended up breaking down for me at some point and became 10 functions on 10 data structures and those data structures became AFn, APersistentSet, APersistentMap, APersistentVector, IFn, IPersistentSet, IPersistentMap, IPersistentVector, ITransientMap, ITransientVector, IndexedSeq, LazySeq, &c, &c, &c. Maybe I started writing code wrong. Maybe I dived too deep into the internals, Maybe it was something else. But at the end, there wasn't one data structure, there were dozens and dozens each with justifiable differences, but even so, that's not what was advertised. It took a decade to reach that point and perhaps the vast majority of folks never will. The sad part is that I know none of it is up for change without creating a Clojure2, and that highlights the problem. Why should changing the internals need to break backwards compatibility? There is one unspeakable reason: the illusion wasn't complete and they weren't really internals to begin with.
  - 4y ago
Per_Bothner 4y ago
To toot my own horn: The oldest still-active compiler-based language on the Java platform, besides Java, is as far as I know Kawa (https://gnu.org/software/kawa https://gnu.org/software/kawa). It started Summer 1996, and is still actively maintained. (Not as active as it used to be, to be true.) Like Clojure, it is a Scheme-like language, but (unlike Clojure) it is very compatible with "regular" Scheme (R7RS), though of couurse with lots of extensions. With a little bit of care (including optional type-specifiers), it is easy to write code that is as fast as Java code.
- BaculumMeumEst 4y ago
  Oh cool! That language is so fun to use, thank you for writing and maintaining it!
mrichman 4y ago
I tried getting into Clojure (I have an undergrad Lisp background). I just couldn't become productive, and the tooling seems fragmented. Been moving many of my workloads from Go to Rust.
distantaidenn 4y ago
I love Clojure (and have touted such in past comments), but it suffers from a glaring problem: every library is half done and/or abandoned. What happens is you end up modifying an existing library to fit your particular problem space. I needed a web framework. None of them just did things in a "simple way". I ended up branching an existing one and have altered it (very heavily) to fit what I need. It's now my go-to for all new projects. The issue with us Lispers is that we love the language more than we do the tooling. Tooling be damned! So we all end up re-inventing the wheel for the 1000th time. We will never gain wide spread adoption, as such. With Ruby, I have Rails. With Python: Django. With Clojure...well good luck. Every framework does one thing beautifully correct and about 10 things wrong. But hey, it's up to you to modify the framework! Because that's the Lisp way of doing things! Maybe I should publish my bespoke framework one of these days...
- danuker 4y ago
  Every early ecosystem suffers from lack of mature libraries. It is a chicken and egg problem. I think your contribution would be very welcome, especially with a bit of docs or minimal examples.
  - sanderjd 4y ago
    I don't think it's an "early ecosystem" though... I was playing with Clojure before I had ever heard of Go, Elixir, Julia, Rust, or Typescript. All of these seem like mature ecosystems now. I really like Clojure as a language, but if it's still an "early ecosystem" at this point, that seems like a problem to me.
    - yenda 4y ago
      True, although I don't know which library the op is talking about, because all the libraries I use are alive and well, some get very rare updated simply because they are "done"
  - miroljub 4y ago
    You can't call it "early ecosystem" after 15 years.
eduction 4y ago
I have been using Clojure for a solo project for a while now and find it shockingly productive. I initially planned to limit how much of the language "surface area" I explored to keep focused on solving the problem but was able to productively use much more of Clojure than I expected: -core.async for concurrency that led me speed up some tasks from ~1000ms to ~40ms (well, core.async got me to about 100ms, or closer to 5x speedup on other tasks, and then other optimizations got me the rest of the way). Also using refs for some very limited data sharing across go threads (apparently actually using refs and dosync, aka mvcc data structures, is rare). -spec for parsing a dsl and validating input -macros for a select few syntax and core async optimizations (avoiding unnecessary go block usage) -multimethods for extensibility -a fair amount of Java interop to use best in class libraries -transients to help optimize performance in some places -even transducers a few places (maybe 1 percent of my code if that, but still) -edn for dsl files I sense that where people have more friction is trying to work with other people, in teams and organizations. In the right organization this can clearly work, dedicated Clojure shops, but there can be resistance in other organizations, and it has to be "smuggled in", and people worry about the ability to hire (especially for orgs that tend not to train heavily - nubank clearly trains a lot of programmers on Clojure but many shops don't want to do this level of training). And then people will avoid using certain advanced features like macros or even some functional conventions (recursion, reduce and map etc instead of vanilla loops) because they worry it will make it harder to onboard people without Lisp or FP experience. I honestly think this is Clojure's big challenge, entrenched expectations and conventions in the industry and a desire to pull programmers off the shelf. In this talk (the one we're all commenting on) Rich and others point at the productivity and fun of REPL driven development -- finding some way to really grow that and somehow take it to the next level -- as a possible solution, to offer yet another carrot to encourage people to make the leap to Clojure. It sounds like a good idea but I have no idea what that looks like exactly. I honestly think the answer to getting more Clojure penetration may be the passage of time, as happened with python. I know nubank/cognitect has been funding some open source work with small grants on top of Alex and Rich's work (and Stuart's?). This kind of basic grunt work can pay off long term. But it's not a sexy answer and if it doesn't work you're at a dead end.
- avindroth 4y ago
agumonkey 4y ago
Can't say I'm not happy to hear Rich Hickey talk again.
olah_1 4y ago
Rich Hickey’s talks may outlive Clojure itself. In some sense, the principles he taught and aimed for were the ideal. Clojure today wasn’t necessarily the ideal. I think there could be room for a better Clojure than Clojure, so to speak
- danuker 4y ago
  Based on my analysis of Rosetta Code samples, Clojure is the most popular language with its compactness. https://danuker.go.ro/programming-languages.html#non-math-map https://danuker.go.ro/programming-languages.html#non-math-ma... Also, it has a low frequency of bugfix commits (which may or may not be related to bugs also). (but it might be the dev experience, I have not adjusted for it). https://danuker.go.ro/frequency-of-bugfix-commits.html https://danuker.go.ro/frequency-of-bugfix-commits.html In addition, the JVM gives it great performance, and it has actual CPU multithreading (while Python or other scripting languages have a GIL). This makes it relevant in today's environment where Moore's law continues through number of cores. Therefore I don't think Clojure will die too soon.
logistark 4y ago
I have the feeling that after Nubank bought Cognitech, Clojure has gone to stagnation. I mean, i feel that promoting and improving Clojure is no longer a priority. And another think that stinks me everytime Cognitech talks about Clojure they have to bring to the table Datomic. They tried to push Datomic on my company long time ago when they do some consultancy job at my company. You can skip all the talk, because is all about how good Clojure is and that is. No any eta about future features, improvements and fix problems of current Clojure users. Lot of open source contributors have leave the community, because there is any plan on Clojure. I guess that Rick Hickey is happy with Clojure as it is now, and this is the way is going to stay. And still no Java 8 support for CompletableFuture, lambdas interface, Stream api, java.time, no pattern matching, java records, this group feels like a group of old programmers stuck at Java 6 that cannot move forward.
- Zak 4y ago
  It seems to me that these things are a big deal if you're doing a lot of JVM interop and not so much if you're primarily using Clojure-native libraries. Clojure has futures, lambdas, streams, a community-maintained java.time library, core.match, and Clojure records. I'm sure there would be benefits to adopting the newer JVM-native equivalents, but I'm not as sure they're worth the costs.
- kamaal 4y ago
  I thought you might be trolling. But then when I looked at the Clojure repo on Github https://github.com/clojure/clojure https://github.com/clojure/clojure the last commit was 2 months back. There is some merit in your arguments.
  - seancorfield 4y ago
    Clojure evolves slowly and deliberately -- it gets about one release a year (with various prereleases) so "2 months" between commits isn't a big deal. I consider it a "feature" because it means Clojure is extremely stable -- which is great for us at work given that we've used it in production for a dozen years at this point and have been able to run alpha builds in production safely during nearly all of that time.
cfiggers 4y ago
I see some comments in here with the sentiment, "Clojure—What am I missing?" Here's an attempt to answer that question. I am just a hobbyist and enthusiast programmer with no formal background in programming or CS, and no real experience using Clojure (or any other language, for that matter) "in anger" in a serious production environment. These are just some nobody's two cents, take or leave them for whatever they're worth to you. From what I understand, there are some applications and domains that the JVM is highly optimized for—especially long-lived, highly concurrent server processes or stream processing applications where microseconds matter in order to keep up with real-time. The fly in the ointment (for some) is that Java itself is Object-oriented, compiled, statically typed, and uses mutable objects and data structures by default. Not everybody loves those design choices. And even of those who do, not everybody finds Java ergonomic (hence Scala and Kotlin, among others). So, much like Scala and Kotlin do, vanilla Clojure just gives access to the JVM (and its highly mature library ecosystem) in different trappings. It's a functional (rather than object-oriented), REPL-driven (rather than compiler-first), dynamically-typed, and immutable data-oriented language, with Lisp's minimal syntax and structural editing experience. Plus, the designers have invested a lot of time and their cumulative decades of programming experience into making a really solid standard library that comes with a lot of smart affordances out of the box. That combo really works for some people. Then, folks who appreciated the conveniences and good design in vanilla Clojure started looking for that dev experience in non-JVM contexts, which is how you get ClojureScript, ClojureDart, ClojErl, Babashka, Scittle, etc. And then, other Clojure-inspired languages pop up that don't purely adhere to Clojure conventions, but co-opt significant portions of its well-designed syntax and standard library—languages like Janet (compiles to C) and Fennel (compiles to LUA) and Hy (compiles to Python). And then, script kiddies like me come along and discover, Hey Wow, I can learn one syntax and suddenly be +80% dangerous in a dozen different environments, without having to start learning a new language from scratch in each one—from the JVM to the browser to mobile apps to native executables, I've got SOMETHING to start building on because I already know how to think in Clojure. At this point, "Clojure" is not just "a language," it's a category of languages—just like Scheme is "a Lisp," Janet is "a Clojure." I don't think that happens with uninteresting, poorly-designed, or irrelevant languages. Clojure scratches a specific itch, and not everybody has that itch to scratch. But whether Clojure is your cup of tea or not (and obviously for many people in this comment section, it's not), I don't think anyone can debate that it's a significant project that justifies its own existence. That doesn't obligate anybody to use it or even look at it twice, but I think it self-refutes a lot of the negativity that gets thrown its way.
jawadch93 4y ago
[dead]
rcarmo 4y ago
Nice to see, but I'm still sad Clojure is a hosted JVM language. I find it unwieldy for a lot of things where Go, Python and Chicken Scheme shine, and wish someone got ClojureScript to run natively in things like Bun or Deno so I could have one fast, small runtime.
- orestis 4y ago
  Check out Babashka!
  - rcarmo 4y ago
    It’s nice, but hardly what I need.
beders 4y ago
Lisp has ruined me forever. I'm not sure how I can go back to other languages. I basically started out with Allegro Common Lisp on Sparc's, went to Java because it was the shiny new thing, and then in 2017 finally took the plunge and have been addicted to Clojure ever since. Don't get me wrong: the learning curve can be steep, but the steepness - at least in my case - came from un-learning all the object-oriented stuff. Once you understand the value of values and the simplicity it brings, it becomes such a joy to code in Clojure. For the people on here disgusted by the JVM ecosystem: There are many alternatives for Clojure. There's Clojure for .NET, ClojureScript in at least two flavors that compile down to JavaScript, there's a fast interpreter called babashka for scripting, there's Clojerl for the Erlang VM, there's jank - which adds gradual typing on a C++ runtime. Oh, and there's jobs that pay really well ;)
- runevault 4y ago
  How is Clojure for dotNet? I haven't touched Clojure in general for years (honestly I think it's been at least a decade) but I remember a lot of libraries making calls expecting the Java standard library so seems like things would have broken, but maybe it is gotten a lot better in recent years.
  - puredanger 4y ago
    It's been kept up to parity but a complete rewrite is currently under way - watch https://dmiller.github.io/clojure-clr-next/ https://dmiller.github.io/clojure-clr-next/
    - nocman 4y ago
      I thought about doing some work on Clojure itself, but, alas, my last name isn't Miller. :-( jk
      - KingMob 4y ago
        The Clojure development process is notoriously closed to outsiders. Even in the early years, some people contributed time and code, and weren’t thanked. I would view attempts to contribute as very high risk for newcomers. I personally maintained a fork for a couple years just for an unmerged patch I needed, rather than try to get the core team to merge it.
Naomarik 4y ago
I was writing a longer comment and deleted everything after it started to look like bragging. All I'll say is that I'm extremely grateful to Clojure for the life I've been able to live and what it's allowed me to accomplish. This is truly a language for beating the averages.
elwell 4y ago
I didn't realize how nice I had it with Clojure until I went full-time Java.
- hota_mazi 4y ago
  Java is almost 30 years old. How does it compare in your mind with, say, Rust and Kotlin?
  - elwell 4y ago
    > Java is almost 30 years old. Java has changed substantially over that time period though
  - roguas 4y ago
    does kotlin offer anything more than less-boilerplate-than-java?
college_physics 4y ago
Clojure fans seem quite taken to hyperbole. If the language is such a "joy", "ultra-productive" etc I would have expected after such a long period of existence some major open source project to be showing off what the language attributes allow you to do. Happy to stand corrected if there is such a slam-dunk showcase that I've missed, I am actually interested to dig into clojure, if nothing else as a way to deepen my understanding of functional programming.
- maxfurman 4y ago
  There is something about the language and/or community that leads folks to build their own X instead of collaborating on a common open-source version of X. Perhaps the lisp learning curve is high enough to dissuade those who want to contribute to a project but don't yet know Clojure?
  - ilkhan4 4y ago
    I have a pet theory that it's because it's too easy to write code in. I think there needs to be just enough pain with a language or library that it becomes worthwhile to allow someone else to write X and just deal with it being imperfect if it still solves your problem.
    - ballpark 4y ago
      too easy and too fun. Also, to anyone interested in this problem, look for the Worse is Better paper
- doubleg 4y ago
  To name a few: https://github.com/xtdb/xtdb https://github.com/xtdb/xtdb, https://github.com/nextjournal/clerk https://github.com/nextjournal/clerk, https://github.com/penpot/penpot https://github.com/penpot/penpot, https://github.com/metabase/metabase https://github.com/metabase/metabase
  - heyzk 4y ago
brundolf 4y ago
One of the things that stands out to me in this video is seeing devs who are much older than the average dev I encounter, who have continued to grow deeper in their skills and form deeper insights, sharing some of those insights. It's something I don't get to see very often and it's encouraging
- simongray 4y ago
  That's what originally attracted me to Clojure back in 2017 when I was ~30.
vaylian 4y ago
Clojure is the language that made me understand why Lisp matters: We can express ideas and instructions in a programming language with just a very basic set of tools. And we can use these tools to craft powerful and elegant abstractions. In addition, Clojure emphasizes immutable data structures, which, after some learning effort, made me write code that is much easier to reason about.
orestis 4y ago
Obligatory shout out to Babashka [0] which is interpreted Clojure. You just download a simple binary and you can get going. Widely used for quick-running scripts, with a lot of batteries included. [0]: https://babashka.org/ https://babashka.org/
garbagecoder 4y ago
For just the right thing, I've loved using Clojure and wish I could use it some more, but I rarely find that just right thing.
munro 4y ago
I could be reading the energy wrong, but damn it looks corporate bullshit sucked the life out of Rich
- cutler 4y ago
  He certainly looks and sounds older. Rich seemed to ride the wave of Clojure's early success with a succession of brilliant presentations. Then .... nothing.
  - simongray 4y ago
    He's speaking again this year at Clojure Conj, so maybe there will soon be something again.
Barrin92 4y ago
a little bit of an offtopic question, but given that the video has a sign language interpreter, is there a specific vocabulary for programming given how many unique terms there are, and is it harer to understand for people who rely on it than normal conversation?
deleted 4y ago
[deleted]
ivanb 4y ago
The ultimate failing of Clojure as a tool is its inefficiency measured in $ per feature. The language is not very approachable for junior programmers. You can grab a Python programmer and graft them on a Java or TS project and the same week they will deliver features and bugfixes. Reading other's people code in Clojure is much harder especially when coming from imperative world. The language is terse. The documentation is terse and lacks examples. Library documentation is insufficient or non-existent. You have to read other people's code. It is a really demanding activity aggravated by lack of static typing. You cannot just hover over a map in your IDE and see its structure. The value may have come through several transformations that add, transform and remove fields. To understand what arguments a function expects you have to decipher destructuring bindings which in real code can be ingenious, i.e. unreadable. And hold on to your butts when a clever teammate invents a flow of control macro and uses it throughout. These and other reasons make the pool of candidates small, candidates "over-qualified" and expensive. If your expert quits, your whole endeavor is screwed. I helped to rewrite a Clojure project that stalled due to lack of affordable talent. It's been chugging along since then at a considerable pace. The new language is very popular and much less affected by the mentioned problems. There is a mention of Penpot in this thread. Mark my words, when it comes a time to scale, they will rewrite the whole thing in a popular statically typed language.
- mnming 4y ago
  I do agree. While I made all my projects in mostly Clojure, I absolutely cannot imagine hiring & onboarding other drvs. And if I had a tough day, my clj code will look like rubbish, while my typescript code will still look decent. It's really not a language for big team.
  - simongray 4y ago
    I have onboarded developers coming directly from university and it went fine? In fact, at my old job, the entire team learned Clojure on the job. I was the only hire who had learned it prior to being hired. Our codebase was fine and very maintainable. The other teams were similarly new to Clojure. Most people spent a few months doing increasingly more advanced things until they were comfortable with the language and the codebase. The main issue for complete beginners is learning to grapple with the different development setup compared to what they might be used to, i.e. interactive development on a live system using an editor-integrated REPL. We basically set everyone up with IntelliJ and parinfer. Paredit was optional, as was alternative editors such as emacs. IntelliJ + parinfer is a similar development experience to Python. The only part that is foreign in that case is the interactive development of a live system which the new devs quickly come around to seeing the benefits of. It helps having seniors who point out the new concepts.
ZionLloyd 4y ago
[dead]
cospaia 4y ago
Clojure changed my life. It made me realize how fun it is to code and switch back to being a programmer. This makes me a much happier person and thus a better husband and father. Never looking back. The Clojure Way just fits me perfectly.
silver-arrow 4y ago
Excellent and very productive language. Personally, I did 15 years of straight Java (before that C and C++), then 5 years of Clojure. For me, the most telling dynamic is when I recently returned to a Java project and realized how much better Clojure is - even for large projects ;) The lack of static typing, which is so often used as an argument against Clojure, is actually what makes Clojure better. The Java projects become a morass of types scattered into a myriad of packages; no matter how experienced you are with Java. Clojure's dynamic underpinnings and its paradigm of hundreds of functions for a few data structures allows for very lean designs that are easier to wrap your head around and keep in your mental models. The other features are just gravy: immutability built in, REPL interactivity, Transducers, Protocols etc. I felt the pain going back to a Java project.
siefca 4y ago
I remember writing about first official releases of Clojure around 2010 when I was an editor at heise online Poland. At the same time I was coding libraries in Ruby and one thing was drawing my attention: lazy enumerators. During works on I18n library with pattern interpolation in Ruby I had chosen to use lazily executed methods which could be stacked with the dot operator, giving nice processing pipelines. Around that time I was reading about Clojure and it hit me how much easier would this be in this language, with function composition and sequences, not mentioning the Delays or Futures. I think Clojure was the first language I decided to learn before conding anything serious. It took me like 2 years to really give it a try, and leave Ruby world, so in 2013 I was making notes explaining how the basics work, and in 2014 started writing a tutorial in Polish called "Poczytaj mi Clojure" (which could be freely translated as "README Clojure" (README meaning both "Clojure, read to me" and "read me [some] Clojure". Through all 2015, during my sabatical, while sitting in a cafeteria almost every day, I coverd built-in special forms, functions, type systems, collections, sequences, macros and more, publishing it online. In 2016 I started sharing first programs on Github. So I probably need about 2 more years to become advanced, according to "Teach Yourself Programming in Ten Years" – https://www.norvig.com/21-days.html https://www.norvig.com/21-days.html I remember trying Hydrox for documentation and so called literate programming approach, playing with function arguments and building macros changing positional args into named ones, using core.async and multimethods to build network bots, learning macros and protocols. I've made some free software libraries through the years, and I think I finally am able to build more complex systems. Since I occasionally have a tendency to go into details too much, or to (re-)write things from scratch, I found Clojure to be the first language giving me enough power to finish those things in less than couple of weeks (1-2 months tops), and go back to a main project to continue. In other lanugages I tried for years I was kind of sinking into sub-projects (which needed to be taken care of) and hadn't enough energy to go back and resume works on more generic, systemic level.

299 points by fogus 4y ago

While I like Clojure as a language - I have never seen a language that engendered such hatred in PMs, EMs, sales, etc. I don't know that it survives long term (in industry, it'll survive for a long time as a hobby language.)

pelasaco 4y ago
I like Clojure, but unfortunately for web development, there isn't a great stack and for data science/ML/AI (which is a great fit for clojure), python dominates the market. What is the niche for Clojure, or why should keep using it in 2023? P.S: I like it a lot, but either I do golang or ror for web dev, or python/pytorch for data sciences/AI stuff, C# for game development. I don't think i can get more productive with Clojure in any scenario, that I'm exposed too, what I'm missing?
- ARandomerDude 4y ago
  It is actually a great choice for unopinionated server-side web development. Frontend development is simply awesome in ClojureScript. Give me Reagent + Shadow CLJS over plain React (or React Native) any day.
  - moonchrome 4y ago
    >Frontend development is simply awesome in ClojureScript Is that still tied to that google closure abomination ? I've not been in CLJ ecosystem for >5 years now but last time I used CLJS I remember they went all in on google Closure and it was a major PITA to use the rest of JS ecosystem because of it. Every time I use React I think how it would be great to use Clojure for that, but last time I tried the tooling overhead just killed it for me.
    - lgessler 4y ago
      > Is that still tied to that google closure abomination ? I've not been in CLJ ecosystem for >5 years now but last time I used CLJS I remember they went all in on google Closure and it was a major PITA to use the rest of JS ecosystem because of it. This has been solved now--there's a blessed CLJS solution[1][2] as well as a third-party compiler with NPM support[3] which many prefer. [1]: https://clojurescript.org/news/2017-07-12-clojurescript-is-not-an-island-integrating-node-modules https://clojurescript.org/news/2017-07-12-clojurescript-is-n... [2]: https://cljs.github.io/api/compiler-options/npm-deps https://cljs.github.io/api/compiler-options/npm-deps [3]: https://shadow-cljs.github.io/docs/UsersGuide.html#npm https://shadow-cljs.github.io/docs/UsersGuide.html#npm
    - simongray 4y ago
      Shadow-cljs makes everything very easy these days.
  - ndr 4y ago
    For you and anyone else with experience, is that the most common/battle-tested cljs stack? What about servers-side, any equivalent Django or FastAPI?
    - dgb23 4y ago
      If you want a complete, integrated "stack" that stitches some of the most common libraries together in a uniform structure you might have a look at kit: https://kit-clj.github.io/ https://kit-clj.github.io/
      - cutler 4y ago
        If you're coming to Kit from Luminus make sure you understand Kit's use of Integrant which involves passing `query-fn` down from the route to every function which accesses SQL. It was a deal-breaker for me.
    - dack 4y ago
      The cljs stack I hear about a lot (and use) is ShadowCLJS with reagent (https://reagent-project.github.io/ https://reagent-project.github.io/) and re-frame (https://day8.github.io/re-frame/ https://day8.github.io/re-frame/). ShadowCLJS is more of a build tool, but is really well documented and easy to use. Reagent is basically react but a simpler API, and re-frame is a layer on top of that kinda like redux. It's overkill for some apps but I find it's actually super easy to work with and not as much complexity as I thought. For backend there is luminus (https://luminusweb.com/ https://luminusweb.com/) or Kit (https://kit-clj.github.io/ https://kit-clj.github.io/). They are basically project templates that wire together a ton of popular solutions for various things - database access, migrations, security, html templating, etc. Also includes frontend frameworks like re-frame if you want. edit: forgot to mention fulcro (https://fulcro.fulcrologic.com/ https://fulcro.fulcrologic.com/) which is an interesting full stack solution. I haven't used it though so can't comment, but it sure seems documented well!
      - ndr 4y ago
        Thank you. What about leiningen vs boot vs deps.edn? Did any of this come ahead as a winner in the recent years? It's been a while since I've looked into this.
  - pelasaco 4y ago
    Yes, ClojureScript is definitely on my learning list, we however decided to avoid one more transpilation tool, and accepted the fact that we have to write typescript. > Give me Reagent + Shadow CLJS over plain React (or React Native) any day. So that is for heavy js based applications, not for something light like rails + stimulus.js, right?
- lgessler 4y ago
  > I like Clojure, but unfortunately for web development, there isn't a great stack What do you feel is missing? Certainly there are options (something as frameworky as Fulcro, something as barebones as a React wrapper like Reagent), so there must be some itch you can't scratch?
  - pelasaco 4y ago
    wow, first time seeing Fulcro, and it has a great documentation https://book.fulcrologic.com/ https://book.fulcrologic.com/, definitely will play with that, thanks!
    - lgessler 4y ago
      Yeah, it's too heavy for some things, but it's situationally very awesome. Fulcro takes the fantasy of "reusable components" very seriously, more seriously than any other frontend framework I'm aware of, and designs from the ground up to allow for that. Be sure to go to #fulcro in the Clojurians slack with any questions/comments--it's a very friendly community in there.
- Heliosmaster 4y ago
  Check Clerk (https://clerk.vision/ https://clerk.vision/) for the boundaries between data science / data viz / moldable programming
dgb23 4y ago
Clojure is not a hobby language.
taeric 4y ago
I'm intrigued, why do the PMs and such care? (I'm assuming EMs is Engineering Manager?)
- gemstones 4y ago
  Clojure is really good at self-selecting for people that really care about innovation in programming languages. The other jobs in a tech company care about innovation in their domain. They rarely align. So for every weird, cool innovation you see, the productivity is immediately lost because people equally care about how you deal with state on app startup, or routing, or database interaction. And since none of those other things move the needle much in how you compete in your business domain, competitors who are not concerned wind up eclipsing you. While you're arguing integrant vs. mount, people are just running dotnet new and bikeshedding over things closer to the business domain. PMs/EMs/QAs/etc. may not have technical knowledge, but they smell something off about programmers arguing about what library to use for routing. Why didn't people complain about this at their past jobs? Surely if it was important, it would have come up. They just perceive you as having hired a bunch of senior people who are incredibly slow relative to their past companies. It really breeds resentment. I have seen clojure-first companies creatively hive off parts of their engineering org to have a separate org that is allowed to use a different stack. They're not super transparent about it to avoid a big exodus of people, but I've personally seen it happen more than once.
  - dgb23 4y ago
    > Clojure is really good at self-selecting for people that really care about innovation in programming languages. The other jobs in a tech company care about innovation in their domain. They rarely align. To me it seems people typically like Clojure because of its simplicity, stability and productivity with the REPL. There are innovations in Clojure (its data structures, transducers...) but overall it is a pretty conservative and minimal language with laser focus on pragmatism. Also in terms of slowness it seems the opposite is the case from my limited knowledge. OS authors and contributors seem to be extremely productive and creative. There are some notable Clojure shops (see: OP) that have been growing at an incredible pace. Maybe I see this differently because I come from a [insert two very popular languages] background where everything breaks every couple of months and the culture is severely fad driven. To me Clojure is refreshing, calming and more powerful on top.
eduction 4y ago
This is a reasonable comment, even as a Clojure fan, I think this fits with how the community thinks of itself to some extent. I can't provide a specific citation but I know there is at least one talk (maybe Simple Made Easy but don't quote me lol) where Rich Hickey talks about the fact that one reason "easy" tools -- which in his view provide fast uptake but more problems down the line due to being "complected" in how they deal with various concerns of the underlying problem -- are so popular is that people who manage programmers (like some of the positions you mentioned) want to be able to easily put butts in chairs, to readily replace engineers like they are cogs in a machine, so they are very willing to make this trade of short term ease for long term pain because less training is required to get to a near term deliverable. It's also clear (see Hickey talk Effective Programs, 10 Years of Clojure, where he surveys the room) that Clojure programmers tend to be senior (real senior not 5 years experience "senior") and a little grumpy about the state of the art, opinionated, and don't want to be cogs. This may also explain the allergic reaction among people who manage programmers/engineers. Managers as a rule (especially at certain orgs) tend to want people who are more compliant and less free thinking and likely to push back. Anyway I think you make a good point except I disagree about its survival long term. I think there's something to be said about the value of being more popular among older more seasoned programmers vs PMs. How many PMs in the 90s foresaw the rise of Linux (vs proprietary unix and Windows), how many go overboard on "agile", how many were into ruby on rails before it picked up among programmers, etc. Managers tend to be a lagging indicator (speaking very broadly).
- munificent 4y ago
  My impression is that Clojure (and Lisps in general) are about maximizing the productivity of an individual where other languages try to maximize the productivity of an entire team. There are trade-offs to be made in either direction and much of what affects the feel of languages on either side of that comes from the choices they make around those trade-offs.
sanderjd 4y ago
Why would PMs and sales people have any opinion whatsoever on this kind of detail?

BaculumMeumEst 4y ago

I love Clojure the language but I’ve never seen a more fragmented ecosystem. There seems to be a pattern in the language of “a problem emerges > a community solution gains traction > Cognitect develops their own solution but its weird and undocumented”, like deps.edn over leiningen, spec over malli, pedestal over ring, etc. Many prominent clojurists recommend deps.edn over leiningen and socket repl over nrepl, but I’ve seen very little guidance on how either actually work or how to use them. Spec seems kind of weird and not well thought out either. And Clojure CLI tools also seem like a total shitshow compared to go or rust’s tooling. As a result working with Clojure feels puzzling and unpleasant, and I feel hesitant to use any community library or project in the language.

dgb23 4y ago
> deps.edn Deps is well documented. The issue I personally found is that I needed to look at a bunch of OS project's deps.edn to see how people commonly structure things. Other than that it is a simple tool. > socket repl over nrepl I personally use Calva (VSCode) which just starts an nrepl based on deps.edn. When writing babashka scripts I start the repl manually and connect to it. Very pleasant experience so far. > Spec seems kind of weird and not well thought out either. I didn't like it at first, but once I got that everything is bottom up I had an AHA moment. Function specs and instrumentation are very powerful. Conform is basically a parser, which can give you a lot of leverage. What bothers me about spec is that it is still not released though.
- billfruit 4y ago
  Deps may be well documented, but lots of introductory material seems to use lein. Having two systems is more confusing.
  - seancorfield 4y ago
    Because a decade ago there was only Leiningen -- so all the books and tutorials (and videos) created in the early days of Clojure had to use it. At work, we started with lein (back in 2011 for our production code), then we switched completely to Boot in 2015, and then we switched completely to deps.edn in 2018. build.clj (tools.build) is a "recent" addition (less than two years since the very first 0.0.1 commit). More and more introductory material is appearing these days featuring deps.edn but given there was a decade of Leiningen usage out there before deps.edn even appeared, the current state of affairs shouldn't surprise anyone. As for more than one system, lots of languages have that situation: consider make -> ant -> maven -> gradle etc.

revskill 4y ago

I tried Clojure, but when i look for a good ORM, what i see is a paid library.

snorremd 4y ago
In Clojure ORMs aren't really that popular considering most Clojurists just use the built in datatypes (e.g. maps) to represent data. There are no classes as such (unless you use Java interop). If you need a query builder the honeysql library is really nice.
- rawoke083600 4y ago
  Lol yup ! "It's Maps All The Way Down"
- danuker 4y ago
  > just use the built in datatypes (e.g. maps) Well, then, MRM: Map-Relational-Mapper.
  - Zak 4y ago
    There's https://www.hugsql.org/ https://www.hugsql.org/ for example. It takes maps for inserts and updates, and returns maps for selects. Other database access libraries over the years have typically shared that characteristic. If you want to convert between maps that map directly to tables and some other structure, manipulating maps in Clojure is easy.
- camdez 4y ago
  Expanding on this a bit, Clojure, as a language, is fundamentally against the idea of ORMs in its design. Objects / classes are not so much the problem, per se—it's specifically that ORMs fundamentally involve scattering uncoordinated mutable state throughout the application. A foundational thesis of Clojure is that mutation is a tremendous source of bugs, and should be avoided / thoughtfully limited. Once you let the unmanaged mutation genie out of the bottle, it's almost impossible to put back in. More concretely, I used to work extensively with Rails; I loved ActiveRecord (ORM) when I first started out—it makes basic things so easy. Later I worked on a large Rails app supporting millions of users...we used ActiveRecord extensively, and had a very talented team. ActiveRecord worked fine most of the time, but I have bad memories of spending hours or even days tracking down user-reported bugs. I'd try to figure out how to recreate the user's state locally, even cloning pieces of the production database to work with their exact DB data, but whatever state the program had gotten into was a large graph of (all!) mutable objects. How was that flag getting set? What code could have done it? When? And the answer is basically ANYTHING at ANY TIME that could possibly get a reference to the object. And web applications are far from the worst offenders in this space because the request / response cycle is (usually) fairly globally stateless. Clojure is the exact opposite of that experience. The state of a Clojure program will most likely comprised of data literals (think JSON data types, if you don't have experience with Clojure / Lisp data). Printable data literals. Connect to the errant server, serialize the state, read it from your machine, and you're there. It's coherent, stable, serializable, transmittable, simple. Who can mutate your data? No one. You have an immutable reference (maybe others do too, but reading is a fundamentally safe operation). How does it change? Only along the explicit path of computations you're working through (it doesn't change, actually, you choose to hold onto a new reference to derived data when you want to). Or, if you really need a mutable escape hatch (like, say, you're holding a handle to a database), every type of mutation in (core) Clojure has defined (and thoughtfully so) concurrency semantics. You won't see a bunch of notes in Clojure API docs that say things like "not thread safe" like you see in JavaDocs. TLDR: Clojure will happily give you object-like read-only views into your database (like Datomic's `datomic.api/entity`), or help you write queries with a knowledge of your database schema, but most Clojure persistence solutions will explicitly coordinate mutation into a single 'site' because that's the only way maintain a coherent view of state-over-time. And that single-mutation-site story is the opposite of what ORMs (as commonly defined) do.

rawoke083600 4y ago

I've started learning Clojure about a year ago, couldn't say it was easy (the fault might be with me and not Clojure) Clojure has a lot a faults (just look at some of the comments here) BUT and it's a BIG BUT for me... Clojure is SUPER FUN :) Over the years(15+), I've been coding in PHP (suck it haters), Go, Rust,Java,Python AngularJS+, Svelte and I can honestly say for me, nothing is more fun that coding in Clojure. It's fun testing a function in "realtime" by just "eval" it on the spot. I don't even code "in the REPL" I just use Calva and eval inline in VSCode Maybe it's cause it's my new toy but it really does bring back the "joy of coding" I've been missing in the other languages. *Learning Clojure became much more easier, once I told myself "It's Maps All The Way Down :D" Sure there are stuff like atoms that make it possible to code around the "immutability" but that is like using a cheat-code to go back to the old ways. Yes there are many times when mutable-data-structures are required, but while learning, don't grab for them as a first solution ! Anywhoo YMMV but once you get over the warts (many there are), much fun and insights awaits :)

kelseyfrog 4y ago
Clojure user here since 2010(my earliest Clojure project on Github), and while I agree with the fun point, the iceberg wart for me at this point is the inelegance of the interface hierarchy and its structure behind the scenes. Clojure's forward-facing interface (a hundred functions that operate on one data structure) ended up breaking down for me at some point and became 10 functions on 10 data structures and those data structures became AFn, APersistentSet, APersistentMap, APersistentVector, IFn, IPersistentSet, IPersistentMap, IPersistentVector, ITransientMap, ITransientVector, IndexedSeq, LazySeq, &c, &c, &c. Maybe I started writing code wrong. Maybe I dived too deep into the internals, Maybe it was something else. But at the end, there wasn't one data structure, there were dozens and dozens each with justifiable differences, but even so, that's not what was advertised. It took a decade to reach that point and perhaps the vast majority of folks never will. The sad part is that I know none of it is up for change without creating a Clojure2, and that highlights the problem. Why should changing the internals need to break backwards compatibility? There is one unspeakable reason: the illusion wasn't complete and they weren't really internals to begin with.
- 4y ago

Per_Bothner 4y ago

To toot my own horn: The oldest still-active compiler-based language on the Java platform, besides Java, is as far as I know Kawa (https://gnu.org/software/kawa https://gnu.org/software/kawa). It started Summer 1996, and is still actively maintained. (Not as active as it used to be, to be true.) Like Clojure, it is a Scheme-like language, but (unlike Clojure) it is very compatible with "regular" Scheme (R7RS), though of couurse with lots of extensions. With a little bit of care (including optional type-specifiers), it is easy to write code that is as fast as Java code.

BaculumMeumEst 4y ago
Oh cool! That language is so fun to use, thank you for writing and maintaining it!

mrichman 4y ago

I tried getting into Clojure (I have an undergrad Lisp background). I just couldn't become productive, and the tooling seems fragmented. Been moving many of my workloads from Go to Rust.

distantaidenn 4y ago

I love Clojure (and have touted such in past comments), but it suffers from a glaring problem: every library is half done and/or abandoned. What happens is you end up modifying an existing library to fit your particular problem space. I needed a web framework. None of them just did things in a "simple way". I ended up branching an existing one and have altered it (very heavily) to fit what I need. It's now my go-to for all new projects. The issue with us Lispers is that we love the language more than we do the tooling. Tooling be damned! So we all end up re-inventing the wheel for the 1000th time. We will never gain wide spread adoption, as such. With Ruby, I have Rails. With Python: Django. With Clojure...well good luck. Every framework does one thing beautifully correct and about 10 things wrong. But hey, it's up to you to modify the framework! Because that's the Lisp way of doing things! Maybe I should publish my bespoke framework one of these days...

danuker 4y ago
Every early ecosystem suffers from lack of mature libraries. It is a chicken and egg problem. I think your contribution would be very welcome, especially with a bit of docs or minimal examples.
- sanderjd 4y ago
  I don't think it's an "early ecosystem" though... I was playing with Clojure before I had ever heard of Go, Elixir, Julia, Rust, or Typescript. All of these seem like mature ecosystems now. I really like Clojure as a language, but if it's still an "early ecosystem" at this point, that seems like a problem to me.
  - yenda 4y ago
    True, although I don't know which library the op is talking about, because all the libraries I use are alive and well, some get very rare updated simply because they are "done"
- miroljub 4y ago
  You can't call it "early ecosystem" after 15 years.

eduction 4y ago

I have been using Clojure for a solo project for a while now and find it shockingly productive. I initially planned to limit how much of the language "surface area" I explored to keep focused on solving the problem but was able to productively use much more of Clojure than I expected: -core.async for concurrency that led me speed up some tasks from ~1000ms to ~40ms (well, core.async got me to about 100ms, or closer to 5x speedup on other tasks, and then other optimizations got me the rest of the way). Also using refs for some very limited data sharing across go threads (apparently actually using refs and dosync, aka mvcc data structures, is rare). -spec for parsing a dsl and validating input -macros for a select few syntax and core async optimizations (avoiding unnecessary go block usage) -multimethods for extensibility -a fair amount of Java interop to use best in class libraries -transients to help optimize performance in some places -even transducers a few places (maybe 1 percent of my code if that, but still) -edn for dsl files I sense that where people have more friction is trying to work with other people, in teams and organizations. In the right organization this can clearly work, dedicated Clojure shops, but there can be resistance in other organizations, and it has to be "smuggled in", and people worry about the ability to hire (especially for orgs that tend not to train heavily - nubank clearly trains a lot of programmers on Clojure but many shops don't want to do this level of training). And then people will avoid using certain advanced features like macros or even some functional conventions (recursion, reduce and map etc instead of vanilla loops) because they worry it will make it harder to onboard people without Lisp or FP experience. I honestly think this is Clojure's big challenge, entrenched expectations and conventions in the industry and a desire to pull programmers off the shelf. In this talk (the one we're all commenting on) Rich and others point at the productivity and fun of REPL driven development -- finding some way to really grow that and somehow take it to the next level -- as a possible solution, to offer yet another carrot to encourage people to make the leap to Clojure. It sounds like a good idea but I have no idea what that looks like exactly. I honestly think the answer to getting more Clojure penetration may be the passage of time, as happened with python. I know nubank/cognitect has been funding some open source work with small grants on top of Alex and Rich's work (and Stuart's?). This kind of basic grunt work can pay off long term. But it's not a sexy answer and if it doesn't work you're at a dead end.

avindroth 4y ago

agumonkey 4y ago

Can't say I'm not happy to hear Rich Hickey talk again.

olah_1 4y ago

Rich Hickey’s talks may outlive Clojure itself. In some sense, the principles he taught and aimed for were the ideal. Clojure today wasn’t necessarily the ideal. I think there could be room for a better Clojure than Clojure, so to speak

danuker 4y ago
Based on my analysis of Rosetta Code samples, Clojure is the most popular language with its compactness. https://danuker.go.ro/programming-languages.html#non-math-map https://danuker.go.ro/programming-languages.html#non-math-ma... Also, it has a low frequency of bugfix commits (which may or may not be related to bugs also). (but it might be the dev experience, I have not adjusted for it). https://danuker.go.ro/frequency-of-bugfix-commits.html https://danuker.go.ro/frequency-of-bugfix-commits.html In addition, the JVM gives it great performance, and it has actual CPU multithreading (while Python or other scripting languages have a GIL). This makes it relevant in today's environment where Moore's law continues through number of cores. Therefore I don't think Clojure will die too soon.

logistark 4y ago

I have the feeling that after Nubank bought Cognitech, Clojure has gone to stagnation. I mean, i feel that promoting and improving Clojure is no longer a priority. And another think that stinks me everytime Cognitech talks about Clojure they have to bring to the table Datomic. They tried to push Datomic on my company long time ago when they do some consultancy job at my company. You can skip all the talk, because is all about how good Clojure is and that is. No any eta about future features, improvements and fix problems of current Clojure users. Lot of open source contributors have leave the community, because there is any plan on Clojure. I guess that Rick Hickey is happy with Clojure as it is now, and this is the way is going to stay. And still no Java 8 support for CompletableFuture, lambdas interface, Stream api, java.time, no pattern matching, java records, this group feels like a group of old programmers stuck at Java 6 that cannot move forward.

Zak 4y ago
It seems to me that these things are a big deal if you're doing a lot of JVM interop and not so much if you're primarily using Clojure-native libraries. Clojure has futures, lambdas, streams, a community-maintained java.time library, core.match, and Clojure records. I'm sure there would be benefits to adopting the newer JVM-native equivalents, but I'm not as sure they're worth the costs.
kamaal 4y ago
I thought you might be trolling. But then when I looked at the Clojure repo on Github https://github.com/clojure/clojure https://github.com/clojure/clojure the last commit was 2 months back. There is some merit in your arguments.
- seancorfield 4y ago
  Clojure evolves slowly and deliberately -- it gets about one release a year (with various prereleases) so "2 months" between commits isn't a big deal. I consider it a "feature" because it means Clojure is extremely stable -- which is great for us at work given that we've used it in production for a dozen years at this point and have been able to run alpha builds in production safely during nearly all of that time.

cfiggers 4y ago

I see some comments in here with the sentiment, "Clojure—What am I missing?" Here's an attempt to answer that question. I am just a hobbyist and enthusiast programmer with no formal background in programming or CS, and no real experience using Clojure (or any other language, for that matter) "in anger" in a serious production environment. These are just some nobody's two cents, take or leave them for whatever they're worth to you. From what I understand, there are some applications and domains that the JVM is highly optimized for—especially long-lived, highly concurrent server processes or stream processing applications where microseconds matter in order to keep up with real-time. The fly in the ointment (for some) is that Java itself is Object-oriented, compiled, statically typed, and uses mutable objects and data structures by default. Not everybody loves those design choices. And even of those who do, not everybody finds Java ergonomic (hence Scala and Kotlin, among others). So, much like Scala and Kotlin do, vanilla Clojure just gives access to the JVM (and its highly mature library ecosystem) in different trappings. It's a functional (rather than object-oriented), REPL-driven (rather than compiler-first), dynamically-typed, and immutable data-oriented language, with Lisp's minimal syntax and structural editing experience. Plus, the designers have invested a lot of time and their cumulative decades of programming experience into making a really solid standard library that comes with a lot of smart affordances out of the box. That combo really works for some people. Then, folks who appreciated the conveniences and good design in vanilla Clojure started looking for that dev experience in non-JVM contexts, which is how you get ClojureScript, ClojureDart, ClojErl, Babashka, Scittle, etc. And then, other Clojure-inspired languages pop up that don't purely adhere to Clojure conventions, but co-opt significant portions of its well-designed syntax and standard library—languages like Janet (compiles to C) and Fennel (compiles to LUA) and Hy (compiles to Python). And then, script kiddies like me come along and discover, Hey Wow, I can learn one syntax and suddenly be +80% dangerous in a dozen different environments, without having to start learning a new language from scratch in each one—from the JVM to the browser to mobile apps to native executables, I've got SOMETHING to start building on because I already know how to think in Clojure. At this point, "Clojure" is not just "a language," it's a category of languages—just like Scheme is "a Lisp," Janet is "a Clojure." I don't think that happens with uninteresting, poorly-designed, or irrelevant languages. Clojure scratches a specific itch, and not everybody has that itch to scratch. But whether Clojure is your cup of tea or not (and obviously for many people in this comment section, it's not), I don't think anyone can debate that it's a significant project that justifies its own existence. That doesn't obligate anybody to use it or even look at it twice, but I think it self-refutes a lot of the negativity that gets thrown its way.

jawadch93 4y ago

[dead]

rcarmo 4y ago

Nice to see, but I'm still sad Clojure is a hosted JVM language. I find it unwieldy for a lot of things where Go, Python and Chicken Scheme shine, and wish someone got ClojureScript to run natively in things like Bun or Deno so I could have one fast, small runtime.

orestis 4y ago
Check out Babashka!
- rcarmo 4y ago
  It’s nice, but hardly what I need.

beders 4y ago

Lisp has ruined me forever. I'm not sure how I can go back to other languages. I basically started out with Allegro Common Lisp on Sparc's, went to Java because it was the shiny new thing, and then in 2017 finally took the plunge and have been addicted to Clojure ever since. Don't get me wrong: the learning curve can be steep, but the steepness - at least in my case - came from un-learning all the object-oriented stuff. Once you understand the value of values and the simplicity it brings, it becomes such a joy to code in Clojure. For the people on here disgusted by the JVM ecosystem: There are many alternatives for Clojure. There's Clojure for .NET, ClojureScript in at least two flavors that compile down to JavaScript, there's a fast interpreter called babashka for scripting, there's Clojerl for the Erlang VM, there's jank - which adds gradual typing on a C++ runtime. Oh, and there's jobs that pay really well ;)

runevault 4y ago
How is Clojure for dotNet? I haven't touched Clojure in general for years (honestly I think it's been at least a decade) but I remember a lot of libraries making calls expecting the Java standard library so seems like things would have broken, but maybe it is gotten a lot better in recent years.
- puredanger 4y ago
  It's been kept up to parity but a complete rewrite is currently under way - watch https://dmiller.github.io/clojure-clr-next/ https://dmiller.github.io/clojure-clr-next/
  - nocman 4y ago
    I thought about doing some work on Clojure itself, but, alas, my last name isn't Miller. :-( jk
    - KingMob 4y ago
      The Clojure development process is notoriously closed to outsiders. Even in the early years, some people contributed time and code, and weren’t thanked. I would view attempts to contribute as very high risk for newcomers. I personally maintained a fork for a couple years just for an unmerged patch I needed, rather than try to get the core team to merge it.

Naomarik 4y ago

I was writing a longer comment and deleted everything after it started to look like bragging. All I'll say is that I'm extremely grateful to Clojure for the life I've been able to live and what it's allowed me to accomplish. This is truly a language for beating the averages.

elwell 4y ago

I didn't realize how nice I had it with Clojure until I went full-time Java.

hota_mazi 4y ago
Java is almost 30 years old. How does it compare in your mind with, say, Rust and Kotlin?
- elwell 4y ago
  > Java is almost 30 years old. Java has changed substantially over that time period though
- roguas 4y ago
  does kotlin offer anything more than less-boilerplate-than-java?

college_physics 4y ago

Clojure fans seem quite taken to hyperbole. If the language is such a "joy", "ultra-productive" etc I would have expected after such a long period of existence some major open source project to be showing off what the language attributes allow you to do. Happy to stand corrected if there is such a slam-dunk showcase that I've missed, I am actually interested to dig into clojure, if nothing else as a way to deepen my understanding of functional programming.

maxfurman 4y ago
There is something about the language and/or community that leads folks to build their own X instead of collaborating on a common open-source version of X. Perhaps the lisp learning curve is high enough to dissuade those who want to contribute to a project but don't yet know Clojure?
- ilkhan4 4y ago
  I have a pet theory that it's because it's too easy to write code in. I think there needs to be just enough pain with a language or library that it becomes worthwhile to allow someone else to write X and just deal with it being imperfect if it still solves your problem.
  - ballpark 4y ago
    too easy and too fun. Also, to anyone interested in this problem, look for the Worse is Better paper
doubleg 4y ago
To name a few: https://github.com/xtdb/xtdb https://github.com/xtdb/xtdb, https://github.com/nextjournal/clerk https://github.com/nextjournal/clerk, https://github.com/penpot/penpot https://github.com/penpot/penpot, https://github.com/metabase/metabase https://github.com/metabase/metabase
- heyzk 4y ago

brundolf 4y ago

One of the things that stands out to me in this video is seeing devs who are much older than the average dev I encounter, who have continued to grow deeper in their skills and form deeper insights, sharing some of those insights. It's something I don't get to see very often and it's encouraging

simongray 4y ago
That's what originally attracted me to Clojure back in 2017 when I was ~30.

vaylian 4y ago

Clojure is the language that made me understand why Lisp matters: We can express ideas and instructions in a programming language with just a very basic set of tools. And we can use these tools to craft powerful and elegant abstractions. In addition, Clojure emphasizes immutable data structures, which, after some learning effort, made me write code that is much easier to reason about.

orestis 4y ago

Obligatory shout out to Babashka [0] which is interpreted Clojure. You just download a simple binary and you can get going. Widely used for quick-running scripts, with a lot of batteries included. [0]: https://babashka.org/ https://babashka.org/

garbagecoder 4y ago

For just the right thing, I've loved using Clojure and wish I could use it some more, but I rarely find that just right thing.

munro 4y ago

I could be reading the energy wrong, but damn it looks corporate bullshit sucked the life out of Rich

cutler 4y ago
He certainly looks and sounds older. Rich seemed to ride the wave of Clojure's early success with a succession of brilliant presentations. Then .... nothing.
- simongray 4y ago
  He's speaking again this year at Clojure Conj, so maybe there will soon be something again.

Barrin92 4y ago

a little bit of an offtopic question, but given that the video has a sign language interpreter, is there a specific vocabulary for programming given how many unique terms there are, and is it harer to understand for people who rely on it than normal conversation?

deleted 4y ago

[deleted]

ivanb 4y ago

The ultimate failing of Clojure as a tool is its inefficiency measured in $ per feature. The language is not very approachable for junior programmers. You can grab a Python programmer and graft them on a Java or TS project and the same week they will deliver features and bugfixes. Reading other's people code in Clojure is much harder especially when coming from imperative world. The language is terse. The documentation is terse and lacks examples. Library documentation is insufficient or non-existent. You have to read other people's code. It is a really demanding activity aggravated by lack of static typing. You cannot just hover over a map in your IDE and see its structure. The value may have come through several transformations that add, transform and remove fields. To understand what arguments a function expects you have to decipher destructuring bindings which in real code can be ingenious, i.e. unreadable. And hold on to your butts when a clever teammate invents a flow of control macro and uses it throughout. These and other reasons make the pool of candidates small, candidates "over-qualified" and expensive. If your expert quits, your whole endeavor is screwed. I helped to rewrite a Clojure project that stalled due to lack of affordable talent. It's been chugging along since then at a considerable pace. The new language is very popular and much less affected by the mentioned problems. There is a mention of Penpot in this thread. Mark my words, when it comes a time to scale, they will rewrite the whole thing in a popular statically typed language.

mnming 4y ago
I do agree. While I made all my projects in mostly Clojure, I absolutely cannot imagine hiring & onboarding other drvs. And if I had a tough day, my clj code will look like rubbish, while my typescript code will still look decent. It's really not a language for big team.
- simongray 4y ago
  I have onboarded developers coming directly from university and it went fine? In fact, at my old job, the entire team learned Clojure on the job. I was the only hire who had learned it prior to being hired. Our codebase was fine and very maintainable. The other teams were similarly new to Clojure. Most people spent a few months doing increasingly more advanced things until they were comfortable with the language and the codebase. The main issue for complete beginners is learning to grapple with the different development setup compared to what they might be used to, i.e. interactive development on a live system using an editor-integrated REPL. We basically set everyone up with IntelliJ and parinfer. Paredit was optional, as was alternative editors such as emacs. IntelliJ + parinfer is a similar development experience to Python. The only part that is foreign in that case is the interactive development of a live system which the new devs quickly come around to seeing the benefits of. It helps having seniors who point out the new concepts.

ZionLloyd 4y ago

[dead]

cospaia 4y ago

Clojure changed my life. It made me realize how fun it is to code and switch back to being a programmer. This makes me a much happier person and thus a better husband and father. Never looking back. The Clojure Way just fits me perfectly.

silver-arrow 4y ago

Excellent and very productive language. Personally, I did 15 years of straight Java (before that C and C++), then 5 years of Clojure. For me, the most telling dynamic is when I recently returned to a Java project and realized how much better Clojure is - even for large projects ;) The lack of static typing, which is so often used as an argument against Clojure, is actually what makes Clojure better. The Java projects become a morass of types scattered into a myriad of packages; no matter how experienced you are with Java. Clojure's dynamic underpinnings and its paradigm of hundreds of functions for a few data structures allows for very lean designs that are easier to wrap your head around and keep in your mental models. The other features are just gravy: immutability built in, REPL interactivity, Transducers, Protocols etc. I felt the pain going back to a Java project.

siefca 4y ago

I remember writing about first official releases of Clojure around 2010 when I was an editor at heise online Poland. At the same time I was coding libraries in Ruby and one thing was drawing my attention: lazy enumerators. During works on I18n library with pattern interpolation in Ruby I had chosen to use lazily executed methods which could be stacked with the dot operator, giving nice processing pipelines. Around that time I was reading about Clojure and it hit me how much easier would this be in this language, with function composition and sequences, not mentioning the Delays or Futures. I think Clojure was the first language I decided to learn before conding anything serious. It took me like 2 years to really give it a try, and leave Ruby world, so in 2013 I was making notes explaining how the basics work, and in 2014 started writing a tutorial in Polish called "Poczytaj mi Clojure" (which could be freely translated as "README Clojure" (README meaning both "Clojure, read to me" and "read me [some] Clojure". Through all 2015, during my sabatical, while sitting in a cafeteria almost every day, I coverd built-in special forms, functions, type systems, collections, sequences, macros and more, publishing it online. In 2016 I started sharing first programs on Github. So I probably need about 2 more years to become advanced, according to "Teach Yourself Programming in Ten Years" – https://www.norvig.com/21-days.html https://www.norvig.com/21-days.html I remember trying Hydrox for documentation and so called literate programming approach, playing with function arguments and building macros changing positional args into named ones, using core.async and multimethods to build network bots, learning macros and protocols. I've made some free software libraries through the years, and I think I finally am able to build more complex systems. Since I occasionally have a tendency to go into details too much, or to (re-)write things from scratch, I found Clojure to be the first language giving me enough power to finish those things in less than couple of weeks (1-2 months tops), and go back to a main project to continue. In other lanugages I tried for years I was kind of sinking into sub-projects (which needed to be taken care of) and hadn't enough energy to go back and resume works on more generic, systemic level.