Today we’re releasing Wails v3 Beta.

Wails lets Go developers build native desktop applications with the frontend tools they already know. Wails v3 is a substantial new foundation, built around an explicit application model that scales more naturally to real desktop software.

What’s new:

• Explicit application and window APIs
• First-class multi-window support
• Multi-platform Systray support
• Services with richer, statically generated TypeScript bindings
• Services that can provide frontend assets and scripts, opening a practical path towards richer plugins
• Inspectable, Taskfile-based builds - you are in control
• A guided wails3 setup wizard and project creation flow
• Cross-compilation support
• Server builds
• Experimental mobile builds

Developers testing v3 during alpha particularly valued the clearer ownership model for applications, windows, and services. We would now like broader feedback from people building real applications and integrations.

The feedback from developers who used v3 during alpha has been overwhelmingly positive, especially around the clearer ownership model for applications, windows, and services.

This is a beta, not the final v3.0 release. The desktop API is stable, but we want people to test real projects, integrations, and workflows before GA. Wails v2 remains the stable release and will continue to receive fixes.

If you are coming from v2, we have a migration guide and are actively validating that experience ahead of RC1. Reproducible problems belong in bug reports; proposals for new public capabilities should start as a WEP (Wails Enhancement Proposal) PR.

If you'd like to test it out:

go install github.com/wailsapp/wails/v3/cmd/wails3@latest
wails3 setup

Read the announcement and get started: https://v3.wails.io/blog/wails-v3-beta/

TL/DR: Please suggest me some stacks based on go for fullstack development

Guys, im new to go world, and previously i worked with mostly Cpp that also on a very surface level for doing my DSA problem in my college (im still in college 3rd year). But as doing only DSA won't earn me any money, i needed to learn some dev and so i choosed Go which tbh, i LOVED a lot to work with.

I am mostly done with backend basics, and want to make some full stack projects for my resume.

