should governments make risky investments is a good question, but lets at least tax unrealized gains and wealth first.

Can anyone recommend a third party conversation-style app without all the codex bloat?

Comments URL: https://news.ycombinator.com/item?id=48909102

Points: 3

# Comments: 1

it'll be special kind of fraud, fraud against the planet, execution is ok for that one

we can start with:

Conspiracy to defraud is an agreement between two or more people to act dishonestly to deprive someone of property, cause them financial loss, or expose them to economic risk. It is a criminal offense, and the conspirators can be prosecuted even if the actual fraud is never executed or no loss occurs.

but i'm also ok with creating a separate crime against the environment and applying it retroactively to top management and politicians whose work and decisions have inflicted most damage.

> evidence for such conspiracy existing

that is exactly what should be investigated.

> should be "investigated" and "executed"

obviously executed when found guilty (i could be convinced that other forms of punishment are sufficient). why are you inventing things to get outraged about?

wow, what a self report

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.

https://news.ycombinator.com/item?id=48381598

that said im not anti ai, i just think it is being applied in the most moronic ways during this hype cycle (gary tan anybody?)

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.

> 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.

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.

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.

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.

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.

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

core.async isn't going anywhere, if async/await works better than promise based implementation, core.async will get an update in it's .cljs parts

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!