There's a petition circulating right now demanding that Open-Source contributions be formally recognized as volunteering for the common good.

I read more about it via Inkscape (the open-source graphics editor), as they just published an article supporting it: https://inkscape.org/pt-br/news/2026/05/13/inkscape-supports-german-petition-to-recognize-ope/

After reading it, I didn't hesitate. I checked out the petition and saw it's focused on Germany, where this issue is currently being actively discussed by politicians. I signed it and left a comment with my thoughts. The link is here: openpetition.org/!sywhp

I believe that if the petition spreads enough (there are only 4 months left to sign), it will spark a much bigger conversation. If Germany actually pushes this through, it could set a precedent for other countries, including the Czech Republic, where I'm based.

A huge part of the Vlang community is deeply involved in open-source, and we have many engineers here building truly sustainable, resource-efficient programs. The fact that the V language itself is such an amazing open-source project perfectly aligns with the goal of saving hardware resources and writing efficient code.

There's a petition circulating right now demanding that Open-Source contributions be formally recognized as volunteering for the common good.

I read more about it via Inkscape (the open-source graphics editor), as they just published an article supporting it: https://inkscape.org/pt-br/news/2026/05/13/inkscape-supports-german-petition-to-recognize-ope/

After reading it, I didn't hesitate. I checked out the petition and saw it's focused on Germany, where this issue is currently being actively discussed by politicians. I signed it and left a comment with my thoughts. The link is here: openpetition.org/!sywhp

I believe that if the petition spreads enough (there are only 4 months left to sign), it will spark a much bigger conversation. If Germany actually pushes this through, it could set a precedent for other countries, including the Czech Republic, where I'm based.

A huge part of the Vlang community is deeply involved in open-source, and we have many engineers here building truly sustainable, resource-efficient programs. The fact that the V language itself is such an amazing open-source project perfectly aligns with the goal of saving hardware resources and writing efficient code.

Summer is finally here, and with it comes some serious heat, so while sitting at my laptop, I decided on a whim to search for “Vlang” on YouTube. To my surprise, a new video popped up—just a few days old—from the channel The Flourishing. The creator went to great lengths to gather a lot of information that nicely ties together the history of this language.

In the video, the author references an interview with Alex Medvednikov, which I had to click on right away. And there I was, watching with my mouth agape—he speaks Russian!

Suddenly, it all clicked. The founder of V is originally from Russia, even though he now lives in the Netherlands. That explains the name Medvednikov. It’s a fascinating discovery, because he speaks Russian absolutely fluently, naturally, and with tremendous command. From what I’ve seen in his English videos, he speaks more slowly and comes across a bit differently—now I realize that English simply isn’t his native language.

You know what’s a shame, though? That he doesn’t make more videos about his language V, in Russian. I’d love to watch those—I’d happily turn on the subtitles and learn directly from him, instead of just wading through articles and source code. :D

What do you think about this? Do you follow language creators in their native languages, or do you prefer sources that are entirely in English?

I’ve been working on a WASM-based game engine project lately, and it led me to some interesting observations regarding V and Odin.

When I started, I tried to implement the core engine in V, but I constantly hit roadblocks with WASM compilation. It felt like fighting the compiler rather than writing code. I decided to switch to Odin for this specific purpose, and the difference in how they handle memory is night and day.

In Odin, memory management for JS/WASM buffer optimization is incredibly transparent. I can access bits directly, calculate addresses, and extract data with zero friction. It’s the cleanest approach for performance-critical code. In contrast, V often hides memory management, which is great for business logic, but it makes low-level optimization cumbersome. While you can use unsafe blocks in V, I ran into issues where I could successfully optimize a block, but the test suite would fail, even though the actual runtime initialization worked fine.

To me, this highlights a core difference: V’s transpilation model creates a "black box" that requires you to be an expert in the generated C code. It’s a great tool, but when you need that "honest" engineering control, the friction is real. Odin doesn't use a C transpiler in the same way, allowing that level of control from the start.

However, this led me to an interesting observation about the two communities:

• Vlang tends to attract people focused on building maintainable, large-scale architectures. It forces you to adopt design patterns, interfaces, and polymorphism. It’s perfect for business logic, where readability for the team is the priority.
• Odin attracts "tinkerers" and game dev enthusiasts. They are incredibly creative and obsessed with performance, but often lack the engineering discipline for long-term maintainability. This frequently leads to "spaghetti code" in the pursuit of quick results.

