net.http now speaks pooled, multiplexed HTTP/2 by default — across mbedTLS, OpenSSL, and native Windows (SChannel). Just call http.fetch() / http.get() like normal: V negotiates h2 via ALPN, reuses connections transparently, and falls back to HTTP/1.1 automatically for origins that don't support it. No config needed (enable_http2: false if you ever want the old one-shot behavior).

The server side is fully RFC 9113 / 7541-conformant — 146/146 h2spec cases passing.

Landed across #27412, #27413, #27643, and #27712 (the Windows piece). Thanks to everyone who reviewed along the way — go build something with it! 🚀

Inspired by Clay, a cross-platform GUI library for the V language. Fast layout algorithm that makes flex-box style layouts simpler. No worrying about: data binding, observables, UI thread synchronization, wiring, callbacks, or threading headaches. View is a function of your state; change the state anywhere and the UI updates.

Special thanks to: Mike Ward

Cross-platform GUI library for the V language. Inspired by the syntax of Java's Swing/FX & Fluent/WinUI3 Style.

Rather than treating V (Vlang) as a list of syntax rules, this guide (and tutorial) emphasizes a practical path: learn the core ideas, run the examples, and build small projects as you go.

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 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.

When you capture your screen, subtle traces are left in the file that can reveal what device, operating system, or display configuration. This tool uses FFmpeg to neutralize those traces.

It turns out that V (Vlang) is a unique choice for systems programming – it is simple to learn while remaining fast enough for system-level tasks.

When I consider the fact that many IT companies are primarily hiring developers for C#, Java, and JavaScript, while the demand for Go or Rust developers is significantly lower, it suggests one thing: a large part of the corporate world still relies heavily on established technologies and operating systems like Windows.

Here, we run into another interesting observation: many corporations build monolithic applications that they deploy to Azure and various containers (Docker). These then communicate via Kubernetes to maintain their ecosystem. Consequently, corporations spend huge amounts of money on cloud operations, keeping "heavy," not necessarily systems-oriented languages like C#, Java, and JavaScript, running.

Why is this the case? From a company's perspective, it is simply difficult to find someone who understands systems architecture and can program in it; a developer must understand hardware principles for the application to function efficiently.

This is where Go comes in—it is easy to learn and can be used to write system utilities. However, a problem arises here: Go is primarily optimized for backend requests, but it isn't ideal for system applications where there is a strong emphasis on minimal binary size. For that, we have Rust, which is safe but very difficult to learn. For many, Rust is so complex that even programming in C and C++ seems more accessible.

We find ourselves in a vicious cycle. Companies won't use C because it is prone to memory errors and it is hard to find experts who truly understand it. So, they prefer to hire developers who know C# or Java, where there is a massive ecosystem and where one simply "glues" code together for monolithic applications, for which corporations then pay significant cloud costs.

I used to wonder if there was even a language that could be fast to compile, produce small binaries, be easy to learn, and minimize the room for error. For production use in companies, such a language was essentially missing.

And that is where Vlang comes in. It meets all the requirements to become a low-maintenance tool for systems developers, ideal for creating fast and small system tools, or even backends. This changes the perspective on where the language is heading. I finally understand why Vlang is trying to build a large ecosystem of modules that can be easily integrated into one's own projects.

Vlang is a systems language that is easy to learn and creates binaries that can be incredibly performant. I have personal experience with this—as an experiment, I created an SSG program called Mustela, which really surprised me in this regard. It has a 1.3 MB binary and can be integrated with various other applications, thereby fulfilling the Linux philosophy.

However, when I try to promote the benefits of this language to corporations, I run into the fact that they often don't understand Linux principles and prefer to stick with languages that are cumbersome but, at first glance, "safer" for typical DevOps staff. It is such a vicious cycle that I find myself thinking that in 2026, we are not yet technologically mature enough to build programming on simplicity; it is all still in the building phase.

Small lowfi CLI music player program

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.

Fetch and cache RFCs, resolve cross-references and errata, look up IANA codes, track Internet-Drafts, search the Datatracker, and more from the command line.

Quick context up front: I have ALS and can't use keyboard anymore, so I use AI to help me write and move the code along. The design and the live testing are mine.

I posted vebidor 5.0 (native iOS/Android automation in V, no Appium/Node), and someone in the thread made a point that stuck: the comparison docs dismissed codegen as "low automation value," and that was wrong — the real time-sink in writing tests isn't watching a trace afterward, it's the write-a-locator → run → fix → rewrite-after-every-refactor loop. Codegen is in the hot path of actually authoring a suite; a trace viewer is just a debugging nicety.

They were right. So 5.1.0 is the codegen / session recorder.

