7 ms·

I do wonder what has to happen for greater adoption of Clojure.

joshlemer 5y ago
If you have ideas on how to improve Clojure adoption, there's a #growth channel on the Clojurian slack server.
jdminhbg 5y ago
Maybe a fuller understanding of its applicability to discussions like this one from yesterday? https://news.ycombinator.com/item?id=30753127 https://news.ycombinator.com/item?id=30753127
deleted 5y ago
[deleted]
newlisp 5y ago
Companies seeing some value in it and pushing it but that won't happen. Most companies today want static typing and don't want to rely on discipline for stuff like maintaining documentation/more tests and having them up to date. If it's true that engineers leave after one/two years then I can't blame them. Whatever cost static typing brings, it's worth it to them. Just look at how typescript usage has exploded.
mixedCase 5y ago
I would never use it under any circumstance of my choosing, since it's a dynamically typed language and I don't have any further need for any more of those at the moment; in fact only looking to cut down on my usage of them. But from my experience working with it on real projects: - Good tutorials, combined with library and build tooling integration for usage with GraalVM. Startup times make it a horrible fit for anything other than long-lived daemons. - Speaking of build systems: more ecosystem coalescing around tools.deps, there's a lot of resources around Leiningen, not too many around the blessed native tooling (I know, I know, it's fairly new for Clojure standards, but it is a problem). - More and better linters for popular libraries. Without good types, you need something to guide you when you're misusing an API; the team where I worked with Clojure lost a lot of time getting Reagent patterns wrong. My final complaint is something that I don't think can't ever be fixed without undoing what makes Clojure, Clojure: REPL-driven development combined with dynamic typing, in the same way as its cousin: debugger-driven development, often leads to write-only code that works but good luck using it or modifying it if you don't have good automated tests to tell you how it's supposed to be used and more importantly how it's not. It doesn't help that tests are de-emphasized by the community precisely because of REPL-driven development. "Just put it on the REPL and see what it does" is not a good way of reasoning about code, and makes it easy and convenient to just pile on more hacks that may or may not break something instead of promoting understanding. "Just write good code and have discipline, you're doomed if you can't do that anyway" does not excuse that other languages have radically different tools and practices that lead to far fewer footguns.
- mattmein 5y ago
  >> other languages have radically different tools and practices that lead to far fewer footguns Can you share any examples of these different tools and practices?
  - mixedCase 5y ago
    "Advanced" (read: decades old) type systems. They provide tools like algebraic data types, generics, interfaces, row polymorphism and many others, but just those four allow expressing a gargantuan amount of invariants in the type system without sacrificing flexibility. Invariants that can be proven once and be maintained throughout years of code churn without repetitive runtime checks, heavy discipline or overly repetitive automated tests that attempt to poorly reimplement a type system. They can be used not only as a way to let the compiler help you out in not making mistakes but also as an exploratory tool to test out many edge cases with quick feedback and as an informational aid to help quickly introduce new developers into a codebase with its own business domain explained in a language that allows conveying "this is possible" and "this isn't possible" much more quickly than reading tons of procedural code until the reader comprehends all the implicit rules laid down by the program's behavior.
    - iLemming 5y ago
      Well, respectfully (while not disagreeing with you), I have to say that you seem to live in some idealistic utopia of software crafting. Between the crazy world of gazillion lines of shitty Python or Javascript, and some incredible proof assistants, I think Clojure finds itself in a quite pragmatic, practical, and cozy niche. Notably, Clojure "speaks money". Money necessitates reliability and requires defect-free software. At the same time, modern, digitized money management desires flexibility and efficiency in fixing bugs and adding new features; Clojure very often fits perfectly for it. That is why it is so prevalent within fintech startups. If someone pays you to play around with advanced type systems, and you love that, what can I say? You are a lucky one. I get paid to build something that works. I'm not a zealot; I use Clojure because it makes sense (for me). But some people prefer Python and Javascript. And that's fine.
