Yes, large. I haven't used Zig much myself, but from a few experiments I ran, Zig handles dead code elimination exceptionally well. It compiled a full Win32 GUI calc app that used Capy (a full, cross-platform GUI framework) into a 133kb executable. Removing Capy completely and using Win32 APIs directly produced an even smaller (93kb) binary (it also removed some DLL dependencies, leaving basically only ntdll.dll). For the same task, Rust + Slint produced a 4.7 MB binary that still depended on multiple (non-Windows-provided) shared libraries.
Given another commenter's mention of a similar project written in Nim that yielded a 1.6 MB binary, my first guess is that the 6 MB Zig binary simply isn't optimized for size - it might be a debug build. If not that, then I'm not sure what's happening, but yeah, in the context of Zig, 6mb for a CLI app is a bit strange.
Steam provides a stable Linux runtime, but it's not containerized or isolated Docker/Flatpak-style. It's closer to a chrooted env with some specific distro, but without chroot and the need to maintain said distro. They want to provide runtime stability and compatibility comparable to that on Windows - it's a great initiative, and I really hope they'll succeed. The snowflake-like userlands on Linux are a pain, but the current solutions (Docker, Flatpak, things like conda) are all bad solutions to this particular problem (though they are good solutions to other problems, so it's not a criticism, just a difference in goals).
However, Steam Runtime for Linux was still in beta, last I checked. Plus, it doesn't solve the cross-platform part. But for Linux-native development, Steam Runtime might be what's needed to have long-term compatibility for apps (finally).
It doesn't have to cost money. You can write a normal Windows app and run it under Proton. For end users, provided that they have Steam installed (it's free), they can just add "Non-Steam game" to the library - it's ~4 clicks.
It works. It works great. It's actually the only sensible solution if you want something compiled today to work without changes on both Windows and Linux in 10 years.
I did an experiment, implementing a GUI calculator, and Rust + Slint + cross-compiling to Windows (I develop on Linux) + Proton runtime was the clear winner:
- compiled bundle: 20 MB (F#/dotNet + Avalonia: 207 MB)
- loc: ~1000 (dotNet: ~700)
- dlls: none other than what Wine provides (dotNet: 67 .dll files)
You have an option to build for Linux for dev/testing, then you cross-compile to Windows and provide a short (4 points) instruction for adding the Windows build to Steam on Linux. It works, and it will most likely continue to work in the future, unless Valve folds and both Wine and Proton die. The only thing worth looking out for is crates that depend on external shared libraries: you need to bundle them manually. Other than that, it works.
Another option I considered was Zig with the Win32 API, but the LOC count was unacceptably high.
I'm working on a write-up for the experiment. The premise was: "I'm working on Linux and want to create a GUI app that will, with the build done today, continue working on Windows and Linux for the next 10 years". Steam/Proton + mostly static compilation + bundled libraries is the only solution that makes this mostly painless.
> It doesn't have to cost money. You can write a normal Windows app and run it under Proton. For end users, provided that they have Steam installed (it's free), they can just add "Non-Steam game" to the library - it's ~4 clicks.
I'm saying you don't need to publish on Steam to make your app run on Steam. You really don't. A user can add any executable to the Steam Library via the "Add a Game -> Add Non-Steam Game" button in the bottom-left corner of the GUI. It works 100% locally and with any kind of executable (not just games). It also bypasses any auto-updates. Finally, you can launch an app like that from the CLI or a desktop shortcut without opening Steam (well, it'll still run and update itself when needed, but you bypass the GUI).
> A user can add any executable to the Steam Library via the "Add a Game -> Add Non-Steam Game" button in the bottom-left corner of the GUI.
Yeah, but that's also not exactly a better user-experience for the end-user than "Download .exe, double-click to launch" or "Download .msi, finish install, run program".
Distribute your software however you want, I tend to try to make the download and install as familiar as possible to the users of the specific platforms.
Btw, even your starting prompt is guiding the model to just agree with your opening statement. You can't just roll with whatever the model says and assume the conclusion of "definitely can run in 10 years unchanged" is true.
Yeah, that's why the second prompt starts with "You misunderstood" and a correction. This is a long conversation, with multiple experiments performed and a lot of inspection of all the intermediate results on my end between prompts. You assuming otherwise without reading is a bit offensive.
To your point on installation: sure, but if you value it that much, just pay Valve to add you to the Steam store? And that would be the only possible solution given my constraints, all explicitly mentioned at least once in the linked conversation:
- binary produced today works
- without changes
- on both Linux and Windows
- is a GUI app
- has some dependencies
- is developed on Linux (no Windows needed)
For this set of constrains, Proton/Wine with a cross-compiled Win32 binary/bundle is literally the only solution (care to name another?)
For other constraints, it's a solution. Worth considering. That's all.
> You assuming otherwise without reading is a bit offensive.
Yeah sorry, hurling huge LLM conversations at me tends to make me skim them, hope you don't mind I didn't study the conversation you had with ChatGPT in detail.
That you considered someone skimming a chat log offensive yet the act of sharing those chat logs and expecting others to dredge through them, is almost offensive to me. So I guess we can call it even now.
> For this set of constrains, Proton/Wine with a cross-compiled Win32 binary/bundle is literally the only solution (care to name another?)
Cross-compiling the good old way, with a Linux VM, Windows VM and a macOS host (maybe Mac Mini?). I basically have the very same requirements (+ macOS), except zero third party dependencies, and end up doing it this way, all managed with Nix so basically all the installation-bloatyness is something I deal with so users get the exact same experience they expect on their OS.
Interesting to see Factor and J so far to the bottom and right in the zstd test, but much closer to the rest in the Pandoc test (with Asm taking their place). This suggests that both the task and language (not just the language) influence the efficiency.
I try to use LLMs for Kotlin, Python, Emacs Lisp, and Smalltalk (among many others, but these are what I have ongoing projects in). You'd think that Kotlin and Python would be much easier to generate than the other two, right? But that's not what I observed: Elisp is very close to Python in terms of how fast and how many tokens it takes to generate the code! The generated Elisp code is often better on the first try than generated Kotlin code for a comparable task.
Smalltalk is... complex. It's meant to be developed interactively in a running image, but running Codex on API pricing is too expensive, and Codex CLI cannot interact with the image without a lot of plumbing. I ended up building multiple tools that live in the image and a protocol for calling them, and a set of skills for using them - including code search, docs search, test runner, and script/string evaluator. I also defined a way of annotating types for method arguments and return values (without having a type checker), which helped a lot. Still, it's an uphill battle; I wouldn't go there on API pricing!
My takeaway is that it's not obvious which language fits the LLMs and a given task best.
It's not. The latest-and-greatest models on $200/mo subscriptions routinely produce bloated code full of boilerplate. They are incapable of producing elegant, concise, readable, correct-by-design code - they literally can't do it, even with the smallest samples, and it gets much worse as the scale of the implementation increases. You can't will the capability into them through prompts. You probably could do so with fine-tuning or other techniques, but I suspect that would just make the variance higher - and the average code quality would be much lower than it already is.
The code generated by LLMs is passable, but never truly good. The same is true for LLM-generated designs and architectures, just even more so. They are trained on all the code out there, and the percentage of really good code is so vanishingly small that it's incredibly hard to replicate even for humans after a lifetime of learning. LLMs would need to reach a next level of capability to consistently recognize good code. Generating it consistently is out of the question for at least the next few generations of the AI.
Not all code has to, or needs to, be good. LLM-generated code is useful and helpful. It's an incredible time-saver for one-off scripts, and you can make an LLM implement and maintain parts of the program you need, but don't care to make good at the moment. LLMs are very efficient (if we ignore externalities) and easy-to-use code generators, which is huge in itself. However, they are not great or even good at generating code.
Last weekend, there was a post showcasing a Rust library with utility functions for writing parsers. It featured a simple line-by-line INI file parser. I decided to rewrite it in Python with PyParsing, a library I happen to know well. GPT-5.6-Sol High wrote the grammar that worked. It was tragically bloated, poorly factored, and multiple grammar problems were masked by parse actions. It worked, but it was decidedly bad code. I then rewrote the grammar by hand, getting it down to 1/3 of the length, eliminating all parse actions, and improving error messages in the process. I then spent 2 hours trying to convince the model to perform the same refactorings I did, but had to give up: no matter what I tried, the model couldn't get all the needed changes to coexist at the same time. When it got the terseness right, it inevitably ruined error handling. When it got the grammar right, it ruined the factoring. And so on.
Later on, I decided to make the model rewrite the PyParsing grammar in Smalltalk's PetitParser - a pretty close match in terms of capabilities. I gave the model my version of the grammar. I told it to translate that Python code. It still butchered more than half of it, doing "optimizations" (the model's words) that replaced a cached production with a literal + 3 message sends in 8 places in the (trivial!) grammar. I explained what I value in the original code, why those are important features to keep, and tried again. It still couldn't give me an idiomatic Smalltalk translation, though it did get significantly closer. I concluded that the model has a very limited understanding of how concepts I wanted can manifest in actual code and called it a day.
To give you an idea of the scale: excluding blank lines and imports, the grammar is exactly 10 lines of Python...
So no - LLMs are not good at generating code. They are just fast and convenient, and again - that's huge. But it's nowhere near a level where it can be steered to produce good code - much less being able to generate good code by default.
(I realize this post is a bit off topic and it's just an anecdote - but I've experienced this daily for the past half a year; I'm not basing my opinion on just that last attempt.)
Yeah, definitely on point. I use AI for code generation, but I ride herd on it quite a lot and I limit scope viciously and with hard rules about what the models are even allowed to generate. It's worked out pretty well, but it's hardly the "oh send a question get a full system back" that people try to pretend it is.
It's not that bad... But it is bad. It looks cool, and I managed to read the first few paragraphs. But when the code scrolled into view, it stopped looking cool and became an eye-destroying disaster.
YMMV, but OP, if you read this, please consider disabling the text-shadow for code snippets... or disabling syntax highlighting in code snippets. These two things are not a good thing together.
> Side note: I expected to see mention of design by contract and function preconditions/invariants/postconditions.
For some reason, DbC seems to be virtually unknown to most programmers. It's incredibly strange: I was sure that DbC would be the next big step after gradual typing. It's just such a natural fit: where the type system gives up (any/dynamic), the contract system can step in. There are papers on automatically generating contracts from types (and vice versa) to allow typed values to flow through untyped code; there are papers showing how to make that performant enough; papers showing how to instrument systems to generate types and contracts from tests; etc. They are all 15-20 years old now, yet there's still nothing suggesting that the mainstream even looks that way, much less actually implements something usable.
The ones I most likely had in mind (recovered with help from ChatGPT due to my memory being fuzzy - but most links it produced were in my bookmarks):
- Matthias Felleisen, Sam Tobin-Hochstadt, “Interlanguage Migration: From Scripts to Programs” (DLS 2006)
- Sam Tobin-Hochstadt, Matthias Felleisen, “The Design and Implementation of Typed Scheme” (POPL 2008)
- Sam Tobin-Hochstadt, “Typed Scheme: From Scripts to Programs” (2010).
- Asumu Takikawa et al., “Gradual Typing for First-Class Classes” (OOPSLA 2012)
- Esteban Allende, Johan Fabry, Éric Tanter, “Cast Insertion Strategies for Gradually-Typed Objects” (DLS 2013)
- Esteban Allende, Johan Fabry, Ronald Garcia, Éric Tanter, “Confined Gradual Typing” (OOPSLA 2014).
- Nadia Polikarpova, Ilinca Ciupa, Bertrand Meyer, “A Comparative Study of Programmer-Written and Automatically Inferred Contracts” (ISSTA 2009).
There's a lot more research and literature on the topic. Naive approaches were tried ~2010 and were shown to be performance disasters, but by ~2015 we already had those issues mostly solved. I seriously thought that every new language (or new release of an existing PL) after that would feature first-class support for contracts and gradual typing, along with built-in support for automatically generating/harvesting types and contracts from tests. It's 2026, and the mainstream still doesn't seem aware of the possibilities, much less actively going in that direction. It's nuts!
The 1st, 4th and 7th papers look especially interesting.
I think in order to appreciate DbC (gradual typing is whole another beast altogether) one needs to have some idea of "Program Correctness" concepts in the lineage of Floyd/Hoare/Dijkstra and Meyer. With LLMs it is even more important to use the above as a "Correctness-by-Construction" (CbC) approach to code generation. To me this is the need of the hour and yet i don't see people talking about it;
> I think in order to appreciate DbC [...] one needs to have some idea of "Program Correctness" concepts in the lineage of Floyd/Hoare/Dijkstra and Meyer.
Agreed. To me, full-program (or system) formal verification is something I'd love to have, but I also acknowledge that even champions of formal methods (like Tony Hoare you mentioned) doubt its practicality, due to how large our software systems tend to be nowadays. If so, then let's take as much as we can from those methods (powerful, expressive type systems) and let's complement that with proper infrastructure for ensuring correctness (contracts, invariants, various kinds of automated tests) that are weaker, but much more applicable in practice.
Unfortunately, we're still stuck in a place where a plain `assert` - basically a "goto of ensuring correctness" - needs to be introduced to people with posts like the OP's...
> To me this is the need of the hour and yet i don't see people talking about it
Yes, I feel the same. I think the reason here is that we (programmers, collectively) didn't really take correctness of our programs seriously before, so there's just not much awareness about the research and work done in this problem space. Many people now are ready to admit that yes, we do need stronger, more comprehensive and better integrated tools for controlling, showing, and ensuring correctness - but the need for them arrived so quickly (and along with so many other, serious changes to the craft), that they simply haven't been able to catch up on the prior work fast enough. It'll probably take a few years, at least, for the urgent need for better tools to become widely recognized. It'll take even more time to get to usable implementations.
> (gradual typing is whole another beast altogether)
It's actually not. Contracts in Racket are duals of types (well, not fully, since you can put arbitrary code in a predicate and make that into a contract; however, that's more of an escape hatch than the default use of contracts in Racket). Typed Racket can wrap a typed value in a contract that guarantees that, when the value comes back, it exactly conforms to its type. This way, you can avoid expensive casts. Moreover, Typed Racket has refinement types (ie. that a given int will always be greater than 0), and these refinements have direct contract equivalents, too. So a Typed Racket value can be statically proven to have that property on the typed side, and then you don't have to check or prove it again when it comes back from the untyped world.
I believe this is an extremely neat capability that ties types and contracts together, opening some very interesting possibilities. Like, if a contract can be expressed as a refinement on a type, and we already have support for that in the type checker, we can automatically promote such contracts into types! That's huge, because if the contracted value never leaves a well-typed environment, we can eliminate all runtime checks without affecting correctness. It also addresses the most common problem with contracts (and assertions): runtime overhead.
I'm aware of all that because I decided to build an environment that would blend a fast, interactive development loop, an isolated environment in which agents can comfortably live, and an expansive toolkit for checking and ensuring correctness. I'm building it on top of Pharo Smalltalk, Glamorous Toolkit, and an extended Gradualtalk implementation that would also handle contracts. There are some problematic parts, but if I manage to achieve my goals in a Smalltalk image, I feel like it'll prove it can be achieved in literally every other environment, too :)
EDIT: "Types to contracts" is already presented in papers I referenced before (Typed Racket ones); forgot to mention the "contracts to types" (or rather, static verification of contracts) part: "Soft Contract Verification for Higher-Order Stateful Programs" and "Soft Contract Verification" by Phuc C. Nguyen et al.
I should have inferred that you were talking about Racket since some of the papers you had listed were Scheme related. Gradual Typing and similar powerful type systems are not available in the world of C/C++ where i come from (though modern C++ has a few simpler similar features). Hence my comment on that.
We already know from Curry-Howard isomorphism that "Predicates (i.e. Contracts) <-> Types". It is actually easier to first think of only predicates over the state space which can then be mapped into a type. Here you think of types as sets (as a first approximation) and predicates establishing a relation(a set of tuples) over a subset of their cartesian product. The logic is explicit with no unnecessary abstractions obscuring the concepts. This was Dijkstra's approach which is at the heart of CbC and important for us to understand.
If you straight away start with type systems with a "standard" programmer they are lost. The mistake we do is that we do not properly show the mapping of discrete mathematics onto the constructs of a programming language. With FP languages the problem is compounded since it is based on lambda calculus and so the idea of a type is even more generalized in a different dimension.
IMO, with LLMs generating gobs of code now, we need this in some form yesterday. CbC gives you one approach where the specifications are Predicates (invariants/contracts/etc.) which is successively refined to get the final program but preserving correctness at every step.
Your project sounds quite interesting; Good luck with that! You might want to write a paper/article on that for wider dissemination.
Asserts are a goto of ensuring correctness. Versatile, powerful, and incredibly easy to misuse.
Whatever correctness goal you're trying to achieve, there are safer, more ergonomic, and stronger alternatives you can reach for: type systems, contract systems, and even normal exception handling are often better. However, if you work in a domain where such tools can't be used or are not available, assert will still be there for you. It's worth knowing how to use it for that situation, but you should favor less ad hoc, more systematic features to ensure correctness in day-to-day programming.
I think of the Turing test as one of the starting lines, along with image recognition ("a summer break project for a group of grad students" resisted being solved for decades).
It is a huge leap. Now we can start talking about "intelligence" at all - we really couldn't before. That we're still hovering barely above the starting line is a separate matter (also worth noting, of course).
Given another commenter's mention of a similar project written in Nim that yielded a 1.6 MB binary, my first guess is that the 6 MB Zig binary simply isn't optimized for size - it might be a debug build. If not that, then I'm not sure what's happening, but yeah, in the context of Zig, 6mb for a CLI app is a bit strange.
reply