Comment by CraigJPerry | Hacker News Reader

Comment by CraigJPerry | Hacker News Reader

Clojure is a recurring gravitational pull for me. I haven't had time to properly explore yet but I will before end of year.

It's not a "first" language like JS, Python, Java, C#, Ruby etc. so the community appears to benefit from a higher than average level of skill. In the same way that i imagine Erlang or Elixir might enjoy the benefit of more capable than average users.

The fact that entire paradigms can be implemented as libraries is attractive to me - it suggests to me that the Python 3000 or C++11 problems are unlikely to affect Clojure.

For example, Go is a language I find interesting. The whole CSP concept makes a ton of sense to me in writing enterprise software - mainly from a "keeping the architecture cheap to own and change over time" point of view. I appreciate this isn't where CSP was targeted but it lends itself very well IMO to solving this problem because you could decouple components and grow them independently so effectively.

Go is an entire language but core.async is just a library in Clojure, they didn't have to change the language to implement this which is mind blowing to me.

Another example is types. Only some of the code I write actually benefits from types AND most type systems in "enterprise" languages are pretty anaemic. Typing is also really hard to do well, like really really hard. You had a problem, you adopted typing and now you have two problems is generally my thinking here.

Scala was to be my saviour here but that missed the mark quite spectacularly and the compiler is still ridiculously slow today but then along came TypeScript which is pretty darned awesome IMO.

Thanks to TypeScript and modern Python i had learned that i wanted "optional typing" and i was undecided about type erasure at runtime - i don't immediately see a problem with it, i've written probably thousands of lines of Java with generics then used reflection at runtime without losing sleep, but it fills an awkward space in my head - to invest in types but only benefit at compile time seems like a miss.

In Clojure i can follow the TypeScript model but actually take it further to runtime.

This post is too long already. Long way to say Clojure appears very interesting.

The clojure community has robust tooling around types and similar mechanisms. There is core.typed, but I honestly don’t know of many who use it in production.

More recently, clojure.spec was released (https://clojure.org/about/spec) which I see the community starting to coalesce around. It’s a nicely-designed way for doing validation and property verification at runtime, and imo avoids the “awkward space” problem you mentioned. By creating specs, you get validation, nice errors, and generative testing (almost) for free. Because Clojure development is often repl-driven anyway, there’s not a huge benefit in having compile-time types, at least if you subscribe to the philosophy behind clojure.spec.

I like Clojure quite a lot---for a while, it was actually my main language.

Ultimately, however, I largely gave it up because the library ecosystem just doesn't feel quite right to me---at least at the time I was writing a lot in it (2016-7ish), most of the popular libraries seemed to have a very strong refugee-from-Java sense to them, as in, very influenced by ideas more commonly seen in oo-land. For example, people loved to use (and, more importantly, bundle in other projects) libraries like component/mount that attempt to implement ideas like dependency injection and other design pattern/architectural concepts that just... don't really feel lispy. I remember trying to build a fairly simple web application with one of the main frameworks and just having no clue which piece of the hyper-complicated and indirect code that the lein template built for me I'd need to change to debug some problems with the database. Alas.

(To be clear, I'm not saying this is wrong! It just wasn't for me.)

I’ve been playing a lot with the idea of just using ClojureScript for everything, both backend and frontend.

Shadow-cljs [0] makes interop with the NPM ecosystem a breeze, and ClojureScript is stable, mature, and feature-complete in its own right.

Although you lose out on some of the features of the JVM (threading), you get access to a lighter weight runtime, and the massive world of JavaScript libraries (which don’t bring much OOP baggage with them).

I’m not sure how viable it is long term, but so far it’s been fun, and pretty trivial to write simple wrappers over JS libraries (when repeated direct interop doesn’t make sense).

Somebody else in here mentioned that Clojure isn’t a “first” language, but I think if there was an “easier” (yes, I said easier, not simpler) path to get into it, more people might pick it up as their second language.

[0] https://github.com/thheller/shadow-cljs

I can only say glowing things about Clojure. If you have any interest at all, I strongly, strongly encourage you to try it out. braveclojure.org is a decent start, and it’s also fun to try out the problems at 4clojure.org.

I bought “Clojure Applied” and so far i’ve completed the first chapter on records and types.

The first chapter ticked a lot of boxes for me - i get a strong impression that the “Clojure way” is pragmatism over ideology. I like that.

> Clojure is a recurring gravitational pull for me.

You're in love

After working with it for a couple years now, I still really appreciate it.

I'm discovering the language these days and I really like it.

>You had a problem, you adopted typing and now you have two problems is generally my thinking here.

When you are working with types, it's like you are working out a complex puzzle. Each time you've solved a part of the system you've created more puzzle pieces in other parts. Solving this meta-puzzle feels nice and productive, especially once you get the hang of it. But it's not really solving the original problem, it's just managing the accidental complexity.

Sometimes it feels hyper productive - when you’re working out the practical details of how to model your problem, typing feels like you have a smart assistant helping you think, or at least organise your thoughts more clearly.

When you’re changing some code that’s been around for a while, or writing adapter type code, or any kind of SERDES type operations, it begins to feel less like helpful guard rails and more like unproductive yak shaving. After the initial creation, most of my code changes fall in the latter camp.

I definitely think having a comfortable way to say “here, in this code, i want types. Over here, i don’t care” is a control missing in many languages. You can certainly fake it (e.g. string typing or everything is object type) but not comfortably like for example in TypeScript.

Reply on news.ycombinator.com