I get the impression there is some deeply entrenched individual in the Mozilla Foundation with an abiding hatred for Tree Style Tabs who will never let it deliver what users want without the end-user discovering (using only their native wit) a process roughly equal in complexity to compiling Firefox from source.
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?
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.
> `(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.
LLM bashing aside (although I tend to agree), I agree with midnight_eclair. The claim that Erlang or Go are outright superior to the JVM doesn't really stand up. They're better at some things, and worse than others.
Regarding language syntax, it definitely matters. In the same way the vocabulary we use shapes our thoughts, the expression of a programming language shapes the implementation. Of course, as Clojurists know all too well, it's entirely possible to write Java in any language!
I don't think you, I, him and others necessarily disagree at all here, it's just that living language has defects and I can't spend 30 minutes clarifying beforehand like I am doing a math proof.
To me the strengths of Erlang BEAM VM and Golang's runtime nullify their weaknesses (and of course they do have weaknesses, some are pretty hard to swallow too). To me they sit on the positive side of "right tool for the job".
I just can't work with global mutability anymore. It's an endless hopeless pit of determinism bugs. I picked my battles. Respect to whoever wants to make a career out of chasing them but that's no longer me. I want to make measurable business progress when I work and not babysit defects that should have stopped existing two decades ago.
I can agree with other posters that the JVM has come a long way. I might reassess if I get the time. And I am not bashing on anything here. I am saying what my experience showed me. To me it's tiring to pretend that all languages and runtimes are equal and I'll keep claiming they are not.
As mentioned above: I don't think we necessarily disagree at all.
Well, you are kind of using my comment to vent your frustrations about AI while it has barely anything to do with it -- but you tried to link the two, unsuccessfully. Which is not fair as you have no clue of my stance on AI and are extrapolating a bit too much.
Syntax does not matter simply because it's an extremely leaky abstraction of the runtime below, is my point.
Of course syntax must be high signal/noise ratio, I believe every reasonable programmer will agree. But many are making entire careers in PLs where that's not the case. Hence, in practice it does not seem to matter much, for the better or the worse.
RE: runtime, try and pay attention to the parameters given in my comments. I specifically acknowledged that the JVM is a great and mature runtime but it's lagging behind on STM / actor capabilities. 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.
> 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.
> that would be the reason why syntax does matter, wouldn't it? nobody wants leaky abstractions!
Well I thought we were describing our current reality, not our _desired_ one? Yes nobody wants leaky abstractions and yes they are everywhere.
Syntax matters insofar as to discourage bad habits, is what I'd refine from my previous statements. Most programmers go for the default so defaults and syntax that steers you the right way to think and write matter a lot.
That being said, people write FP Rust (myself included) and have plethora of JS libraries where immutability and FP patterns are the default. Which is a sad state of affairs but much better than nothing -- as it's introducing programmers to immutability and FP and they otherwise would never know.
> 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.
That was my top 1 reason to try it btw; I was intrigued by the fact that people are interested in making it work universally in at least two very different runtimes. To me that signals good language design and good architecture. Which I already knew; Clojure and Racket are amazing on their own.
> 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).
As already said multiple times in the thread -- my info is stale (as claimed by multiple posters).
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!"? If not, I'll not yet revisit.
I just don't want to deal with the endless pit of determinism bugs that global mutability nets us. The gift that keeps giving.
If Akka / Golang's runtime / Rust's various actor-emulating libraries catch up to the OTP, I'll very likely drop Erlang/Elixir because it's a struggle to have a good stable employment (or even contracting lately) with them.
Even if the BEAM VM is slower and has a few annoying sharp edges, its strengths nullify its weaknesses due to the nature of my work (HA web / API servers and also API gateways and orchestrators).
> 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.
Well, I don't think you and I disagree on the premises, with the exception of you believing that I make some outrageous general claims -- which I did not.
> you make it seem as if the world of software development is in some constant battle for supremacy
I could have misinterpreted other people in the past -- very possible. But I also stopped caring about "battles for supremacy" a long time ago and at this point in life and career I simply use my experience and brain to go where my work is more productive, deterministic and fulfilling. To me immutability, share-nothing actors, strong vertical scalability (where a lot of PLs and runtimes do well, not only my favorites) and DX (like live prod REPLs and generally trivial observability) are those axii along which I thrive.
You and a few others seem to have emotional reactions to this which, I assure you, are very unnecessary. I ain't threatening neither your livelihood nor preferences.
> 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?
Amazing how it doesn't even cross your mind that there are trade-offs to those choices. Green threads are awesome, but guess what, they come at a cost. Same for share-nothing semantics.
> 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!"?
You are again presupposing the BEAM has an absolute superiority over the JVM. "Better runtime" makes no sense on its own. Better is always relative to something. Better for whom? For what?
I'd bet that you work on a traditional CRUD enterprise software, and that IO(the database) is the real bottleneck of your app. In that case, sure, the BEAM is a solid choice(so is Python, Ruby and PHP nowadays). But let's please not pretend that is all there is to software engineering.
Any good reason for your rude tone? If we are going to invoke the what crossed somebody's mind trope, I'd lead with that when talking to you -- did it cross your mind to speak calmly and not assume something "did not cross" somebody's mind?
RE: your other similarly rude comment, I have not "appealed to authority" anywhere. I said that I have used multiple PLs / runtimes and made an informed choice... for me. I don't intend to add "...for me" after each sentence. It's redundant and obviously implied when it comes to tech because obviously people have made well-working prod systems with combinations of bash and Perl ages ago. So obviously people can make nearly everything work.
If you don't intend to discuss out of position of curiosity but want to jump on people then I am not interested.
Your first comment assumed I was "speed-running to a conclusion and squinting too hard", and this was "similar to the weird childish name-calling". I think that is in the same area(or worse) than saying "Amazing how X didn't even cross your mind". And sorry, but invoking that you have experience with X, Y, Z and thus your opinion is informed after criticizing some technology IS an appeal to authority.
> If you don't intend to discuss out of position of curiosity
I'm not the one making sweeping statements on the superiority of one piece of technology. Reading your other response, I think you are the one who have little to no curiosity in understanding how you might be wrong.
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.
Not the case; good abstractions are valuable, but the performance differences between runtimes are very real.
Take the example of some simple HTTP<->blob store service gets slammed with millions of requests when someone using the API does a backfill via some framework on their end that aggressively scales request volume up and out.
Something like, say, async Python/starlette with a coroutine per request is gonna perform slightly worse than Erlang, which in turn is gonna perform much worse than Go.
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.
It really takes surprisingly little volume to cripple a return-hello-world Phoenix app that indirects the "hello world" behind way too much middleware and message passing; it takes even less to kick over, say, a Gunicorn instance returning "hello world" at the bottom of the Django middleware stack. Golang with Gin, on the other hand, is surprisingly hard to cripple in the same way. And I say that as someone who likes Elixir and Python a lot more than I like Go!
Thank you. As a guy who made a career out of Elixir (and begins to regret it recently but oh well) I agree that Elixir's throughput is not amazing. However, it can get very far and we should always optimize for the most common usages.
I've personally rewritten one hobby and one professional projects from Elixir to Golang and loved the result; as you said, extremely difficult to bring down a Golang service to its knees.
One clarification: Phoenix server behind Caddy/nginx fairs better btw. But, details. Your point stands.
I am yet to see a Rust web/API service I wrote to _ever_ buckle under pressure and just crash. It was either an application bug (like the famous Cloudflare's `.unwrap()` error from the last weeks/months) or the Linux OOM killer. Literally never crashed. But I did witness it brutally murder a MySQL cluster because it couldn't serve it fast enough. That was both fun and terrifying to watch on the dashboards.
> I did witness it brutally murder a MySQL cluster because it couldn't serve it fast enough. That was both fun and terrifying to watch on the dashboards.
Haha yep. In my experience, everyone running CGI/process-per-request application servers is bullish on switching to a concurrent or cooperative runtime...until they realize they just removed the primary ratelimiter on downstream DB/service accesses.
The converse war stories are also amusing: people rewrite their whole app in a concurrent/asynchronous framework and nothing changes, because the DB driver is still farming out all queries to a tiny fixed-size threadpool of connections that was the bottleneck all along.
Oh yeah, definitely. If your DB server (or any storage backend) cannot have like 200+ connections alive at all times then it's absolutely pointless rewriting your app in Elixir or Golang. You'll just serve DB timeouts in your responses.
> 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.
> focus their efforts on ensuring downstream IO doesn't get overwhelmed (db read replicas, caching, etc) before optimizing runtime performance or autoscaling out unnecessarily.
All good advice, but the choice of runtime can affect the point at which autoscaling and load balancing even need to enter the conversation at all. Optimizing, say, a mostly in-memory cache service and writing it in Golang may yield results like "we can run a single instance of this and serve three orders of magnitude of business growth; slap it behind a DNSRR or a k8s NodePort for update/replacement/fast failover if it crashes, no complex load balancer needed", where writing the same thing in, say, PHP might require discussing orchestration/load balancing/memory/worker process recycling/autoscaling early on in the service's lifetime. Being able to skip those conversations (entirely or for a long time) is a very significant business benefit.
(Upvoted for a really relevant and valuable refinement to the thread.)
Admittedly that layer is almost always abstracted i.e. AWS / GCP and various other smaller hosted solutions that handle a good chunk of load balancing for us. In that landscape BEAM VM's strengths shine even brighter. I've seen firsthand that you can in fact bring a BEAM VM to its knees if you expose it just like that to the net. It's not pretty. Golang fares a touch better and Rust seems almost immune (provided one does not screw up their caching layer and don't do elementary N+1 query mistakes).