What it does: record a live session and it emits runnable vebidor V source. The key design choice is that generated locators go through the same semantic get_by_* engines you'd hand-write — get_by_role, get_by_label, get_by_test_id — verified unique at capture time, with a CSS/xpath fallback only when nothing semantic is unique. So the output is the refactor-resistant shape, not a brittle div:nth-child(3) chain that breaks on the next reorg.

Web (over WebDriver-BiDi): an in-page recorder watches your clicks/inputs/Enter, synthesizes the selector, and streams actions back. Verified on Edge with a full capture → emit → compile → replay round-trip — the generated program re-runs and every recorded locator resolves.

v run tools/codegen.v web https://example.com --out flow.v
# click around; Alt+click to record an assertion; press Enter to finish

Native mobile is the part I'm happiest with, because there's no preload-script trick available — native apps can't take injected JS. So:

• Android is passive: it streams adb shell getevent, scales raw touch coordinates to screen pixels, and on each tap snapshots the UiAutomator2 accessibility tree (page_source), hit-tests the smallest node containing the point, and synthesizes a cross-platform selector. Verified live on an emulator (Pixel AVD, API 34) — an on-device round-trip re-resolved 5/5 generated selectors against the live tree.
• iOS has no passive touch stream over XCUITest, so it's an honest assisted REPL (tap x y / text … / assert x y / done) rather than pretending to capture taps. Offline-tested; not yet run on a physical device — calling that out rather than overclaiming.

One action model + emitters feed both front-ends, so the same recording machinery targets vebidor.webdriver and vebidor.mobile.

Standards-based the whole way down — no CDP-only tricks, no Node. Install with v install vebidor.

Happy to talk about the gnarly bits — the getevent coordinate scaling, or synthesizing selectors from the accessibility tree so they survive refactors.

Modern V seems to have found a reasonable niche as something like a Crystal style language for people who prefer Go like ergonomics. I’m asking this with the understanding that there have been claims of people being banned for dissent or criticism.

I’m not arguing that no one should use V, nor am I saying it has no value simply because it overlaps with languages like Crystal, Nim, or Go. My question is more about why disputes over the language’s novelty and breadth of claims seem to become such a problem, especially now that V appears to have found its own practical space. Why be defensive at this point?

I've been building vebidor, a browser/mobile automation library written entirely in V — think Selenium/Playwright/Appium, but as a native V module with no Node runtime and no bundled browser. v5.0.0 just added native mobile, so it now covers web and real-device automation from one API.

What it does

• Web (W3C WebDriver Classic) — 100% Selenium feature parity, drives Edge/Chrome/Firefox/Safari.
• Playwright-style ergonomics — lazy auto-waiting Locators, get_by_role/text/label/... selectors, web-first retrying assertions, one-call launch().
• WebDriver-BiDi (the W3C bidirectional protocol over WebSocket) — network interception/mocking, HTTP auth, console/network events, isolated contexts, preload scripts, tracing.
• Native mobile (new in v5.0.0) — vebidor.mobile drives WebDriverAgent (iOS) and the UiAutomator2 server (Android) directly over their HTTP sockets. Same backends Appium uses, minus the Node middleware. Cross-platform get_by_*, gestures, app lifecycle, device state.

​

import vebidor.webdriver


fn main() {
    mut b := webdriver.launch_edge(webdriver.LaunchOptions{ headless: true })!
    defer { b.close() }
    b.goto('https://example.com')!
    webdriver.expect(b.wd.get_by_role('heading', ''))!.to_be_visible()!
}

import vebidor.mobile


fn main() {
    mut s := mobile.launch_ios(mobile.IOSOptions{ mode: .simulator, udid: '...', wda_xctestrun: '...' })!
    defer { s.close() }
    s.get_by_label('General').tap()!
    mobile.expect(s.get_by_text('About')).to_be_visible()!
}

Why it exists

It's the only real automation option in V, and it's standards-based all the way down — W3C WebDriver + W3C BiDi for the web, and the public on-device servers for mobile. No Chromium-only CDP lock-in, no proprietary wire. Compiles to a native binary.

Honest about limitations