iLemming 5y ago
Nothing. It is still growing. Slowly, steadily, systematically. Clojure evolves strategically, not tactically. Besides, no matter what happens - Clojure would stay a niche language. There are certain benefits to that. Those who tie business worth and technical advantages to language popularity, often ignore them. My unit (just like many other Clojure teams) has been building numerous solutions for many years now. Our employer loves us very much. As long as we keep making money; maintain our codebase aiming for expansion rather than [quartely] renovation - investors won't care what we use to achieve the results. If other companies prefer hiring new devs and rebuilding everything every two years - well, that's their money.
phtrivier 5y ago
- ease the onboarding. Every few months I try to give clojure another shot, and every few months _some_ part of the setup has changed and / or is broken. - compile to small binaries that run fast. I get what the langage gets from the JVM, but those 5,10 seconds I get before _anything_ runs, even after I had everything compiled ? - show me an example of how having 'spec' is going to help me refactor the code that I got wrong the first time, as easily as what a proto-ML-like static type checker does. It's not a question of "types are bad vs types are good thing". It's a question of "this property was called 'name', but now I need it to be 'names', and I really need to know every possible place of my code base that uses it so that I can recursively change all code paths to handle the fact that it's a list, now." I read the spec doc a dozen times, and I don't think it does help in this simplest of simple case. Also, I make typos all the time, and caml / typescript / rust catch them before I waste a run cycle. Dynamic langages can't know if 'names' and 'name' coexist - Let me tell the compiler what I mean once. - promote an "obvious" gui lib. It's not obvious what I need to use to do an hello world window (but that's really not specific to clojure, in all fairness...)
- phtrivier 5y ago
  Also, about the 'name' -> 'names' thing ; I get that maybe the idea should be that I should keep the 'name' property around and just accrete the 'names' thing, and API should be immutable and all, but, just, 'No'.
  - deleted 5y ago
    [deleted]
- nanomonkey 5y ago
  GraalVM has made creating Clojure binaries with quick launch times much more possible. I suggest checking out babashka (Closure bash scripting) as an example and as a means.
  - amelius 5y ago
    Does that also work on embedded platforms with limited resources?
armitron 5y ago
It needs to run natively and not on the JVM. Performance is bad compared to Rust and even Go. Erlang is better when it comes to parallelism.
- keeeeeeeem 5y ago
  Seems like a weird nitpick, given that Clojure is a parasitic language by design. In addition to the JVM it also runs on GraalVM, Node, BEAM and .NET.
  - armitron 5y ago
    "Runs", on paper. BEAM and .NET are more of the same and not at all practical and GraalVM not what I mean by native. Also, clojurescript is not clojure.
wildermuthn 5y ago
One thing: Rich Hickey has to reject the ecosystem-killing mindset that he summed up in his essay, “Open Source is not about you.”

If you have ideas on how to improve Clojure adoption, there's a #growth channel on the Clojurian slack server.

Maybe a fuller understanding of its applicability to discussions like this one from yesterday? https://news.ycombinator.com/item?id=30753127 https://news.ycombinator.com/item?id=30753127

deleted 5y ago

[deleted]

newlisp 5y ago

Companies seeing some value in it and pushing it but that won't happen. Most companies today want static typing and don't want to rely on discipline for stuff like maintaining documentation/more tests and having them up to date. If it's true that engineers leave after one/two years then I can't blame them. Whatever cost static typing brings, it's worth it to them. Just look at how typescript usage has exploded.

mixedCase 5y ago

I would never use it under any circumstance of my choosing, since it's a dynamically typed language and I don't have any further need for any more of those at the moment; in fact only looking to cut down on my usage of them. But from my experience working with it on real projects: - Good tutorials, combined with library and build tooling integration for usage with GraalVM. Startup times make it a horrible fit for anything other than long-lived daemons. - Speaking of build systems: more ecosystem coalescing around tools.deps, there's a lot of resources around Leiningen, not too many around the blessed native tooling (I know, I know, it's fairly new for Clojure standards, but it is a problem). - More and better linters for popular libraries. Without good types, you need something to guide you when you're misusing an API; the team where I worked with Clojure lost a lot of time getting Reagent patterns wrong. My final complaint is something that I don't think can't ever be fixed without undoing what makes Clojure, Clojure: REPL-driven development combined with dynamic typing, in the same way as its cousin: debugger-driven development, often leads to write-only code that works but good luck using it or modifying it if you don't have good automated tests to tell you how it's supposed to be used and more importantly how it's not. It doesn't help that tests are de-emphasized by the community precisely because of REPL-driven development. "Just put it on the REPL and see what it does" is not a good way of reasoning about code, and makes it easy and convenient to just pile on more hacks that may or may not break something instead of promoting understanding. "Just write good code and have discipline, you're doomed if you can't do that anyway" does not excuse that other languages have radically different tools and practices that lead to far fewer footguns.

