midnight_eclair

tree style tabs and container-locked windows. that will make firefox perfect.

> Should tax payers fund these losses as well?

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

The old app version was actual "chat" application focused on conversations UI, new one seemingly got merged with Codex and conversations are an afterthought - you have to navigate to them, the history is unusable, everything got worse.

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

> isn't fraud .. can't be executed for fraud

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

> you don't know what exact crime has been committed

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?

[flagged]

> I assume you need Woke and rubbing "pride" or "Ukraine" into everything

wow, what a self report

because earth's geosync orbit is at 36k kilometers (function of gravitational force and rotation speed)

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