81–90 of 204 posts
I wonder if the author is familiar with Smalltalk - it has a very small syntax. In some ways so does Lisp, in other ways it has more than every other language, depending on what you think about operators versus functions.
> The seq abstraction, for example, means I usually don’t have to worry about what kind of sequence I’m dealing with Eh? That's completely lifted from CL ( https://www.lispworks.com/documentation/HyperSpec/Body/t_seq... ). Same for AREF/NTH, there's ELT. Other than that, I agree, CL is baroque yet needs some hole filling here and there. > Lisp: everything is a list But that's wrong. Not even a little. Unless you mean…
I haven’t used clojure in quite a while but what’s the issue with (let [a b] …)? Is (let (a b) …) even valid clojure?
It takes some getting used to, and I do wish Clojure would do something more like (let [[var1 val] [var2 val]] ... .. though of course then you'd have to figure something else out for destructuring.
> I do wish there were an easier way to move in the ]}]})))}-ness of block ends though. I’m not quite sure what this means. How is it different/worse than all parens..? fyi I use paredit and just hit ) and it moves me past any kind of paren/bracket. But even without that you can just hit left and right..?
It’s easier if everything is parens, just hit paren til the errors are gone.
Once you learn Clojure's syntax and semantics, you're no longer bound to the JVM. There's ClojureScript (JS), ClojureCLR, ClojureDart, jank (C++), Basilisp (Python), babashka (SCI), and many others. This means that, if you don't know Java or don't like the JVM, you can likely use Clojure wherever you already feel most comfortable. For the most part, any Clojure code which doesn't use host interop will work on all dia…
Earlier quoted context omitted.
What can the Erlang / Golang runtimes do that the JVM can’t?
Thousands of share-nothing actors (fibers / green-threads) with first-class support for communication between them, for a start. Erlang/Elixir -- immutability as well.
Earlier quoted context omitted.
Are JVM virtual threads not on par with golangs's concurrency? I think core.async even uses virtual threads now
If they are, I have not heard about it (which does not mean much, I check Java once a year). And if they really are then I'd give Java a serious look again because it's a mature ecosystem that was gimped by ancient runtime decisions for literal decades.
Earlier quoted context omitted.
Thousands of share-nothing actors (fibers / green-threads) with first-class support for communication between them, for a start. Erlang/Elixir -- immutability as well.
What kind of software actually requires this? Honest question. Anything I can think of would probably be written by C++ devs