• No binary trace viewer / video / codegen like Playwright (there's a JSON tracer).
• No hybrid-app webview driving yet on mobile (Appium still wins there).
• iOS real-device work needs a macOS host (code signing). Android works anywhere adb does.
• BiDi can't dispatch real touch events — that's a protocol gap, not an impl gap.

Links

• Repo: https://github.com/quaesitor-scientiam/vebidor
• Docs + landing page: https://quaesitor-scientiam.github.io/vebidor/
• Four-way comparison vs Selenium / Playwright / Appium: COMPARISON.md in the repo

Built and verified live (headless Edge for web; iOS Simulator + Android Emulator for mobile). Feedback and issues very welcome — especially from anyone using V for scraping or end-to-end testing.

sonic inspired json encoding/decoding that utilizes V compile-time ability

https://github.com/magicfun1241/fastjson

Vebidor is a native V implementation of the W3C WebDriver protocol — and as of v4.2.0 it also speaks WebDriver-BiDi and ships a Playwright-style API with Mobile emulation on top. No Node runtime, no bundled Chromium, no bindings to another language — it compiles to a single native binary and talks to any conformant driver (Edge, Chrome, Firefox, Safari).

What's new in 4.2.0:

Playwright-style ergonomics
Playwright's "mobile" is device emulation (device descriptors: viewport, UA, device-scale-factor, isMobile, hasTouch, touch input) — not real-device automation (that's Appium). Vebidor is matching the emulation side over BiDi. Fidelity is best on Chromium-based drivers (Edge/Chrome); each emulation.* call is gated by supports().

WebDriver-BiDi (bidirectional, over WebSocket) — coexists with the classic session:
- Network interception & mocking (route / fulfill / abort), response-phase interception, and HTTP auth.,
- Console + network event listeners, wait_for_event, cookie-change events.,
- Isolated user contexts, preload scripts (addInitScript-style), viewport emulation, file upload, screenshots/PDF, and a lightweight tracer.,

Still 100% feature parity with Selenium's classic WebDriver surface. Every feature above was verified live against headless Edge.

Vebidor v4.0.0 — a Playwright-style browser automation library, written in pure V

Vebidor is a native V implementation of the W3C WebDriver protocol — and as of v4.0.0 it also speaks WebDriver-BiDi and ships a Playwright-style API on top. No Node runtime, no bundled Chromium, no bindings to another language — it compiles to a single native binary and talks to any conformant driver (Edge, Chrome, Firefox, Safari).

Playwright-style ergonomics

• One-call launch() — auto-detects the driver + browser, picks a free port, tears everything down on close. No more "start chromedriver on 9515."

• Lazy, auto-waiting Locators that re-resolve on every use (immune to stale elements): get_by_role, get_by_text, get_by_label, get_by_placeholder, get_by_test_id.

• Web-first assertions that poll until they pass: expect(loc).to_be_visible(), .to_have_text(), etc., with .not() and .with_timeout().

WebDriver-BiDi (bidirectional, over WebSocket) — coexists with the classic session:

• Network interception & mocking (route / fulfill / abort), response-phase interception, and HTTP auth.

• Console + network **event listeners**, `wait_for_event`, cookie-change events.

• Isolated user contexts, preload scripts (addInitScript-style), viewport emulation, file upload, screenshots/PDF, and a lightweight tracer.

Still 100% feature parity with Selenium's classic WebDriver surface. Every feature above was verified live against headless Edge.

```v

import vebidor.webdriver

fn main() {

mut b := webdriver.launch_edge(webdriver.LaunchOptions{ headless: true, bidi: true })!

defer { b.close() }

mut bidi := b.bidi()!

bidi.route(fn (req webdriver.InterceptedRequest) {

if req.url.contains('/api') {

req.fulfill(200, 'application/json', '{"mocked":true}') or {}

} else {

req.continue_request() or {}

}

})!

b.goto('https://example.com')!

b.wd.get_by_role('link', '').click()!

webdriver.expect(b.wd.get_by_role('heading', '')).to_be_visible()!

}

```

Feedback and contributions welcome — especially testing across Chrome/Firefox/Safari on other platforms.

Version 3.1.1 | 🎉 100% Feature Parity with Selenium 🎉 | Production Ready

🚀 Features

✅ Fully Implemented (100% Coverage) 🎉

Core Features:

• Session Management - Create, manage, and quit browser sessions
• Navigation - Navigate, back, forward, refresh
• Element Location - Find elements by CSS selector, XPath, ID, class name, tag name, link text
• Element Interaction - Click, send keys, clear, submit forms ✅ 100% Complete
• JavaScript Execution - Execute synchronous and asynchronous scripts ✅ 100% Complete
• Cookies - Get, add, delete, clear all cookies
• Screenshots - Capture page and element screenshots (base64)
• Frame Switching - Switch between frames, iframes, and parent frame
• Actions API - Complete keyboard, mouse, wheel, drag-and-drop ✅ 100% Complete

Vebidor Github link

Package for type safe list of allowed MIME, that was used to return "Content-Type" header on router. Has many other use cases: file extensions from MIME type, get MIME text representation, MIME type from file extension, MIME type from text representation, etc...

I’m excited to announce that Mustela, a tiny but predatory static site generator, is officially stable (v1.0.0)! 🦦

