Rust: the language things get rewritten in
Rust is slowly but inexorably refactoring humanity's codebase.
About 5 years ago, I was going through Rust documentation and decided that I didn't like Rust [ru].
Last year, I needed to prototype some game logic and chose Rust for that task, as I couldn't find anything better: Zig looked too immature, and C++ is getting more and more dead complicated with every standard.
As a result, I wrote 10 pages of notes on my experience, which unexpectedly boiled down to a compact statement in the title. And if you are too lazy to read further, then this is praise, not criticism.
However, I still stick to my opinion from the previous post:
A good tool shouldn't constrain its user, because the tool's developer can never anticipate every possible use case.
According to my understanding of beauty of how technology works, a programming language built on Rust's principles should have a near-zero chance of success. However, the de facto situation is exactly the opposite: Rust is rapidly gaining popularity, and after working with it, I have to admit it's a good and powerful tool. But good grief, it's just wrong. Who does things this way?
From my point of view, Rust's success is caused by two factors:
- The tremendous professionalism and experience of its creators and core team.
- The maturity of the software development industry.
I'll try to concisely describe the primary conceptual difference between Rust and other languages; why that difference is both its strength and its weakness; and why, for several years now, there has been an ongoing trend of rewriting everything in Rust.
This post is based on strictly subjective experience
I used Rust for only a year; for prototyping and experimentation; in game development.
Consequently, I'm not in a position to claim expertise in Rust or an unbiased view of it.
For example, some of the difficulties I experienced may have been due to the fact that I was simultaneously prototyping and learning the language. That is, they may have been a consequence of my choice, rather than properties of the language.
At the same time, I have enough development experience to extrapolate from that year to more general cases and form my own subjective opinion on the matter. That is what I will do in this essay.
Want to build a startup together? I could be the right fit
Life is like a hurricane here in Ham-burg…
As you may know, I'm finishing my professional sabbatical. It is still unclear what I'll be doing next, however I've gathered a list of potential projects that are very interesting to me. I'm ready to discuss partnership around those projects right now.
If you're an early-stage startup or are only just about to create one, I would fit well into the role of CTO / technical Co-Founder (I can also take on management and product work). If you're a more mature company starting a new project, I can lead it under whatever title you find appropriate.
If you follow my blog, you probably already have some idea of who I am. But just in case, here is my CV. I have 19 years of experience in software development: from gamedev in C++ to payment backends in Python, from garage-style indie development to large projects.
For convenience, I've split the kinds of projects that interest me into several groups:
- LLM shovels and shovels for LLMs.
- Virtual characters, virtual influencers.
- Gamedev.
Notes on coding agents
Agents coding something (c) ChatGPT
When I was summarizing the last year, I said that agents will be the main topic of 2026. For the last three months, I have been gradually figuring out how to use them for development, and now we can discuss the intermediate results.
Formally speaking, coding agents are a subset of AI agents, but for simplicity, these terms will be used as synonyms in this text.
How I used agents:
- I refactored and wrote some code in Rust for an experimental game logic engine.
- I used agents for the standard development tasks while working on Feeds Fun (Python/TypeScript).
- Like a true hacker, I decided that if I wanted to understand agents, I had to code something related to them. So over the course of a month, I vibecoded Donna — a planner for agents (Python).
Since agents are a new thing:
- No one knows how to use them — we are in the process of gaining experience and gathering use cases.
- No one has broad experience using them — either you choose one or two approaches and use them to do your work, or you endlessly experiment without creating value.
Thus, this post will be in the form of subjective notes and theses.
Vantage on management: Scientific practices for engineering — public artifacts
An engineer demonstrates their work to the community (c) ChatGPT, Leonardo da Vinci
- Points of view on a product
- Hypothesis testing loop
- What to read, when, and why
- No instructions for engineering
- Engineering is science is engineering
- Scientific practices for engineering — public artifacts
In the previous essay, we discussed how engineering and science are closely related, and therefore can borrow practices from each other.
Let's talk about those practices. Since I'm interested in the engineering side of things, we'll discuss practices that engineering can borrow from science.
Here and throughout this essay, by engineering I mean software engineering (IT). I'm confident that the ideas discussed here apply to engineering as a whole, but that field is vast and extraordinarily diverse. The blog format and my innate modesty doesn't really allow me to make such ambitious claims.
This essay is the first of several planned texts about practices. It focuses on the practice of creating publicly accessible artifacts (such as scientific papers and open-source software), the strength this practice gives science, and the potential gains engineering could make by adopting a similar model.
By "public" in this text, I mean global access — the artifact is world-readable to anyone who might be interested. This does not necessarily imply an open license (e.g., open-source licensing), however, open-sourcing is often a natural choice for public artifacts, it is simplifying things a lot.
We'll discuss the following topics:
- what a public artifact is;
- artifact verifiability;
- public artifacts as evidence of competence;
- public artifacts as a criterion for qualification;
- public artifacts as an axis of employee evaluation;
- public artifacts as health metrics;
- difficulties of shifting development toward public artifacts;
- how to start.
This text is not a recommendation, but an invitation to discussion. It is full of idealism and controversial statements. I hope for your understanding and comments.
LLMs think breadth-first, humans think depth-first
I've formulated my main conceptual issue with LLMs at this point, based on my personal experience.
The problem is less noticeable in chats — it gets smoothed out by the continuous interaction with a human who steers and corrects the LLM.
However, it becomes much more noticeable during vibe coding, or when you ask an LLM something that calls for a large abstract answer.