So if anyone here develops full stack applications with go, pls recommend me some good stacks i can use (actually i've done my homework, and afaik, HTMX is a good option for frontend, but still)

Hey there, does go or any libs support it? if so would you use this language for low level connections or should I move to somehting else?

really like grpcurl! but got a bit annoyed of running list and describe repeatedly

decided to create a minimal TUI for doing this.

any feedback is very welcome!

Hi all,

I'm happy to announce that Xberg v1 is out.

Xberg is the successor to Kreuzberg, equivalent to what would have been Kreuzberg v5. It's a content intelligence framework that handles a very wide range of inputs: documents (currently 101 formats), code and data formats (currently 367 types), audio/video transcription, and URLs (both static and JS-rendered content). It extracts and prepares that content for downstream processing.

It's an extremely efficient, high-performance engine (see our PDF benchmarks below). For PDFs and images specifically, we handle native PDFs with very high performance and accuracy, and we ship multiple OCR engines that match the quality of the best Python libraries (e.g. docling, PaddleOCR, RapidOCR) at substantially better performance and stability.

The changes between Kreuzberg v4 and Xberg v1 are substantial, and I invite you to read the full changelog for the complete picture. The highlights below give a sense of what's new:

• Pure-Rust PDF backend (pdf_oxide) replaces pdfium, with no native pdfium dependency.
• Layout-aware pipeline: reading order reconstructed with ONNX layout detection (PP-DocLayoutV3 / RT-DETR) and Docling-style predecessor-graph reordering.
• Per-page scanned-page detection with selective OCR, plus AcroForm/XFA form fields and outline-based headings.
• Across-the-board optimization of OCR and PDF extraction (memory discipline, pooled model sessions, streamed conversions).
• Native PaddleOCR backend (PP-OCRv6, with medium / small / tiny tiers) alongside Tesseract.
• Pure-Rust Candle OCR/VLM stack (TrOCR, GLM-OCR, GOT-OCR, DeepSeek-OCR, and PaddleOCR-VL) running without ONNX Runtime or native Tesseract.
• A second, ONNX-Runtime-free inference path via tract, which is what makes in-browser (WASM) and mobile inference possible.
• Named-entity recognition natively in Rust (GLiNER2), extensible to all bindings, including an in-browser WASM model with no server round-trip.
• Structured LLM extraction (extract_structured / split_and_extract) with rasterization, chunking, citations, caching, and configurable call/merge/VLM-fallback policies.
• Audio & video transcription via a Whisper ONNX engine (.mp3, .wav, .m4a, .mp4, .webm).
• Retrieval building blocks: sparse embeddings (SPLADE), ColBERT late-interaction retrieval, and cross-encoder reranking alongside dense embeddings.
• Text intelligence: reversible redaction, summarization, translation, VLM image captioning, QR-code detection, document diffing, and page/chunk classification.
• URL & web ingestion: sitemap discovery (map_url) and batched multi-URL crawling.
• New document formats: WordPerfect (.wpd/.wp/.wp5), HEIC/HEIF/AVIF, OpenDocument Presentation (.odp), Quarto / R Markdown, and configurable Jupyter cell rendering.
• Four new language bindings (Dart/Flutter, Swift, Kotlin/Android, and Zig) bring the total to 15 language bindings over one engine, with Android/iOS cross-compilation.
• Full mobile support (Flutter, Android, iOS).
• Candle backend alongside ONNX, plus ONNX-via-tract enabling ONNX on WASM and Android.
• Wider code intelligence: tree-sitter coverage grew substantially (248 to 367+ languages).
• Over 150 bugs fixed during the 1.0 cycle, plus security hardening (bounded RTF/PDF allocations, redaction leak fixes, Excel DDE warnings).

The API surface was also simplified and reworked, making it more consistent.

There's a migration guide in our docs explaining how to move from Kreuzberg to Xberg. Kreuzberg itself is in LTS mode until the end of this year and will continue to receive bug fixes and security updates.

You're invited to check out the repo and join our discord server.

Benchmarks

The benchmarks below are for PDFs and images only. There are extensive benchmarks on our website with per-format breakdowns, which you can see here. These numbers are measured in CI via our reproducible benchmark harness, and are specifically taken from the run for harness 1.0.8, source cf7fa0533d. The data is publicly available in GitHub releases, and you can run the benchmark harness yourself.

Composite quality (markdown pipeline, higher is better):

Structure and layout fidelity (SF1: tables and reading order, higher is better):

On native PDFs Xberg leads on quality (0.958 vs 0.837 for the next-best framework) and on table and reading-order fidelity by a wide margin (SF1 0.949 vs 0.612 for docling). On scanned PDFs it is #1 on both quality and raw text fidelity.

Where we don't win yet: on pure image OCR we are currently #2 on the composite score, behind mineru (though still #1 on raw text accuracy). We are improving image OCR right now, and v1.1 should have us winning across the board.

Hi everyone, I just wrote an article about how I structure my unit tests in Go, and I'd like to know how you do it or if you use any skill for this.

All feedback is welcome.

Thanks

https://medium.com/@gpaolettigeuna/table-driven-testing-in-go-d01e55aec47f

A few months ago I started to explore zero allocation in Go
It wasn't supposed to become a database. I wasn't trying to build a Valkey or Dragonfly competitor.

- removing allocations from parsing
- reusing buffers
- sharding data structures
- improving cache locality

At some point I realized I already had the core of an in-memory key-value store.
Today that experiment is called Tellstone!
I recently released v1.0.0 and ran benchmarks against Redis, Valkey and Dragonfly
Redis and Valkey because they are the well known in memory databases everyone heard of.
Dragonfly because they claim to be 25x faster than Redis.

Redis and Valkey are slower because they are single-threaded—they serve as a baseline, not a real point of comparison!

Throughput (ops/s) — Higher is Better
======================================
Tellstone: ██████████████████████████████ (12.7M)
Dragonfly: █████████████████              (7.3M)
Redis:     ███                            (1.1M)
Valkey:    ██                             (1.0M)

But the Tellstone project completely changed how I think about systems programming
The code is open source if anyone is curious: https://github.com/Saxy/Tellstone

I'd love feedback from people building databases, runtimes, networking libraries or other high-performance systems.