5 ms·

Has anyone used Clojure much? I love Rich's talks so I've been very interested in it but there are so many great languages to learn these days.

jetti 6y ago
I have been using it for almost a year now as I use it at work. I like it a lot and am glad I made the switch (I spent the previous 8 years doing C# work). We use both Clojure and ClojureScript
bcrosby95 6y ago
I've used it quite a bit for side projects, but never professionally. I definitely think it's a great general purpose language. However, I don't use it as much anymore because I feel like my primary coding tasks (webapps) are better served by Elixir. As a language I vastly prefer Clojure. But it's hard for me to pass on BEAM and the concurrency model therein.
jonahbenton 6y ago
Yes, and yes there are, and many are worth the brain bending to get them absorbed, and the brain bending is different for each. Speaking personally, having worked at one level or another with, looks like, 48 of the top 50 TIOBE languages over 30+ years (lacking OpenEdge ABL and ABAP) and about a third of the next 50 (where Clojure resides), Clojure is near the top of the list for me in terms of brain-bending value.
_bxg1 6y ago
I did one personal project in it just to get my feet wet. Unfortunately the tooling was not great at the time so it soured my impression a bit (I'm told it's gotten better since then). But also, I just have a really hard time giving up static types these days. Even for small projects, I always feel anxious about code that doesn't have annotations on function boundaries. It may have more to do with personal sensibilities than actual need, but regardless, it makes things unpleasant for me.
- hannofcart 6y ago
  Same here: having gone from C++ to JS+Python and back to Golang/Rust, I just can't imagine life without types. However, of all the not-static-typed language ecosystems I see, Clojurists seem to miss types the least. I have dabbled with the language and I know about `spec` but I don't quite seem to grasp why even shops using Clojure without spec don't seem to miss types much either. Perhaps people more experienced with Clojure can shed light on this?
  - _bxg1 6y ago
    A pure functional style does help somewhat; things are more predictable and consistent, expressions can be evaluated inline to test them out, etc. And I think Clojure teams (Lisp teams in general, really) are already forced to be on the small side because of how flexible things can become with macros and such. You have to have a stronger shared headspace compared to, say, a Java project. So that also lends itself to being more dynamic-types-tolerant. Finally, that very flexibility (with macros, etc.) is only fully possible in the absence of static types. So there is a genuine tradeoff. Still, even with all of the above I'd rather have them than not have them.
  - slifin 6y ago
    If you want something to let you know you've made a silly mistake like putting a string in a number function or missed an argument use clj-kondo it will catch those problems for you in the editor If you want to make a Person class or type I would recommend instead making your information model as a Datomic schema and have all your functions use associative destructuring with defaults values for missing data with function comments for good measure For dev I would recommend Datahike over Datomic initially
  - lorddoig 6y ago
    It depends what you want to use types for, really. If your motivation for using types is provable correctness and you can grok Haskell (or better yet, Idris), then you should do that. If you want performant dispatch, Clojure can give you JVM-level perf through the use of protocols. If, however, you want input validation (in the sense that you can be sure that a function argument you've been given will allow you to do what you intend with it) then static typing isn't the only player in that game. In my experience (which I think resonates with RH and most Clojurists) is that for the vast majority of _information-driven_ systems, types are used as the latter. If you have a `Customer` class that gives you guarantees about the availability of, say, an `accountNumber` field, that is useful for correctness as you can be sure the information you need is there. However, if some future downstream coder wants to use your customer in the more general sense of being a human, then (s)he has to worry about sub/super/abstract-classing, may have to make upstream modifications to expose previously hidden data, and similar faffage. In Clojure the idiomatic solution to this problem is to "just use a map"; the real-world downside to this, however, is extremely weak contracts between functions. In this example, what `spec` allows you to do is strengthen those contracts by verifying that the data your function is provided is sufficient for your uses (as in the map contains all the keys you'll need with suitable data types in the fields) _without_ constraining what downstream consumers can also do with this data (extra map keys are ignored). These checks are only done at runtime and only when enabled, however writing a spec gives you (very-nearly-almost) free generative testing that will run your function a default of 1000 times with random data in the correct shape to make sure it doesn't blow up—this isn't a guarantee of correctness, but it does provide extremely high levels of confidence (most type systems are also not even close to guaranteeing correctness either, only compliance with the type system). Spec also gives you (for free) performant runtime coercion for use in actual real-world code. You get a lot of bang for your buck. `spec` is definitely not a type system, but it very capably fulfils a similar role in the kinds of programs Clojure was intended to be good at. It gives you all the flexibility and dynamism of Clojure with most of the confidence of static typing, without constraining either.
devin 6y ago
Professionally for something like 7 years now. It’s good stuff.
tbatchelli 6y ago
I have been using it professionally since the first Conj and I still do. We have a ton of Clojure code where I work. I still love it.
JBiserkov 6y ago
https://clojure.org/community/companies https://clojure.org/community/companies
jtth 6y ago
As a language it is a work of wonder and it focused and refines thinking about programming. Learning it will make you a better programmer in whatever language or paradigm you more commonly use. As a tool for building things it varies. I only know about the web, and on the web it's probably best as a secondary language to do heavy lifting as a service rather that the backbone of a SaaS, where Django or Rails will get you where you want to be faster. Trying to do fairly common web stuff in Clojure is a lot more work and happens at a much lower level of abstraction, even if you use curated selections of libraries like Luminus. The focus on libraries over frameworks is enticing for some engineers who want to spend a long time building reliable and totalized systems, but for quickly building out features it leaves a lot to be desired. The ecosystem also assumes you are going to make an SPA in ClojureScript. (That said, Fulcro is fascinating if you are committed to the SPA way of doing things; the way it manages data flow seems unique, at least to me.)
- gradys 6y ago
  IMO, the ClojureScript SPA ecosystem is a stronger competitor in its domain than Clojure on the backend. Re-frame in particular is a gem. It's as though someone tried the React/Redux stack, thought long and hard about actions and selectors, and realized that with one or two more pieces, everything falls into a beautiful, purely functional harmony.
  - peferron 6y ago
    I have the exact opposite opinion! Clojure on the backend is awesome because you can use mature, stable, pure Clojure libraries for almost everything and it works together beautifully. ClojureScript on the other hand suffers from constantly having to interop with JS libs and tools, or trying to wrap them, with many wrappers being outdated or having a bus factor of 1. I feel like the advantages of CLJS have eroded over the past few years: - TypeScript has fully taken over, generalizing the advantages of static typing - JS libraries have adopted functional patterns, narrowing the comparative advantage of CLJS - Tools like create-react-app have emerged to simplify project configuration, while CLJS is still figuring things out: https://clojurescript.org/news/2020-04-24-bundle-target https://clojurescript.org/news/2020-04-24-bundle-target
rhlsthrm 6y ago
I've been really wanting to learn another language (been doing TS for the past couple years, would really like to see what else is out there). What do you think are other great languages to learn instead? I'd want something ideally with: functional paradigms (really want to learn these), good tooling, good ecosystem, good production deployment recipes, shared code between front end and back end. Any thoughts?

jetti 6y ago

I have been using it for almost a year now as I use it at work. I like it a lot and am glad I made the switch (I spent the previous 8 years doing C# work). We use both Clojure and ClojureScript

bcrosby95 6y ago

I've used it quite a bit for side projects, but never professionally. I definitely think it's a great general purpose language. However, I don't use it as much anymore because I feel like my primary coding tasks (webapps) are better served by Elixir. As a language I vastly prefer Clojure. But it's hard for me to pass on BEAM and the concurrency model therein.

jonahbenton 6y ago

Yes, and yes there are, and many are worth the brain bending to get them absorbed, and the brain bending is different for each. Speaking personally, having worked at one level or another with, looks like, 48 of the top 50 TIOBE languages over 30+ years (lacking OpenEdge ABL and ABAP) and about a third of the next 50 (where Clojure resides), Clojure is near the top of the list for me in terms of brain-bending value.

_bxg1 6y ago

I did one personal project in it just to get my feet wet. Unfortunately the tooling was not great at the time so it soured my impression a bit (I'm told it's gotten better since then). But also, I just have a really hard time giving up static types these days. Even for small projects, I always feel anxious about code that doesn't have annotations on function boundaries. It may have more to do with personal sensibilities than actual need, but regardless, it makes things unpleasant for me.

hannofcart 6y ago
Same here: having gone from C++ to JS+Python and back to Golang/Rust, I just can't imagine life without types. However, of all the not-static-typed language ecosystems I see, Clojurists seem to miss types the least. I have dabbled with the language and I know about `spec` but I don't quite seem to grasp why even shops using Clojure without spec don't seem to miss types much either. Perhaps people more experienced with Clojure can shed light on this?
- _bxg1 6y ago
  A pure functional style does help somewhat; things are more predictable and consistent, expressions can be evaluated inline to test them out, etc. And I think Clojure teams (Lisp teams in general, really) are already forced to be on the small side because of how flexible things can become with macros and such. You have to have a stronger shared headspace compared to, say, a Java project. So that also lends itself to being more dynamic-types-tolerant. Finally, that very flexibility (with macros, etc.) is only fully possible in the absence of static types. So there is a genuine tradeoff. Still, even with all of the above I'd rather have them than not have them.
- slifin 6y ago
  If you want something to let you know you've made a silly mistake like putting a string in a number function or missed an argument use clj-kondo it will catch those problems for you in the editor If you want to make a Person class or type I would recommend instead making your information model as a Datomic schema and have all your functions use associative destructuring with defaults values for missing data with function comments for good measure For dev I would recommend Datahike over Datomic initially
- lorddoig 6y ago
  It depends what you want to use types for, really. If your motivation for using types is provable correctness and you can grok Haskell (or better yet, Idris), then you should do that. If you want performant dispatch, Clojure can give you JVM-level perf through the use of protocols. If, however, you want input validation (in the sense that you can be sure that a function argument you've been given will allow you to do what you intend with it) then static typing isn't the only player in that game. In my experience (which I think resonates with RH and most Clojurists) is that for the vast majority of _information-driven_ systems, types are used as the latter. If you have a `Customer` class that gives you guarantees about the availability of, say, an `accountNumber` field, that is useful for correctness as you can be sure the information you need is there. However, if some future downstream coder wants to use your customer in the more general sense of being a human, then (s)he has to worry about sub/super/abstract-classing, may have to make upstream modifications to expose previously hidden data, and similar faffage. In Clojure the idiomatic solution to this problem is to "just use a map"; the real-world downside to this, however, is extremely weak contracts between functions. In this example, what `spec` allows you to do is strengthen those contracts by verifying that the data your function is provided is sufficient for your uses (as in the map contains all the keys you'll need with suitable data types in the fields) _without_ constraining what downstream consumers can also do with this data (extra map keys are ignored). These checks are only done at runtime and only when enabled, however writing a spec gives you (very-nearly-almost) free generative testing that will run your function a default of 1000 times with random data in the correct shape to make sure it doesn't blow up—this isn't a guarantee of correctness, but it does provide extremely high levels of confidence (most type systems are also not even close to guaranteeing correctness either, only compliance with the type system). Spec also gives you (for free) performant runtime coercion for use in actual real-world code. You get a lot of bang for your buck. `spec` is definitely not a type system, but it very capably fulfils a similar role in the kinds of programs Clojure was intended to be good at. It gives you all the flexibility and dynamism of Clojure with most of the confidence of static typing, without constraining either.

devin 6y ago

Professionally for something like 7 years now. It’s good stuff.

tbatchelli 6y ago

I have been using it professionally since the first Conj and I still do. We have a ton of Clojure code where I work. I still love it.

JBiserkov 6y ago

https://clojure.org/community/companies https://clojure.org/community/companies

jtth 6y ago

As a language it is a work of wonder and it focused and refines thinking about programming. Learning it will make you a better programmer in whatever language or paradigm you more commonly use. As a tool for building things it varies. I only know about the web, and on the web it's probably best as a secondary language to do heavy lifting as a service rather that the backbone of a SaaS, where Django or Rails will get you where you want to be faster. Trying to do fairly common web stuff in Clojure is a lot more work and happens at a much lower level of abstraction, even if you use curated selections of libraries like Luminus. The focus on libraries over frameworks is enticing for some engineers who want to spend a long time building reliable and totalized systems, but for quickly building out features it leaves a lot to be desired. The ecosystem also assumes you are going to make an SPA in ClojureScript. (That said, Fulcro is fascinating if you are committed to the SPA way of doing things; the way it manages data flow seems unique, at least to me.)

gradys 6y ago
IMO, the ClojureScript SPA ecosystem is a stronger competitor in its domain than Clojure on the backend. Re-frame in particular is a gem. It's as though someone tried the React/Redux stack, thought long and hard about actions and selectors, and realized that with one or two more pieces, everything falls into a beautiful, purely functional harmony.
- peferron 6y ago
  I have the exact opposite opinion! Clojure on the backend is awesome because you can use mature, stable, pure Clojure libraries for almost everything and it works together beautifully. ClojureScript on the other hand suffers from constantly having to interop with JS libs and tools, or trying to wrap them, with many wrappers being outdated or having a bus factor of 1. I feel like the advantages of CLJS have eroded over the past few years: - TypeScript has fully taken over, generalizing the advantages of static typing - JS libraries have adopted functional patterns, narrowing the comparative advantage of CLJS - Tools like create-react-app have emerged to simplify project configuration, while CLJS is still figuring things out: https://clojurescript.org/news/2020-04-24-bundle-target https://clojurescript.org/news/2020-04-24-bundle-target

rhlsthrm 6y ago

I've been really wanting to learn another language (been doing TS for the past couple years, would really like to see what else is out there). What do you think are other great languages to learn instead? I'd want something ideally with: functional paradigms (really want to learn these), good tooling, good ecosystem, good production deployment recipes, shared code between front end and back end. Any thoughts?