I think your prediction is a bit early. Maybe a decade early. 2033 is 7 years away. The transition is happening really fast, faster than most people (or political leaders) know, but not that fast.
We will hit 1TW per year of new solar soon, but to get to 100% electricity by the end of 2033 I think we would need closer to 3TW per year.
How does parallelism come into play for this conversation? Async/await is a concurrency construct. And Java’s virtual threads are also a concurrency construct. Neither of them have anything to do with parallelism. Or am I misunderstanding something?
I'd say Java's virtual threads are also a parallelism construct (at least in the performance sense, not logical guarantees), since they're scheduled on a pool.
I was bit disappointed how few metrics the article mentioned. There are tons of code quality metrics that have been thought of over the last 40 years. We don’t have a good idea which ones are worth enforcing though. And we don’t know if the metrics that are good for humans are also good for LLMs
> You and the other poster just need to find some agreeable benchmark so you can decide who won.
That is the hard part. I'm not sure the usage numbers we'd need to decide the outcome are public now, and I can't predict ~4yr out whether any currently available metric will continue to be available. Stack Overflow's popular language thing has been going for a while, that will probably still exist (if SO does) but do we have any reliable metrics to tell us what fraction of code is AI generated?
I think the outcome will be very obvious when the the time comes to settle the bet, but I agree that it's not easy to write those terms today.
But speaking of Stack Overflow, that's a good point to examine more closely. Simply looking at Stack Overflow's usage trend [1] should have been a strong clue that a seismic shift was under way. A couple of things could be responsible for it, though:
1) Stack Overflow's movers and shakers have finally assholed themselves into irrelevance. That's possible, and it could potentially explain the secular decline that began around 2015. But it doesn't explain the rate of descent since 2023, given that the core rules haven't changed for years. It also doesn't explain the meteoric rise between 2008-2014. What they were doing clearly worked, right up until it didn't.
2) AI is now answering questions that would previously have been posted to SO. That's the conventional argument. Hard to dispute it. And it leads to...
3) Stack Overflow has not failed its mission, but fulfilled it: most of the code that will ever need to be written already has been. That's an argument I've never seen anyone else propose, likely because it's a really stupid argument that's been made many times before. I think it's true this time, though, at least until genuinely-new hardware paradigms come along. I think it's a big reason why AI will be doing our jobs for us going forward. Programming is a robot's job now.
3a) As a corollary not related to the SO question, I think the math community is starting to wake up to a similar realization: we have all the math we need. Or, rather, we have all the math we can comprehend. The low-hanging fruit is all gone. Mochizuki's work, which requires a large part of multiple peoples' careers to prove or refute, is an example of that phenomenon. Leading mathematicians are coming to recognize that their best shot at contributing to progress in math is to work on AI.
The groundwork has been laid, and now we need to find better ways to reuse and recycle what we have. That's how AI will help us reach the next level. It's just crazy to think that our industry will be recognizable in 3-5 more years.
As a joke. Back when 2 came out, they promised there would never be a version 3. I.e., no breaking changes. Then they realized they did need to make a breaking change, so the only way to be true to their promise was to skip version 3.
No, you misunderstand what is going on. htmx is an exercising in learning web development by someone who didn’t follow 2 decades of web development progress.
He is catching up though, now approaching the early 2010s jQuery (moxi) and backbonejs era with fixiproject.org
Htmx is a direct descendant of Intercooler.js, which has been around since circa 2013, more than a decade. Intercooler still exists and is used in production, and you can clearly see that it works almost exactly the same way as htmx does today, it just bundles jQuery together.
The creator has been working on these ideas for a long time, but the core idea–swapping HTML from the server into the DOM–has been constant throughout.
It's exactly because he followed the past two decades of web dev that htmx avoids almost everything about it. Fixi and htmx extensions follow the 80/20 principle and can work by just being dropped in with a script tag. You don't need an elaborate npm setup, same as everything else in the htmx ecosystem.
The creator is stuck in 2012 and so on as I said. If you look at project fixie, the reason htmx 4 exists, it shows how the 80/20 is an incomplete idea for something as general as a web framework. 80/20 might work for your specific use case, but as a general notion, it either gets built on reasonable constructs or grows into a Frankenstein. Htmx approach is a mirror of yaml in my ways. In denial of what it is trying to be and so turns into complete monster.
Correction: they didn’t ‘realize they needed to make a breaking change’, they got excited by the improvements they could unlock by using the Fetch API and wanted to make a breaking change.
The upgrade is completely voluntary: it won’t even be set as the default version in npm till next year, and there are no known security issues that would force anyone to upgrade. People happy with v2 can just stay on it for the foreseeable future.
I wish they would have done what Taalas did with chatjimmy.ai and just directly host a model for us to view, rather than just claiming it’s 50x faster than Nvidia/groq. Their claim is specifically for a 1 trillion param model. So they could have just grabbed GLM 5.2, or similar, and hosted it.
Joke’s on us, all of their pages are LLM pages! LLM generated, that is.
Btw, can guarantee that they are not ready to demonstrate that yet. They’re using 2D FLASH with 30M weights per die [1], so to get to 1T they will need… 33,333 dies. Interesting scaling problem to say the least
But they also declare having a "Mead" technology that stores at least 175b NNs in a single chip through 3D stacking - see https://www.mythic.ai/mead and other posts in this page.
A confusing thing is that the goal is tackled through a number of proposals... Why Vanguard if they have Mead? If Mead, how to get the memory integration that are explicit on Vanguard?
100x seems like an underestimate. Even with no model improvements, we should see that sort of reduction. Looking at TSMC’s margins, Nvidia’s margins, and OAI/Anth (alleged) margins on inference, there is a room for a 100x reduction.
Right now all three of those are at abnormally high levels. Competition will come for all three.
Ive been amazed at how well LLMs are at writing Gleam[1] and Lustre[2]. Compared to a mainstream language, there is basically zero gleam code in the training data.
I have no evidence to back this up, but I suspect that languages that are good for humans[3] will be good for LLMs. Compiled, strongly typed, statically typed, immutable, pure functions, pattern matched, memory safe, etc.
[1] https://gleam.run
[2] https://lustre.hexdocs.pm
[3] Yes I realize that languages features that are "good for humans" is a hotly debated topic. That's just my personal list for what I like in a language.
I used to hold this opinion but since changing to Rust on the server and Typescript on the client, I can confidently tell you agents are so much better at Rust, especially at producing idiomatic code, than they are at Gleam.
There are reasons to love Gleam and Lustre (I like Gleam a lot), but LLMs just aren't one of them. I made the switch to Rust around May this year. Also the community is super anti-AI, arguably with good reason (how it impacts open source), and I'd recommend keeping your AI code to yourself.
I’ve been developing a language for a few years, and even with incomplete semantics and a simple one page example LLMs don’t have much trouble writing it.
I think the language/syntax has an impact, but the tooling around it will be most important for LLMs, in the same way it is for humans.
I'd agree. I've spent the last month running an experiment, having an LLM being up a self-hosted compiler. It has no problem writing complex code in a never before seen language with severe constraints[immutable, no naked recursion, recursion schemes].
The biggest challenges are maintaining non-functional requirements, specifically CPU and memory effenciency.
Gleam has been stable for over two years, so maybe it's been long enough that LLMs have internalised the documentation.
Given it's a language that doesn't really contain any groundbreaking ideas[1] (the closest is 'use' IMO), it's possible LLMs can reuse patterns from other functional language.
[1] This isn't criticism. I love how Gleam turned out.
That's not a take I was expecting to find here. I've found most LLMs absolutely dreadful when it comes to Gleam, to the point that I most often disable even inline autocomplete when working in Gleam codebases.
Too often I find them getting pulled into larger ruts in the training data and trying to insert language features that don't exist (ifs, loops, and syntactic constructs) from more popular languages like TypeScript and Rust. Do you not experience other languages getting partially substituted in when you have LLMs write Gleam?
I suspect it depends a lot on the llm/harness being used. But when I use Opus/cc or sol/codex, at the end of the turn everything compiles, passes tests, and passes lint. I never even look at code that can't compile. Maybe the LLM is generating weird stuff in-between, but I don't see it.
What you're describing feels like my experience back in 2024/25. Back then I was using a llm auto complete or the chat interface, and I would get weird stuff all the time. (not just gleam but any language).
You’re talking about autocomplete! That’s always a poor model doing it because it has to be fast enough. I never use that anymore in any language, it’s only occasionally helpful. I suspect everyone is talking about agent harnesses here , not autocomplete. With a harness, the agent not only can be more powerful (and slow) it can go into “thinking” mode and once it comes back with some code , it’s almost always quite good. I think this is true in Gleam and in many other languages, no matter how minor, as long as it has good docs and good error messages so the AI will fix dumb mistakes before you get to see it.
I think that just shows LLMs are great at almost any language. As the post says, it can get very poor, as with J and Factor, but anything remotely easy to read for humans seems to be perfectly fine for LLMs. I can say I am still to try a language they struggle with myself. Tried Dart, Groovy, Common Lisp, Elisp… and more. It is an expert in all of them and I can’t really tell they advantage one over another. Our mixed Kotlin Java huge code base is a walk in the park for Opus5 and Fable5.
For an even more niche language, Roc basically became usable in the new syntax about two months ago (still has compiler crashes, there's a good reason it hasn't had a real release) but Opus writes it just fine after a couple corrections to handle the language's quirks.
I’m assuming the data for Europe is largely correct, but a lot of the per country data doesn’t pass the smell test to me. Afghanistan (35 days), Libya (45), Yemen (46), etc. what percentage of workers there are getting that many paid days off?
Edit - the original source even had the audacity to label Yemen with a “smiley face” since it has the most paid days for the region.
I would highly recommend https://diysolarforum.com/ and Will Prowse on YouTube. Thats how I made my solar/battery system. And it passed city inspection.
We will hit 1TW per year of new solar soon, but to get to 100% electricity by the end of 2033 I think we would need closer to 3TW per year.
reply