To me this is almost like a tone-deaf naming change.
Empty Slot (new Pro as Mythos competitor?)
Old Pro -> now Flash
Old Flash -> now Flash Lite
Old Flash Lite -> now Gemma (and not served by Google)
I say "almost" because the situation is more fluid and unstable than a normal naming change. If Apple were to do this with laptops, maybe it'd be like, Air gets better and pricier and becomes Pro-level model, Neo same way becomes Air-level model, etc. But Apple's too design oriented to do something like that. Google, well...
This change has made me decide to move to a multi-provider situation like through OpenRouter for consumer-facing LLM api in a service I'm building. I just can't trust Google to not constantly rearrange everything under our feet. Doesn't mean I won't use Gemini, but it clearly means I need to have others in the mix ready to go. In fact I used to use lots of Flash Lite, which is now Gemma territory, and I can't get that served by Google anymore and don't want to run my own hardware.
But in any case, I'd compare this "Flash" model with previous "Pro" on all metrics. It's kinda like if in clothes a Small suddenly became what was a Large, or at Starbucks a Grande became the new de facto Venti. And only for the new! drinks.
And if we think this way, it's possible that prices are actually falling?
Using Clojure and Elixir and LLMs are fantastic with both. Sure, if I get to a super-stable situation then maybe I'd consider moving to Rust (or Jank?), but for now I'm just so happy with Clojure and Elixir in this new world. I'm solving new problems with fully bespoke architecture so the flexibility is key. Clojure for business logic and most DB. With Elixir, it's the actor model and hand-holding as I'm using it for the web layer. I bet Ruby on Rails would also shine for some cases, prob most CRUD for example.
For me, I need to move fast and already knew Phoenix well, LiveView fits my use case, and websockets setup with Phoenix is very clear so switching to a two-language setup seemed better than CLJS. I could have gone CLJS re-frame and all that but it would have been more work and more unknowns. I call LLMs from Elixir also so all of the reconnect, backoffs, papercuts, shenanigans and so on, well I just know how to do this kind of thing better in Elixir. In its way Elixir is a great, like, defensive language. I was able to keep most async in Elixir and Clojure mostly synchronous. There was some pain though with bridge between the two and at times I thought I'd made a mistake. Clojure is fantastic with data and Datalog databases, so no regret. Outside world deals with Elixir, and the temple is in Clojure and Datalog.
Most developers evaluate programming languages by comparing features in isolation, never stepping back to consider the overall experience of using one.
Features are easy to talk about. They're discrete, nameable, and comparable. "Does it have Foo?" is a question you can actually answer. "What's it like to build and maintain a real system in language X for two or three years?" isn't. So people default to what's measurable.
Most devs haven't spent serious time in more than two or three languages in production. Without that contrast, the holistic experience is invisible - you don't know what you're missing, and you don't notice the pain you've learned to live with.
Language communities form around features because features make good rallying points. "We have algebraic types." "We have macros." These become identity markers. The holistic experience doesn't tribalize as cleanly - it's harder to put on a t-shirt.
There's also a sunk-cost angle: devs who've spent years in a language have every incentive to believe its features justify the investment. Honestly evaluating the overall experience might undermine that.
The irony is that the languages with the most devoted communities tend to be loved for exactly these holistic reasons - the ones that are nearly impossible to convey through a feature list. You can rave about Clojure or Elixir all day, but a curious newcomer will land on the homepage, scan the features, and walk away unimpressed: "Meh, it doesn't even have Foo. People say this is great? They clearly don't know what they're talking about."
Well in a recent project I tried TypeScript thinking, OK, LLMs, huge training corpus! massive adoption! api for everything already set up! swim with the current! and I tried various frameworks and so on, but for me reasoning about things and being able to make systems that I could adapt and pivot it was honestly inferior compared to niche Elixir and Clojure. But it's not like I hate JS; I use it in LiveView all the time. And don't mean to imply there are no problems in niche-land though; you've got to be willing to do more yourself and live in a tiny world. Really, LLMs kind of tamed Clojure for me because it seems so far at least that they can handle the glue code and stitching libraries together pretty decently as long as you don't get lazy with architectural choices and stay vigilant. And if I ever hire it pretty much has to be remote or learn on the job, though again LLMs reduce this pain greatly.
I'd be interested in soft drinks that were unsweetened altogether and not just sugar free. Sometimes I have sparkling water + apple cider vinegar + lemon/lime juice and it's wonderful when well mixed.
I've got a couple of sweetener-free recipes I use with my soda maker, though I should warn you nobody else I've given them to likes them. But I like them well enough.
One is a couple of squirts of vanilla, a couple of squirts of lemon juice, and a bit of salt. Salt is probably an underappreciated drink ingredient for this sort of thing. It turns out it isn't in your soft drinks just to make you want to drink more. This makes something that is related to cream soda, except for the aspects of cream soda that come from being crammed full of sugar, which I can't do much about.
I also have a mix I keep around made out of 3 tablespoons salt, 1 cup vanilla, 1/2 cup lemon juice, 1/2 cup lime juice, and about 1/3rd cup almond extract. I measure it all (except the salt which I just put in directly) into a single 2 cup Pyrex dish and just sort of eyeball the last 1/3rd cup of almond extract, then funnel it in to a holder. I use McCormick 32 oz vanilla and almond extract for this and order bulk RealLemon and RealLime juice for this from Amazon, and mix it into one of the leftover bottles and keep it around refrigerated. 3 squirts and "whatever dribbles in" as I'm removing the bottle is what I used for one DrinkMate bottle. To taste, as all of this is, of course. If nothing else this is pretty cheap per drink.
You can also mix unsweetened electrolytes in, but you have to wait until after you dilute the mixture with water or it'll react with the lemon & lime juice. Salt you can keep in the mix but not electrolytes in general. It adds a certain body to the mix even if you're not interested in the electrolytes per se, and a single packet of them lasts a long time.
You're not going to go into business selling this stuff, but if you're already drinking unsweetened apple cider vinegar & lemon/lime juice as a beverage flavoring we might just have some compatible tastes here. Carbonation is required, though, otherwise the vanilla and the almond extract don't come through at all.
The problem is that carbonic acid is bitter, and if you have a carbonated beverage, you have carbonic acid. Usually, this bitterness is balanced by sweeteners.
VS Code and its forks (Cursor, Antigravity, etc.) have Calva, a fantastic REPL with excellent linter Kondo. These are amazing tools; formatting is the very least of it. You don't need Emacs. I personally using VS Code + Doom Emacs. Also, many packages that look abandoned are simply mature. You can literally use ten year old packages.
I'm not a hot shot programmer, entirely self-taught but a decent architect who thinks hard about problems, and with LLM agents Clojure shines for me. There are some fantastic databases also starting with Datomic -- free now thanks to Nubank -- and everything inspired by it and the Clojure flavor of Datalog. These include Datalevin, Datahike, DataScript, XTDB. Datomic itself is probably best for enterprise though there's now an embedded version.
But I'm pretty convinced that most LLMs I've used are more reliable with Clojure (and Elixir) than with most of the popular languages, and I can say they use Datalog extremely well, seemingly much better than SQL despite the vast difference in corpus size. For one thing Datalog just gets rid of joins issues.
> I worry about new languages though. I guess maybe model training with synthetic data will become a requirement?
I read a (rather pessimistic) comment here yesterday claiming that the current generation of languages is most likely going to be the last, since the already existing corpus of code for training is going to trump any other possible feature the new language might introduce, and most of the code will be LLM generated anyways.
I had the thought of an AI-specific bytecode a while ago, but since then it's seemed a little silly -- the only langs that work well with agentic coding are the major ones with big open-source corpuses and SO/reddit discussions to train on.
I also saw something about a bytecode for prompts, which again seems to miss the point -- natural language is the win here.
What is kind of mysterious about the whole thing is that LLMs aren't compilers yet they grok code really well. It's always been a mystery to me that tools weren't smarter and then with LLMs the tooling became smarter than the compiler, and yet ... if it actually was a compiler we could choose to instruct it with code and get deterministic results. Something about the chaos is the very value they provide.
reply