The Stats:

• Language: 100% V (standard library only, zero 3rd party dependencies).
• Performance: Generates ~9,000 pages per second.
• Efficiency: Build time 37ms, RAM usage ~4.8 MB.
• Architecture: Linux amd64 (single statically linked binary).

The Journey:

I’ve been working on this ecosystem for exactly 2 months and 10 days. It was a brutal sprint where I built:

1. Mustela CLI (The engine).
2. The Documentation (Complete guide).
3. Mustela Web (Landing page, Docs, and Blog).
4. Forensic Analysis Project (A complex real-world use case).

It’s been an intense ride (my head is spinning!), but it’s the ultimate proof that V is not a toy. It’s a powerful tool for building fast, robust, and reliable applications with ease.

I’ve decided to keep the CLI source code private as my intellectual property (I built everything from scratch), but the Mustela Web is Open Source (link in footer).

Special thanks to Alexander (the creator of V) for his support and for sharing my progress on X. V allowed me to write this entire ecosystem comfortably and at lightning speed.

Try it yourself:

Download the binary and see how fast it builds the docs:

👉 Get Started with Mustela

I’m curious: How many milliseconds does it take to build on your machine? :)

🎥 See it in action:

If you want to see how Mustela installs and compiles a live Vite/JS project on ChromeOS Flex before trying it yourself, I recorded a quick 5-minute walkthrough video here: Mustela SSG Demo: 1.3MB High-Speed Vlang Engine with Parallel Pipeline (Youtube)

PS: English is not my native language, so I used a translator to make this post clearer. I hope the technical parts still make sense!

I’ve been building a project called vphpx, with vphp as the core layer.

The idea is to use V not just for CLI tools or services, but for PHP-native infrastructure:

• bridging V with Zend/PHP values
• exposing native PHP-facing APIs and objects
• building higher-level application/runtime layers on top

The project currently includes:

• vphp: V <-> Zend interop
• vphptest: regression and runtime validation
• VSlim: routes, container, middleware, CLI, views, and PSR-style HTTP types

Why I wanted to build this:

• I wanted to test V in a systems-integration role, not only as an app language.
• I wanted to see if V can make extension/runtime codebases easier to grow than straight C.
• I wanted to push beyond “bindings” and into a fuller PHP-facing stack.

So this is less about making “yet another web framework”, and more about exploring whether V can serve as an implementation language for native PHP infrastructure.

That’s the main reason I made it: I wanted to see how far this approach could go once you move from single exported functions to objects, routing, middleware, PSR-style HTTP types, and a framework-like application surface.

Hi everyone,

I wanted to share a project I’ve been building with V. It’s called Mustela, a static site generator designed for developers who are tired of "bloated" tools and slow build times.

The Problem:

Most modern SSGs feel like a black box. They clone data, rely on heavy garbage collection, and slow down significantly as your project grows.

The Solution (Mustela’s Architecture):

I approached Mustela not as a typical app, but as a high-speed data pipeline.

• Zero-Copy Architecture: Data moves through the system via pointer passing. No redundant memory allocations.
• Stateful DSL Engine: Instead of spinning up a new environment for every file, Mustela uses "State Recycling." The Lexer and Parser are allocated once on the heap, and their internal state is simply reset between files.
• Unix-First: It leverages native inotify for zero-latency filesystem monitoring.

Performance (The 5,000 Page Challenge):

On an average i5 machine, Mustela builds 5,000 Markdown files in 528 ms (~9,470 pages/sec) with a peak RAM usage of only 34.6 MB.

Real-world Dev Experience:

I’ve integrated Mustela with Bun and Vite for the ultimate dev stack. It’s so fast that it outruns the tooling:

12:57:05 PM [mustela] UPDATE | ./theme/default/document.mu
12:57:05 PM [mustela] BUILD  | 6 files processed in 26 ms (26638 µs)
# Vite is still refreshing while Mustela is already done.

Dogfooding & Open Source:

The documentation website is built entirely with Mustela. Please note that the content is still a work in progress as I’m writing the final CLI and Workspace tutorials. To show you how the engine handles real-world templates and the "Sandwich" pattern (mixing MD with HTML blocks), I’ve made the documentation repository public:

• Hub Site: Mustela Hub
• Codeberg (Docs Source): Mustela Web Codeberg

Status:

The engine is currently in the "final polishing" stage. I’m tuning the CLI and finalizing the Vite/Bun workspace templates. I plan to release the first stable, 400KB statically linked binary by the end of this month.

I'd love to hear your thoughts on this "linear pipeline" approach or answer any questions about the V implementation!

PS: English is not my native language, so I used a translator to make this post clearer. I hope the technical parts still make sense!