mattmein 5y ago
>> other languages have radically different tools and practices that lead to far fewer footguns Can you share any examples of these different tools and practices?
- mixedCase 5y ago
  "Advanced" (read: decades old) type systems. They provide tools like algebraic data types, generics, interfaces, row polymorphism and many others, but just those four allow expressing a gargantuan amount of invariants in the type system without sacrificing flexibility. Invariants that can be proven once and be maintained throughout years of code churn without repetitive runtime checks, heavy discipline or overly repetitive automated tests that attempt to poorly reimplement a type system. They can be used not only as a way to let the compiler help you out in not making mistakes but also as an exploratory tool to test out many edge cases with quick feedback and as an informational aid to help quickly introduce new developers into a codebase with its own business domain explained in a language that allows conveying "this is possible" and "this isn't possible" much more quickly than reading tons of procedural code until the reader comprehends all the implicit rules laid down by the program's behavior.
  - iLemming 5y ago
    Well, respectfully (while not disagreeing with you), I have to say that you seem to live in some idealistic utopia of software crafting. Between the crazy world of gazillion lines of shitty Python or Javascript, and some incredible proof assistants, I think Clojure finds itself in a quite pragmatic, practical, and cozy niche. Notably, Clojure "speaks money". Money necessitates reliability and requires defect-free software. At the same time, modern, digitized money management desires flexibility and efficiency in fixing bugs and adding new features; Clojure very often fits perfectly for it. That is why it is so prevalent within fintech startups. If someone pays you to play around with advanced type systems, and you love that, what can I say? You are a lucky one. I get paid to build something that works. I'm not a zealot; I use Clojure because it makes sense (for me). But some people prefer Python and Javascript. And that's fine.

iLemming 5y ago

Nothing. It is still growing. Slowly, steadily, systematically. Clojure evolves strategically, not tactically. Besides, no matter what happens - Clojure would stay a niche language. There are certain benefits to that. Those who tie business worth and technical advantages to language popularity, often ignore them. My unit (just like many other Clojure teams) has been building numerous solutions for many years now. Our employer loves us very much. As long as we keep making money; maintain our codebase aiming for expansion rather than [quartely] renovation - investors won't care what we use to achieve the results. If other companies prefer hiring new devs and rebuilding everything every two years - well, that's their money.

phtrivier 5y ago

- ease the onboarding. Every few months I try to give clojure another shot, and every few months _some_ part of the setup has changed and / or is broken. - compile to small binaries that run fast. I get what the langage gets from the JVM, but those 5,10 seconds I get before _anything_ runs, even after I had everything compiled ? - show me an example of how having 'spec' is going to help me refactor the code that I got wrong the first time, as easily as what a proto-ML-like static type checker does. It's not a question of "types are bad vs types are good thing". It's a question of "this property was called 'name', but now I need it to be 'names', and I really need to know every possible place of my code base that uses it so that I can recursively change all code paths to handle the fact that it's a list, now." I read the spec doc a dozen times, and I don't think it does help in this simplest of simple case. Also, I make typos all the time, and caml / typescript / rust catch them before I waste a run cycle. Dynamic langages can't know if 'names' and 'name' coexist - Let me tell the compiler what I mean once. - promote an "obvious" gui lib. It's not obvious what I need to use to do an hello world window (but that's really not specific to clojure, in all fairness...)

phtrivier 5y ago
Also, about the 'name' -> 'names' thing ; I get that maybe the idea should be that I should keep the 'name' property around and just accrete the 'names' thing, and API should be immutable and all, but, just, 'No'.
- deleted 5y ago
  [deleted]
nanomonkey 5y ago
GraalVM has made creating Clojure binaries with quick launch times much more possible. I suggest checking out babashka (Closure bash scripting) as an example and as a means.
- amelius 5y ago
  Does that also work on embedded platforms with limited resources?

armitron 5y ago

It needs to run natively and not on the JVM. Performance is bad compared to Rust and even Go. Erlang is better when it comes to parallelism.

keeeeeeeem 5y ago
Seems like a weird nitpick, given that Clojure is a parasitic language by design. In addition to the JVM it also runs on GraalVM, Node, BEAM and .NET.
- armitron 5y ago
  "Runs", on paper. BEAM and .NET are more of the same and not at all practical and GraalVM not what I mean by native. Also, clojurescript is not clojure.

wildermuthn 5y ago

One thing: Rich Hickey has to reject the ecosystem-killing mindset that he summed up in his essay, “Open Source is not about you.”