Bzip2 crate switches from C to 100% Rust (trifectatech.org)
148 points by Bogdanp 5h ago 58 comments
AMD's CDNA 4 Architecture Announcement (chipsandcheese.com)
112 points by rbanffy 7h ago 19 comments
LLMs pose an interesting problem for DSL designers
110 gopiandcode 86 6/17/2025, 7:17:05 PM kirancodes.me ↗
To be honest I don't think this is necessarily a bad thing, but it does mean that there is a stifling effect on fresh new DSL's and frameworks. It isn't an unsolvable problem, particularly now that all the most popular coding agents have MCP support that allows you to bring in custom documentation context. However, there will always be a strong force in LLM's pushing users towards the runtimes and frameworks that have the most training data in the LLM.
The new way would be to build a disposable jig instead of a Swiss Army Knife: The LLM can be prompted into being enough of a DSL that you can stand up some placeholder code with it, supplemented with key elements that need a senior dev's touch.
The resulting code will look primitive and behave in primitive ways, which at the outset creates a myriad of inconsistency, but is OK for maintenance over the long run: primitive code is easy to "harvest" into abstract code, the reverse is not so simple.
I'd argue that the problem of solving this effect in DSLs might be a bit harder than for frameworks, because DSLs can have wildly different semantics (imagine for example a logic programming DSL a la prolog, vs a functional DSL a la haskell), so these don't fit as nicely into the framework of MCPs maybe. I agree that it's not unsolvable though, but it definitely needs more research into.
What matters most of all is whether the DSL is written in semantically meaningful tokens. Two extremes as examples:
Regex is a DSL that is not written in tokens that have inherent semantic meaning. LLM's can only understand Regex by virtue of the fact that it has been around for a long time and there are millions of examples for the LLM to work from. And even then LLM's still struggle with reading and writing Regex.
Tailwind is an example of a DSL is that is very semantically rich. When an LLM sees: `class="text-3xl font-bold underline"` it pretty much knows what that means out of the box, just like a human does.
Basically, a fresh new DSL can succeed much faster if it is closer to Tailwind than it is to Regex. The other side of DSL's is that they tend to be concise, and that can actually be a great thing for LLM's: more concise, equals less tokens, equals faster coding agents and faster responses from prompts. But too much conciseness (in the manner of Regex), leads to semantically confusing syntax, and then LLM's struggle.
Let's say you want to generate differently sized text here. An LLM will have ingested lots of text talking about clothing size and tailwind text sizes vaguely follow that pattern. Maybe it generates text-medium as a guess instead of the irregular text-base, or extends the numeric pattern down into text-2xs.
Not just frameworks, but libraries also. Interacting with some of the most expressive libraries is often akin to working with a DSL.
In fact, the paradigms of some libraries required such expressiveness that they spawned their own in-language DSLs, like JSX for React, or LINQ expressions in C#. These are arguably the most successful DSLs out there.
Is this an observation of a similar phenomenon?
Even perhaps training a separate new neural network to translate from Python/Java/etc to your new language.
- There likely won't be one Skynet, but rather multiple AI's, produced by various sponsors, starting out as relatively harmless autonomous agents in corporate competition with each other
- AI agents can only inference, then read and write output tokens at a limited rate based on how fast the infrastructure that powers the agent can run
In this scenario a "Skynet" AI writing code in C might lose to an AI writing code in a higher level language, just because of the lost time spent writing the tokens for all that verbose C boilerplate and memory management bits for C. The AI agent that is capable of "thinking" in a higher level DSL is able to take shortcuts that let it implement things faster, with fewer tokens.
Plus if we assume the bottle neck on skynet is physical materials and not processing power, a system written in C can theoretically always be superior to a system written in another language if we assume infinite time can be spent building it.
> Suddenly the opportunity cost for a DSL has just doubled: in the land of LLMs, a DSL requires not only the investment of build and design the language and tooling itself, but the end users will have to sacrifice the use of LLMs to generate any code for your DSL.
I don't think they will. Provide a concise description + examples for your DSL and the LLM will excel at writing within your DSL. Agents even moreso if you can provide errors. I mean, I guess the article kinda goes in that direction.
But also authoring DSLs is something LLMs can assist with better than most programming tasks. LLMs are pretty great at producing code that's largely just a data pipeline.
Examples of domains that might be more challenging to design DSLs for: languages for knitting, non-deterministic languages to represent streaming etc. (i.e https://pldi25.sigplan.org/details/pldi-2025-papers/50/Funct... )
My main concern is that LLMs might excel at the mundane tasks, but struggle at the more exciting advances, and so now the activation energy for coming up with advances DSLs is going to increase and as a result, the field might stagnate.
So it's not just a question of the semantics matching existing programming languages, the question is if your semantics are intelligible given the vast array of semantic constructs that are encoded in any part of the model's weights.
To add to that... One limitation of LLM for a new DSL is that the LLM may be less likely to directly plagiarize from open source code. That could be a feature.
Another feature could be users doing their own work, and doing a better job of it, instead of "cheating on their homework" with AI slop and plagiarism, whether for school or in the workplace.
Consider MiniZinc. This DSL is super cool and useful for writing constraint-solving problems once and running them through any number of different backend solvers.
A lot of intermediate languages and bytecode (including LLVM itself) are very useful DSLs for representing low-level operations using a well-defined set of primitives.
Codegen DSLs are also amazing for some applications, especially for creating custom boilerplate -- write what's unique to the scenario at hand in the DSL and have the template-based codegen use the provided data to generate code in the target language. This can be a highly flexible approach, and is just one of several types of language-oriented programming (LOP).
Put differently, The languages people actually use had people who decided to use them, they picked the best ones. Making something new, you compete against the best, not the average. That's not to say that it can't be done, but it's not easy.
As AI systems improve, and especially as they add more 'self-play' in training, they might become really good at working in any language you can throw at some.
(To expand on the self-play aspect: when training you might want to create extra training data by randomly creating new 'fake' programming languages and letting it solve problems in them. It's just another way to add more training data.)
In any case, if you use an embedded DSL, like is already commonly done in Haskell, the LLMs should still give you good performance. In some sense, an 'embedded DSL' is just fancy name for a library in a specific style.
This mimics what you see in, say, Photoshop. You can edit pixels manually, you can use deterministic tools, and you can use AI. If you care about the final result, you're probably going to use all three together.
I don't think we'll ever get to the point where we a-priori present a spec to an LLM and then not even look at the code, i.e. "English as a higher-level coding language". The reason is, code is simply more concise and explicit than trying to explain the logic in English in totality up-front.
For some things where you truly don't care about the details and have lots of flexibility, maybe English-as-code could be used like that, similar to image generation from a description. But I expect for most business-related use cases, the world is going to revolve around actual code for a long time.
If compilers had significant non-deterministic error rates with no reliable fix, that would probably be a rather different timeline.
If something is useful people will use it. Just because it seems like llms are everywhere, not everyone cares. I wouldn't want vibe coders to be my target audience anyway.
In an initial experiment, I found that LLMs could translate familiar shell scripting concepts into Hypershell syntax reasonably well. More interestingly, they were able to fix common issues like type mismatches, especially when given light guidance or examples. That’s a big deal, because, like many embedded DSLs, Hypershell produces verbose and noisy compiler errors. Surprisingly, the LLM could often identify the underlying cause hidden in that mess and make the right correction.
This opens up a compelling possibility: LLMs could help bridge the usability gap that often prevents embedded DSLs from being more widely adopted. Debuggability is often the Achilles' heel of such languages, and LLMs seem capable of mitigating that, at least in simple cases.
More broadly, I think DSLs are poised to play a much larger role in AI-assisted development. They can be designed to sit closer to natural language while retaining strong domain-specific semantics. And LLMs appear to pick them up quickly, as long as they're given the right examples or docs to work with.
[1] https://contextgeneric.dev/blog/hypershell-release/
So with LLMs making it easier to project back and forth between how programmer sees the task at hand, and the underlying dumb/straightforward code they ain't gonna read anyway, maybe we'll finally get to the point of addressing the actual problem of programming language design, which is that you cannot optimize for every task and cross-cutting concern at the same time and expect improvement across the board - we're already at the limit, we're just changing which time of day/part of the project will be more frustrating.
Can someone help me out?
I say this from the perspective of someone who nearly became a PL researcher myself. I could easily have decided to study programming languages for my PhD. Back then I was delighted by learning about cool new languages and language features.
But I did didn't study PL but rather ML, and then I went into industry and became a programming practitioner, rather than a PL researcher. I don't want a custom-designed ML programming language. I want a simple general-purpose language with good libraries that lets me quickly build the things I need to build. (coughPythoncoughcough)
Now that I have reached an age where I am aware of the finiteness of my time left in this universe, my reaction when I encounter cool new languages and language features now my is to wonder if they will be worth learning. Will the promised productivity gains allow me to recoup the cost of the time spent learning. My usual assessment is "probably not" (although now and then something worthwhile does come along).
I think that there is a very real chance that the idea of specialized programming languages will indeed disappear in the LLM era, as well as the need for various "ergonomic" features of general purpose languages that exist only to make it possible to express complex things in fewer lines of code. Will any of that be needed if the LLM can just write the code with what it has?
Some deep PL stuff I doubt there is productivity gain to begin with. But many ideas in the ML language family are simple and reduce debugging pain. Time lost from one encounter with muddy JS/Python semantics is more than the time learning about sum types.
Maybe some boring, kind-of-consistent language like C, Python, or Go is good enough. An LLM spits out a pile of code in one or more of them that does most of what you want, and you can fix it because it's less opaque than assembly. It doesn't sound like a job I'd want, but maybe that's just the way things will go.
I wonder if we need a language designed to be easier for an AI to reason about, or easier for a human to see the AI's mistakes.
Here's the cursor rules file we give folks: gist.github.com/aaronvg/b4f590f59b13dcfd79721239128ec208
I don't blame anyone in the picture, I don't disagree that time saved with LLMs can be well worth it, but it still is a topic I think we in the PL community need to wrestle more with.
LLMs are surprisingly bad at bash and apparently very bad at Powershell
Pythonic shell scripting is well suited to their language biases right now
What humans look at and what an AI looks at right now are similar only by circumstance, and what I sort of expect is that you start seeing something more like a "structure editor" that expresses underlying "dumb" code in a more abstract way such that humans can refactor it effectively, but what the human sees/edits isn't literally what the code "is".
IDK it's not written yet but when it is it will be here: https://kylekukshtel.com/llms-programming-language-design
In the end I think mentioning Python is a red herring. You can produce an eDSL in Python that's not in LLM training data so difficult for LLMs to grok, and yet still perfectly valid Python. The deeper issue here is that even if you use Python, LLMs are restricting people to use a small subset of what Python is even capable of.
* Not just English, substitute any other human language into the above
DSL's would be even harder for LLM's to get right in that case compared to the low-resource language itself
But Python/Julia/Lua are by no means the most natural languages - what is natural is what people write before the LLM, the stuff that the LLM translates into Python. And it is hard to get a good look at these "raw prompts" as the LLM companies are keeping these datasets closely guarded, but from HumanEval and MBPP+ and YouTube videos of people vibe coding and such, it is clear that it is mostly English prose, with occasional formulas and code snippets thrown in, and also it is not "ugly" text but generally pre-processed through an LLM. So from my perspective the next step is to switch from Python as the source language to prompts as the source language - integrating LLM's into the compilation pipeline is a logical step. But, currently, they are too expensive to use consistently, so this is blocked by hardware development economics.
Maybe designing new languages to be close to pseudo-code might lead to better results in terms of asking LLMs to generate them? but there's also a fear that maybe prose-like syntax might not be the most appropriate for some problem domains.
I suppose this could be done now for all the existing languages that target LLVM and unify the training set across languages.
LLMs seem pretty good at figuring out these things when given a good feedback loop, and if the DSL truly makes complex programs easier to express, then LLMs could benefit from it too. Fewer lines of code can mean less context to write the program and understand it. But it has to be a good DSL and I wouldn't be surprised if many are just not worth it.
As someone who loves a wide diversity of actively evolving programming languages, it makes me sad to think those days of innovation may be ending. But I hope that's not going to happen.
It has always been the case that anyone designing a new language or adding features to an existing one is acutely mindful of what programming language knowledge is already in the heads of their users. The reason so many languages, say, use `;` for statement terminators is not because that syntax is particularly beautiful. It's just familiar.
At the same time, designers assume that giving users a better way to express something may be worth the cost of asking them to learn and adapt to the new way.
In theory, that should be true of LLMs as well. Yes, a new language feature may be hard to get the LLM to auto-complete. But if human users find that feature makes their code easier to read and maintain, they still want to use it. They will, and eventually it will percolate out into the ecosystem to get picked up the next time the LLMs are trained, in the same way that human users learn new language features by stumbling onto it in code in the wild.
So I'd like to believe that we'll continue to be able to push languages forward even in a world where a large fraction of code is written by machines. I also hope that LLM training cost goes down and frequency goes up, so that the lag behind what's out there in the world and what the LLMs know gets smaller over time.
But it's definitely possible that instead of that, we'll get a feedback loop where human users don't know a language feature even exists because the LLMs never generate code using it, and the LLMs never learn the feature exists because humans aren't writing it.
I have this same fear about, well, basically everything with LLMs: an endless feedback loop where humans get their "information" from LLMs and churn out content which the LLMs train on and the whole world wanders off into a hallucinatory bubble no longer grounded in reality. I don't know how to get people and/or the LLMs to touch grass to avoid that.
I do hope I get to work on making languages great for humans first, and for LLMs second. I'm way more excited to go to work making something that actual living breathing people use than as input data for a giant soulless matrix of floats.
DSLs look great if they let you write the code you already know how to write faster. DSLs look like noise to everyone else, including Gemini and Claude.
I used to be a big DSL booster in my youth. No longer. Once you need to stop what you're doing and figure out your ninth or eleventh oddball syntax, you realize that (as per the article) Everything is Easier in Python.
Exactly right. Now that we're in the era of LLMs and Coding Agents it's never been more clear that DSLs should be avoided; because LLMs cannot reason about them as well as popular languages, and that's just a fact. You don't need to dig any further, to think about pros and cons, imo.
The fewer languages there are in the world (as a general rule) the better off everyone is. We do need a low level language like C++ to exist and a high level one like TypeScript, but we don't _need_ multiple of each. The fact that there are already multiple of each is a challenge to be dealt with, and not a goal what we reached on purpose.
Also, domain-specific stuff can still be useful sometimes, and other stuff involved with designing a programming language.
My experience so far is that they write mediocre code which is very often correct, and is relatively easy to review and improve. Of course I work with languages like elixir, python, typescript, and SQL - all of which LLMs are very good at.
Without a doubt I've seen a significant increase in the amount of work I can produce. As far as I can tell the defect rate in my work hasn't changed. But the way I work has, I'm now reviewing and refactoring significantly more than before and hand writing a lot less.
To be honest, I'd worry about someone's ability to compete in the job market if they resisted for much longer. With the obvious exceptions of spaces where LLMs can't be used, or have very poor performance.
It'll dump you three classes and a thousand lines of code, where it should use a simple for loop to iterate.
The code Claude, Gemini and Cursor produces still is not enough to pass half-decent quality checks. If you're in "compile=ship", sure.
If you care about performance, or security, or maintainability, no. It's wasting your time, and the review team's time.
They're riding a horse in the age of automobiles, just because they think they're more comfortable on horseback, while they've never been in a car even once.
Its primary point is that TIOBE is based on *number* of search results on a weighted list of search engines, not actual usage in Github, search volume, job listings, or any of the other number of signals you'd expect a popularity index to use.
It could easily be indicating that Python articles are being generated by LLMs more than any other class of articles.
And yes, this only adds up to 23. The TIOBE web site doesn't explain the discrepancy.
""" Remarkably, SQL has started dropping slowly recently. This month it is at position #12, which is its lowest position in the TIOBE index ever. SQL will remain the backbone and lingua franca of databases for decades to come. However, in the booming field of AI, where data is usually unstructured, NoSQL databases are often a better fit. NoSQL (which uses data interchange formats such as JSON and XML) has become a serious threat for the well-defined but rather static SQL approach. NoSQL's popularity is comparable to the rise of dynamically typed languages such as Python if compared to well-defined statically typed programming languages such as C++ and Java. """