Here is how I see the trade-off:

In short, V is built for teams and large, readable architectures. Odin is a playground for solo masters who want absolute control. The problem arises when Odin projects grow—without strict engineering discipline, the lack of standardized patterns makes the code extremely hard to document and explain to others in a team setting.

It’s fascinating to see how the language itself shapes the culture. If you’re choosing a language, don't just look for "the fastest one"—look for the one that actually solves your specific development problem.

I have decided to release Mustela as open-source on GitHub.

Why did I decide to do this? I’ve been looking through many projects in V, and I’ve noticed that many developers lack a deeper understanding of how to architect complex CLI tools or game engines—even though V is perfectly suited for these tasks.

I felt it was time to show others how to build an engine that functions as a platform, applicable to various fields—from game engines to robust backends or CLI applications. Furthermore, you can take a look at how I implemented my own DSL, so I believe there is a lot to learn from the codebase.

To help you fully grasp the concept of the Mustela project, I have included several engineering insights in the README to help you better understand my architecture.

I am very grateful to everyone who has shown interest in Mustela. This project is primarily intended for those of you who want to become engineers and build robust applications.

Good luck exploring the code, and I hope it helps you build something even greater than Mustela itself.

It’s been several years since I started programming. For the most part, I’ve worked with interpreted languages. At first glance, this approach seems simpler, but it comes with a hidden tax: high startup times and unnecessarily high demands on system resources.

For years, I developed robust applications, studying various architectures and complex directory structures. But I always hit the same wall: the larger the project, the more lost I felt. The constant searching for files and navigating a labyrinth of code was a clear sign of cognitive overload. I often ended up essentially programming an "operating system simulation" inside a single program, where every module had its own little world managed by the language's garbage collector.

The Path to the Linux Philosophy

Eventually, I decided on a radical change. I chose to stick to the classic Linux philosophy: create a small, extremely fast program that does one thing and does it damn well.

So, I built an SSG (Static Site Generator) — and I made it "dumb" on purpose. When I later needed a hot-reload feature, I didn't try to shove a WebSocket server and other bloat into it. I simply created a second, equally "dumb" program that handles exclusively the server-side logic and event processing. Nothing more, nothing less.

Emergent Stability

Linux is perfectly designed for this approach. Most of the time, you are working with pipes or FIFO files. These are just lightning-fast conduits for passing values between processes. Linux is already an operating system that effectively balances CPU loads and handles memory management — so why bother struggling with complex asynchronous logic inside your application when the OS can handle it for you?

This approach brings incredible stability: if your WebSocket server crashes, your SSG tool keeps running peacefully. Everything is safe, isolated, and behaves emergently.

Building Blocks, Not Black Boxes

I discovered that this approach is extremely easy to maintain. Programs stop growing uncontrollably. Instead of the source code of one giant entity expanding, the system naturally breaks down into smaller, easily understandable parts.

Many people aren't even aware of this potential. They build one monolith that "does everything." Such a program soon becomes a black box that no one else can navigate. Once you run into a bug, you’re dependent on the author releasing an update.

With small, modular programs, it’s different. They are like building blocks that communicate with each other through the native mechanisms of Linux. It is a kind of freedom that a monolith will never give you.

>I’m curious how you handle project complexity. Do you prefer the 'one tool, one job' approach, or do you lean more towards comprehensive, integrated systems? Let's discuss.

A while ago, I mentioned that my content engine, Mustela, would remain a closed-source project. I’ve changed my mind, and I’m now considering releasing it as open-source.

What makes Mustela different from standard SSGs (like Hugo) is how it handles the lifecycle. Most tools are batch processors – they start, rebuild everything, and exit. When they have a "watch mode," they usually just trigger a full process restart upon file change.

Mustela acts as a resident engine. I’ve implemented a lifecycle management system (Init, Boot, Free phases) using strict Interface Segregation (ISP). This allows me to perform partial hot-reloading: I can re-initialize the config or theme modules while the engine is running, without restarting the whole process.

I've noticed many popular tools skip this level of architectural granularity, leading to massive build-time latency.

My questions for the community:

1. Would you be interested in an "engine-first" approach where the lifecycle is exposed through contracts?
2. Should I include my architectural write-ups (on why I moved away from "batch" processing) along with the code? Or is the code enough?

Looking for some feedback on whether this kind of architectural "over-engineering" (for the sake of performance) is something you find valuable in a V project.