5 ms·
I’m seeing a lot about clojure language, especially recently. I’m missing an insight into the clojure community, especially in the context of libraries and job
by thih9 3y ago
I’m seeing a lot about clojure language, especially recently. I’m missing an insight into the clojure community, especially in the context of libraries and job market.
E.g. I’m not aware of any large framework like Rails or Phoenix. Is this something that is missing and yet-to-come, or there is no need for that?
How does this affect job search, are Clojure jobs less about SAAS/CRUD apps? Does each place build their own custom tooling?
- jwr 3y agoThere is no dominant over-arching framework like in some other languages. There are many smaller ones, with different approaches, so there is more choice. As for SaaS apps, Clojure is a really good fit, because of ClojureScript. You can have a large part of your code as .cljc files, and compile both to JVM and to JavaScript in the browser. I found this is an incredible advantage, enabling a single founder like me to write and maintain a complex SaaS.
- zerr 3y agoSo like Blazor for C#?
- kaba0 3y agoIt runs as quite lean JS on the frontend. If I’m not mistaken, Blazor targets WASM with huge binaries that may prevent its use in certain cases.
- pjmlp 3y agoNot really specially after .NET 8, Blazor will be unifying all ASP.NET programming models, whereas in Clojure it is more simple. Also ClojureScript doesn't do WebAssembly.
- capableweb 3y ago> Also ClojureScript doesn't do WebAssembly. It's a bit ambiguous what you mean with "do", but you can definitely use WebAssembly modules in ClojureScript just like you can in JavaScript. I'm not familiar with Blazor or C# so maybe I'm missing something obvious here.
- pjmlp 3y agoThe obvious part is compiling Clojure source code into WebAssembly bytecodes.
- capableweb 3y agoAh, yeah, that's probably a bit far off in the future. Probably would be possible via GraalVM once GC is available, https://github.com/oracle/graal/issues/3391 https://github.com/oracle/graal/issues/3391
- dustingetz 3y agoplease state the value prop of doing that?
- pjmlp 3y agoThat wasn't the question, rather comparing ClojureScript vs Blazor from OP.
- jwr 3y agoI don't know Blazor, and it's difficult to tell from the webpage. But I can tell you that most of my model (business logic) code is written in Clojure and compiles to both JVM and ClojureScript. In other words, I use the same code on the server and on the client. I also use EDN (meaning Clojure) as the serialization format between them, so I avoid serializing to something non-native. All this buys a lot of incremental improvement. ClojureScript gets compiled using Google Closure compiler in "advanced" compilation mode — for those who might not know, this is not a "minifier", it's a whole-program transformer which does renaming and dead code elimination. The result is highly optimized JavaScript. I guess that's why there isn't much excitement about WebAssembly in Clojure circles — the current state of affairs is really good enough. In my experience (complex SaaS app), DOM operations are a performance bottleneck, not ClojureScript.
- __pache__ 3y agoIt sucks so no one uses it :)
- shrimp_emoji 3y agoI think Clojure had a moment 2015 to 2020ish, but it's passed. People still use it, even though it sucks. What's not to love: - Incredibly slow - Hosted on the JVM, so you're going to be dealing with Java eventually - No automatic tail call optimization because of the limitations of the JVM, so it feels like you're writing a mess of macros rather than real functional code
- ballpark 3y agoIt's definitely not over. I got into it professionally in 2018, and have remained employed with it at three different companies. There's turmoil around it because startups use it with great success, but then as they want to scale they have a hard time finding enough devs to throw at their new ideas.
- rads 3y ago> - Incredibly slow Huh? Clojure is one of the fastest dynamic languages. It's not intended to replace C++ or Rust. > - Hosted on the JVM, so you're going to be dealing with Java eventually In the real world this is a blessing since there are a lot of useful Java libraries out there. > - No automatic tail call optimization because of the limitations of the JVM, so it feels like you're writing a mess of macros rather than real functional code How did you come to this conclusion? Lack of automatic TCO doesn't mean you have to write macros, and most people in the Clojure community will tell you to prefer functions over macros unless it's absolutely necessary.
- jgrodziski 3y ago> - Incredibly slow Almost as fast as Java, and for performance critic processes 99.9% of the time we bump on infrastructure performance problem BEFORE hitting the wall with Clojure (see https://clojure-goes-fast.com/blog/ https://clojure-goes-fast.com/blog/ for tips and tooling about performance) > - Hosted on the JVM, so you're going to be dealing with Java eventually For me it's a major selling point: JVM is battle tested and a wonder of engineering. The Java ecosystem richness is incredible (see tooling above for monitoring and profiling for an example). And the platform is constantly moving forward (see latest JDK with virtual threads, generational ZGC, etc.). And of course GraalVM... (https://www.graalvm.org https://www.graalvm.org) > - No automatic tail call optimization because of the limitations of the JVM, so it feels like you're writing a mess of macros rather than real functional code Never have been a problem and I don't see the point with macros, and code we write looks _very_ functional...
- koito17 3y agoClojure users tend to prefer tiny libraries that excel at one task and compose them together. While Pedestal is definitely a framework, its eclipsed by the sheer popularity of Ring (HTTP abstraction library similar to Rack), where you roll with your own choice of web server, router, middleware, database, data validation and coercion, etc.
- thih9 3y agoGot it. So there’s no missing library, just more flexibility and the community embraces that. Thanks for explaining!
- mtreis86 3y agoRight. Instead of 4 frameworks competing, yet having mostly similar say 25 underlying functions, clojure has say 50 functions (assuming half the framework code overlaps between frameworks) as libraries that can be composed to achieve the same functionality as those frameworks, and more.
- capableweb 3y agoYeah, Clojure basically takes one of the ideas from Alan J. Perlis' "Epigrams in programming" to the next level. > 9. It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures. http://www.cs.yale.edu/homes/perlis-alan/quotes.html http://www.cs.yale.edu/homes/perlis-alan/quotes.html
- stefcoetzee 3y agoWhere generally the proverbial "one data structure" is a hash map. "Just use a map" [0] [0] https://www.youtube.com/watch?v=aSEQfqNYNAc https://www.youtube.com/watch?v=aSEQfqNYNAc
- cutler 3y agohttps://kit-clj.github.io https://kit-clj.github.io https://fulcro.fulcrologic.com https://fulcro.fulcrologic.com
- FPGAhacker 3y agoI haven’t really worked in closure for a while, but luminus was my go to web framework in the past. https://luminusweb.com/ https://luminusweb.com/
- divs1210 3y agoLuminus has a successor called Kit.
- epgui 3y agoI worked with Clojure professionally, and one of the things it forced me to unlearn was reliance on frameworks and lots of little libraries for everything. It's just not necessary when your language is so expressive and simple. I know nobody believes me when I say this, but I really mean it.
- jgrodziski 3y agoThe Clojure's approach is to favour libraries over frameworks. We use Clojure on various style of applications (mainly web and API based), hosted on widespread infrastructure technologies of Cloud Providers (Kubernetes, PostgreSQL, Kafka, etc.) and it's a breeze: here are our reasons for choosing Clojure https://defsquare.com/blog/why-we-bet-on-clojure https://defsquare.com/blog/why-we-bet-on-clojure If you want to look at libraries where some people have settled, here are our _opinionated_ takes on libraries that we use on almost every project: - HTTP: Ring is the de facto way to manage HTTP request (see https://github.com/ring-clojure/ring/wiki/Concepts https://github.com/ring-clojure/ring/wiki/Concepts) supplemented with various "Middlewares" for web-related concerns (security, logging, content encoding, etc. see https://github.com/ring-clojure/ring/wiki/Standard-middleware https://github.com/ring-clojure/ring/wiki/Standard-middlewar...). Jetty and Aleph are common web servers (and https://github.com/clj-commons/aleph https://github.com/clj-commons/aleph) that implement Ring interface. - Routing: Reitit (https://github.com/metosin/reitit https://github.com/metosin/reitit) - Single-Page App: shadow-cljs for the build concerns (https://github.com/thheller/shadow-cljs https://github.com/thheller/shadow-cljs), Reagent with Re-frame for complex/large app (https://reagent-project.github.io https://reagent-project.github.io and https://github.com/day8/re-frame https://github.com/day8/re-frame). Even if we now prefer using HTMX (https://htmx.org https://htmx.org) and server-side rendering (Hiccup way of manipulating HTML is just amazing, https://github.com/weavejester/hiccup https://github.com/weavejester/hiccup). - Schema management: Malli (https://github.com/metosin/malli https://github.com/metosin/malli) - Lifecycle management: Mount, Integrant or Component (https://github.com/tolitius/mount https://github.com/tolitius/mount https://github.com/weavejester/integrant https://github.com/weavejester/integrant and https://github.com/stuartsierra/component https://github.com/stuartsierra/component) - Config management: Aero (https://github.com/juxt/aero https://github.com/juxt/aero) and environ (https://github.com/weavejester/environ https://github.com/weavejester/environ) - Log: μ/log (https://github.com/BrunoBonacci/mulog https://github.com/BrunoBonacci/mulog) - Time: https://github.com/juxt/tick https://github.com/juxt/tick - Testing: https://clojure.github.io/clojure/clojure.test-api.html https://clojure.github.io/clojure/clojure.test-api.html and Kaocha for the runner (https://github.com/lambdaisland/kaocha https://github.com/lambdaisland/kaocha). - Package and project management: tools.deps is simple and powerful (https://clojure.org/guides/deps_and_cli https://clojure.org/guides/deps_and_cli) For infrastructure stuff (PostgreSQL, Keycloak, Solr, Kafka, etc.), just wrapping the underlying Java library or driver is often enough, and there are lots of wrappers for easing the integration. And we implement Hexagonal architecture style to put all of that in place. Don't be afraid a libraries not moving a lot recently, it's a sign that the library is mature and battle-tested. Clojure is a joy to use every day :)