you might be drinking some of that AI koolaid, conflating our suddenly hypertrophied abilities to produce code regardless of our familiarity with the syntax or the APIs with ability to produce and deliver good quality products, but this delusion is getting reality check as we speak.
a realization is propagating through the industry that being able to produce more code than you're able to review, comprehend and internalize is actually not a great thing.
> You're right that those differences are sometimes marginal when the latency of whatever IO the backend's doing dominates the equation. However, in my experience huge volume surges show issues with the runtime (the thing managing/launching multiplexed request handler routines) or the ecosystem (the backend IO libraries' ability to work with the runtime's IO multiplexing and make things like request coalescing easy or automatic) more often than you'd think.
fair enough, although at this point we start talking about LB in front of the thing, consumption mechanics, autoscaling signals
i will still maintain that my simple advice for a dev worrying about scale, is that they should focus their efforts on ensuring downstream IO doesn't get overwhelmed (db read replicas, caching, etc) before optimizing runtime performance or autoscaling out unnecessarily.
> That being said, has Akka started making full use of JVM's new green threads? Has Java itself started introducing immutability and STM / share-nothing as first-class citizens? If not, then by the "programmers reach for the defaults first" rule above I'd think Java is not yet ready.
> OK Clojure has these amazing libraries, kudos. Has anybody rolled up their sleeves and said "Alright, BEAM VM's reign is over, I am making the same or better runtime as them in Java / Clojure!"?
will akka use green threads? i'm sure it will when the developers behind it deem them useful.
will jvm add immutability, stm and share-nothing primitives that (i assume you allege) are missing? sure, i guess, when it becomes frequent enough ask.
you make it seem as if the world of software development is in some constant battle for supremacy, but it just isn't.
there is no "BEAM VM's reign". and if there was - it's unlikely that anybody would care to topple it. people just want to get their job done and they use whatever tools are available, familiar and convenient for them.
> I just don't want to deal with the endless pit of determinism bugs that global mutability nets us
and a lot of people agree with you. and there's a lot of tools that address that. and i can assure you, when working with clojure, even on the blasphemous mutable jvm runtime, that class of bugs is non-existent.
> you have no clue of my stance on AI and are extrapolating a bit too much
apologies, but maybe next time try to elaborate more on sweeping statements like "syntax doesn't matter", because in current context my assumption for why you would say that is not all that outrageous.
> Syntax does not matter simply because it's an extremely leaky abstraction of the runtime below, is my point.
that would be the reason why syntax does matter, wouldn't it? nobody wants leaky abstractions!
ironically, Clojure is a great example of a hosted language that does not leak much in terms of underlying runtime, as evidenced by the fact that it has been implemented on top of a variety of runtimes with decent control over cross-runtime code reuse.
> acknowledged that the JVM is a great and mature runtime but it's lagging behind on STM / actor capabilities
you're stating this as if it's a fact, but what is your evidence? afaik jvm has a very extensive actor model library (Akka) and clojure does include a solid STM implementation (https://clojure.org/reference/refs).
the reality is that both of these approaches to concurrency are simply not popular enough, so your grievances with JVM for (allegedly!) lacking some important features relevant to them are not in sync with the demand.
> Tearing down a straw man is not impressive and it comes across as you trying to gain visibility by deliberately misrepresenting your discussion opponent's arguments.
don't debate-bro me bro, there are no straw men and no misrepresentations of your messages. if there are invalid assumptions - it's because instead of turning this into a dozen-messages-deep interrogation of what you really meant, i'm taking shortcuts and assuming what i believe is most plausible interpretation.
> `(let [a b] ...)` instead of `(let (a b) ...)` is _not_ okay
it is however quite consistent, clojure uses vector form for most macros that require a "control" form before a "data" form: argument list in defn, names list in let, iteration descriptors in for, etc. you get used to consistency quite easily.
> the real value-add is in the runtime, not the syntax. Java has a solid runtime but it's not yet as good as Erlang's, maybe even not up to the standards of Golang
won't lie, this is hilarious. you got me from nodding along to being the spitting out food meme guy in a span of couple seconds.
JVM runtime is undeniably the most well researched and optimized runtime in history of runtimes, specifically in realm of concurrency and parallelism, it literally carries like half the world on it's back.
not to throw any shade on erlang vm - i've been a fan for well more than a decade, but other than making some interesting, but limited in practice, tradeoffs with regard to concurrency architecture, it doesn't really offer much more.
go's runtime is just a different beast altogether designed with different goals in mind and with no baggage of backward compatibility with legacy.
one particular detail i'm very grateful to Clojure for, is exactly the ability to use JVM runtime without having to touch any Java.
> Programming language syntax scarcely matters
on the contrary, it matters quite a lot.
you might be drinking some of that AI koolaid, conflating our suddenly hypertrophied abilities to produce code regardless of our familiarity with the syntax or the APIs with ability to produce and deliver good quality products, but this delusion is getting reality check as we speak.
a realization is propagating through the industry that being able to produce more code than you're able to review, comprehend and internalize is actually not a great thing.
and that's where syntax matters - it has to be high signal/noise, it has to expose you to right abstractions and it has to be pliable to allow the codebase reflect the problem in a way that minimizes cognitive load both during production and during consumption.
LLMs are language models and syntax is a crucial part of any language.
from experience, during bursts it's never actual web/api server that is bogged down, it's the downstream io bottlenecks.
if your accepting layer is abstracted away and implemented correctly, there is very little performance difference between different concurrency approaches and all you're exposed to as developer is implementation of your handler functions.
thanks for the link, i was just recently trying to find that talk!
re server-side rendered fragments - htmx is extremely easy to integrate with your clojure(script) projects, i found it to be quite pleasant paradigm, but i have no skin in the game so take it with grain of salt xD
fun fact: clojurescript had support for asynchronous paradigm through core.async library (CSP style) long before async/await landed in javascript itself.
edit: i'm in no way trying to diminish the value of this release, just pointing out how cool it is that you can get new language features before they are available in the host language by just adding a library to your dependencies. clojure is awesome!
the benefit of lisp in an editor with integrated repl environment is that you get to see immediate feedback by easily evaluating chunks of your code as you navigate it, without copying stuff back and forth between the editor and the repl
and the benefit of lisp comes from the fact that every expression is fully delineated by parentheses, so you don't need to select any text, find the start or the end of any syntactic construction, you just eval the form you're standing at and see the result
or just as easily you can wrap that form, bind the locals to test values and eval that to see what changes
i'm surprised anybody coming from clojure would say this.
you absolutely do NOT need to learn paredit to write lisp, any modern vim/emacs/vscode plugin will just handle parentheses for you automatically.
that said, if you do learn paredit style workflow - nobody in any language in any ide will come even close to how quickly you can manipulate the codebase.
i can link you similarly undecipherable walls of text in rust and zig and c
but i bet if you sat down a junior developer not yet entrenched in any style yet, they'd be able to grok lisp code MUCH faster than the intricacies of syntax of the other alternatives ¯\_(ツ)_/¯
> What you're calling "data-oriented DSLs" is not constrained
constraints come from the interpreter, not from the syntax
> in my book just specifying a data-structure doesn't make a language
correct, it does not
what makes it a language is defining constraints on that structure and rules for how it's interpreted
that works both for clojure (where the data structure can involve lists, vectors, maps and primitives) and traditional lisps (where data structure is lists, or to be precise cons cells and primitives)
in both cases macros can be used and are used (but don't have to be used) to prevent immediate evaluation of those data structures according to host language rules and instead change how they are evaluated according to DSL author's rules
for example, datomic queries are just data structures, but they clearly form a constrained language with well defined semantics and the fact that they're not implemented via macros doesn't make them less of a DSL
wow, what a self report