4 ms·

Clojure is a quirky language, and I really enjoyed writing a proof-of-concept microservice with it back in 2015-era when everyone was shouting "Scala is the way

Clojure is a quirky language, and I really enjoyed writing a proof-of-concept microservice with it back in 2015-era when everyone was shouting "Scala is the way!" I was able to prototype with it and stand it up in a weekend. With the tiniest bit of code, I had the exact service I needed. It ended up in production after only spending a couple weeks, most of which was spent wrapping my head around Docker and Mesos that we used to run the .jar. However, it's a quirky language. So, my quick take, as a glue layer on top of the JVM, it was quite powerful, but jank has me scratching my head. LISP doesn't really read well the bigger the codebase, and as something to write software in standalone environment, it makes me a bit hesitant. I sometimes would hit walls, because in real world software, you need persistent state. Functional software, for obvious reasons, fights against that, and so modeling state is actually quite difficult. This is where I think, as a small layer on top, it's fast and effective. I would just not want to write more than a few files with it though. Happy to follow along this project though and see where it goes.

kccqzy 2y ago
Clojure offers so many ways for you to manage state for different use cases. Atoms, volatiles, agents, vars, refs. Functional programming never fights against persistent state. It simply carves out the functionality by use cases and offer you more choice in managing it.
Jeaye 2y ago
Often times, when people learn Clojure, they are also learning functional programming and lisp and data-oriented programming and interactive programming all at once. Writing Clojure requires a shift in perspective, coming from the imperative and object-oriented paradigms, and without that shift, even basic programs can seem impossible to build. This shift was very difficult for me, coming from C/C++/C#/Rust, and I've spoken with many others who've felt the same. I suspect, when you talk about hitting walls due to state, it's due to that perspective shift not being complete. Does that mean I'm saying Clojure is the best lang for everyone and it's their fault if they don't get it yet? No, certainly not. We need to do better with that, in the Clojure world, to make that bridge easier to cross. But, having fought my way across that bridge, I can confidently say that mutable state is no problem in Clojure. We have first-class support for it and that support is thread-safe by default. Unlike something like Haskell, effects aren't scary and don't need to be wrapped. They can be adhoc. jank inherits all of this and just brings it to the native world. That means lighter binaries, faster startup, and easier interop with native libs. Aside from that, it's Clojure.
diggan 2y ago
> I sometimes would hit walls, because in real world software, you need persistent state. Functional software, for obvious reasons, fights against that, and so modeling state is actually quite difficult. I haven't felt this, Clojure has good primitives for dealing with state, both temporary and more permanent. The biggest difference from (most) mainstream languages is that it's very explicit what has state and where you're mutating it. But personally I feel like that makes it easier to manage complicated state relationships, rather than harder, since it's typically isolated in smaller parts.
EuAndreh 2y ago
LISP doesn't really read well the bigger the codebase [citation needed]

kccqzy 2y ago

Clojure offers so many ways for you to manage state for different use cases. Atoms, volatiles, agents, vars, refs. Functional programming never fights against persistent state. It simply carves out the functionality by use cases and offer you more choice in managing it.

Jeaye 2y ago

Often times, when people learn Clojure, they are also learning functional programming and lisp and data-oriented programming and interactive programming all at once. Writing Clojure requires a shift in perspective, coming from the imperative and object-oriented paradigms, and without that shift, even basic programs can seem impossible to build. This shift was very difficult for me, coming from C/C++/C#/Rust, and I've spoken with many others who've felt the same. I suspect, when you talk about hitting walls due to state, it's due to that perspective shift not being complete. Does that mean I'm saying Clojure is the best lang for everyone and it's their fault if they don't get it yet? No, certainly not. We need to do better with that, in the Clojure world, to make that bridge easier to cross. But, having fought my way across that bridge, I can confidently say that mutable state is no problem in Clojure. We have first-class support for it and that support is thread-safe by default. Unlike something like Haskell, effects aren't scary and don't need to be wrapped. They can be adhoc. jank inherits all of this and just brings it to the native world. That means lighter binaries, faster startup, and easier interop with native libs. Aside from that, it's Clojure.

diggan 2y ago

> I sometimes would hit walls, because in real world software, you need persistent state. Functional software, for obvious reasons, fights against that, and so modeling state is actually quite difficult. I haven't felt this, Clojure has good primitives for dealing with state, both temporary and more permanent. The biggest difference from (most) mainstream languages is that it's very explicit what has state and where you're mutating it. But personally I feel like that makes it easier to manage complicated state relationships, rather than harder, since it's typically isolated in smaller parts.

EuAndreh 2y ago

LISP doesn't really read well the bigger the codebase [citation needed]