upvote
Thanks for feedback. Here's a pre-AI-slopped README https://github.com/nooga/let-go/blob/98c2e2ebf38519bceb4f799...

You can also refer to the HN post itself - it says why I think it's cool.

reply
This version is infinitely better.
reply
apologies if i was blunt - readme sloppage is a particular annoyance of mine that is quickly becoming common. i'm not against vibecoding, far from it. but a readme is a part of a project that humans immediately touch - seeing it littered with em-dashes signals carelessness.

i appreciate you taking my feedback with grace.

reply
I would like to point out, again, that em dashes are very much used by humans that run macOS or iOS — like in this case.
reply
No worries at all. I understand your point. I'll look into fixing this!
reply
Why did you feel the need to slopify your README? The original version read much, much better.

I genuinely don’t understand why people do this.

reply
Good question, perhaps I really was just careless. I'll look into fixing the README.
reply
It’s all good. Your project is awesome (and I say this as someone who has done Clojure fulltime for 5 years and nowadays write mostly Go).
reply
What made you stop using Clojure? Lack of Clojure jobs? Or something else?
reply
Job offer I couldn’t refuse that didn’t have Clojure.

Now I work for a fully remote team, can work anywhere in the world, at any moment I want, leading the data / cloud team for a distributed timeseries database.

Can’t complain. :)

Clojure has had a huge, fundamental impact on my way of approaching software development. I actually came from a Haskell / C++ background, but the way Clojure treats data still has a fundamental impact on how I reason about data, architecture and simplicity.

I did have some issues with how Clojure is managed and do not always subscribe to Rich’s vision (I think core.spec makes no sense, a heavily macro based global state registry is fundamentally not how I would design this, and malli is infinitely better. same for core.async vs manifold), but that is a minor detail in what was a transformative experience for me.

I believe I am not alone when I say this.

I’m still following things from a distance. Considering the current thread, I’m actually very interested in yank, which is Clojure on LLVM, and have been sponsoring that project for a few years. That would be very nice if it could enter stable state, I may take another look again.

reply
Thanks for clarifying.

> I did have some issues with how Clojure is managed

Yes there was some drama a few years back and then Rich wrote his post 'Opensource is not about you'. It was a good post.

Opensource is not easy and you might argue the reason why Clojure is so stable and backwards compatible is because of the way it's managed.

Luckily we didn't up with a scenario where Rich completely stopped. I think there was a recent case of an opensource maintainer (who works in academia) stopping PRs due to an entitled user. Can't remember the project.

But equally, is the current form of stewardship fit for purpose for the next 10 years of Clojure, i.e. to increase adoption by businesses? Don't know. Maybe something can be learned from how Linux is managed. I think Linus experienced similar bottleneck issues back then.

> I’m actually very interested in yank

I think you mean Jank: https://jank-lang.org/ ?

I'm quite excited about Clojure for GO projects.

EDIT: clarity.

reply