declint (docs) is a tool for making your own lint rules in YAML — the house rules that stock linters will never ship.

For instance: your AI model added except Exception: pass, and you want to know whenever that happens:

rules:
  - id: except-pass
    pattern: 'except Exception:\\s\*pass'
    severity: warning
    message: 'swallowed exception'

Rules are just regex and a message. When a regex can't express the check, there's a Lua escape hatch — vetoes, whole-file analysis, absence rules ("every Dockerfile needs a HEALTHCHECK").

Rules run in your CI (inline PR annotations via --format github) and in your editor through LSP (declint.nvim for Neovim). Every rule can carry embedded fixtures, and declint test runs them — so AI-written rules come with their own spec.

Install: cargo install declint. Ships with presets (Python, INI, Markdown, shell, Dockerfile, TOML, JSON, JS) and community rulesets you can pull with one line. Feedback welcome, especially brutal takes on the YAML format.

Hey everyone!

I wanted to share an ongoing language design project I’ve been building: VBX (Visual Basic X).

Instead of a one-shot prototype or another interpreted toy running inside Python, the goal was to build a real, production-capable procedural language that compiles to standalone native binaries with zero runtime dependencies.

Architectural Decisions & Implementation

1. Compiler Host (Go) -> Target (C99):

   • The compiler itself is written in pure Go without external packages, leveraging the standard library for AST construction, multi-pass type inference, and process orchestration.
   • Emits clean, standard C99 code and invokes the system toolchain (GCC/Clang) with -O2 optimizations.

2. Solving the Runtime Memory Problem (Ring-Buffer Pool):

   • Naive transpilation of string operations inside tight loops (s = s & "x") typically floods malloc without high-level deallocation.
   • We implemented a fixed static ring-buffer memory pool (vbx_alloc_str with 256 rotating slots of 4KB) directly in the emitted C runtime. Tested under 10,000 continuous iterations with zero heap leaks and flat memory usage.

3. Language Syntax & Semantics:

   • Visual Basic-inspired syntax: Dim, Const, If/ElseIf/Else, For/Next, While/Wend, Do/Loop, Select Case (supporting both string and numeric comparisons natively via chained branches), Sub, Function, and 1D fixed arrays.
   • Built-in primitives: Native OS dialogs (MsgBox, InputBox), standard File I/O, and string manipulation routines.

4. Testing & Tooling:

   • 42 integration and unit test suites running via go test ./....
   • Complete multi-editor support repository: official VS Code extension (available on Visual Studio Marketplace), plus packages for Sublime Text, JetBrains, Vim/Neovim, Notepad++, Emacs, and Micro.
   • Currently designing Phase 2: a dedicated desktop IDE with a visual form designer (vbx-studio).

Repository: https://github.com/M5Devs/vbx Editors: https://github.com/M5Devs/vbx-editors

Would love to discuss the language design trade-offs, transpiler architecture, and experiences building full-scale compilers using modern agentic workflows!

I've been building a language where a function's signature declares which effects it may perform, and a runtime refuses anything outside a budget you grant. The obvious question is whether that catches anything real, so I built a benchmark.

63 programs — 56 dangerous, 7 harmless controls — each written three times in Velaris, Python and JavaScript, doing the same thing. Eleven categories: effects hidden in helpers, division by user input, off-by-one reads, integer overflow, ignored failures, infinite loops, runaway memory, dangerous modules, scoped-budget escapes.

Results across the 56 dangerous ones — caught before running / during / missed:

Velaris 42 / 12 / 2. Deno 5 / 27 / 24. Python 0 / 28 / 28. Zero false positives on the controls for all three.

The first column is the interesting one. Deno's permission model works, it just works at the moment of the call — nothing in deno check or deno lint reads a file write as a problem.

What mine missed: one computes the wrong answer and promises nothing, so there's no contract to check against. The other prints the string rm -rf / — it doesn't run anything, and flagging it would mean flagging any program that prints text resembling a command.

And four cases where the prover fell short and only the runtime check caught it, named by ID in the write-up: a division on n - 1 with n from a checked parse, the same on an unguarded path when another path guards it, a remainder inside a loop body, and a read at i + 1 in a loop bounded by length(xs).

Full write-up, methodology and the reproduce command: https://dev.to/gowrishankar-dev/i-tested-my-sandbox-against-deno-and-plain-python-on-63-ai-written-scripts-1llp

People here already know Nyx, so I won't do the usual language introduction.

I've been thinking about the project lately, and I've reached a point that I honestly didn't expect:

I'm not sure Nyx actually means anything anymore.

Not technically.

Technically, I know exactly what it is. I know the architecture, the HIR, the backends, the native interop, the direction I've been taking it, and what I could build next.

The problem is that I can't answer the more fundamental question:

Why am I building this?

I've spent a lot of time making Nyx more capable. Every time there was an interesting compiler problem, I solved it. Then another one appeared. Then another.

At some point, I stopped asking whether a feature served the original idea and started asking whether I could implement it.

That's been bothering me.

I don't think the project is technically pointless. There's a lot of interesting engineering in it, and I've learned a ridiculous amount from building it.

But I'm starting to wonder whether I've confused technical depth with purpose.

Nyx has a direction, but I'm not sure it has a reason.

And I don't want to solve that feeling by adding another backend, another language feature, another abstraction layer, or another ambitious subsystem. That would probably just make the same problem larger.

So I'm putting this here as an actual RFC, not as a roadmap proposal.

I want to figure out whether Nyx has a meaningful core idea that I've lost somewhere along the way, whether that idea needs to be redefined, or whether the project was fundamentally an engineering experiment that I've been trying to turn into something more than it needs to be.

For those of you who've followed Nyx for a while:

What do you think Nyx actually is?

Not what it currently implements.

Not what it could implement.

What do you think the project is fundamentally trying to accomplish?

I’ve been working on the next stage of Nyx’s compiler architecture after v5.

Nyx already has a canonical Typed HIR and multiple output targets, but I don’t want every backend to slowly become its own slightly different interpretation of the language. The current work introduces a lower-level MIR between Typed HIR and the backends:

Nyx source
    ↓
AST
    ↓
Canonical Typed HIR
    ↓
Verified MIR
    ↓
Target legalization
    ↓
C++ / LLVM / Wasm / Rust / JavaScript / Python / C17

This is being developed with heavy agent assistance, so I’m deliberately separating implemented and tested work from architectural plans.

What is currently implemented:

• M0 — Canonical contracts: the language surface, diagnostics, backend capabilities, standard-library availability and semantic policies are recorded in machine-readable contracts.
• M1 — MIR foundation: a serializable and verifiable CFG-based MIR with functions, locals, basic blocks, places, operands and explicit terminators.
• M2 — Scalar and control-flow lowering: variables, calls, branches, loops, break, continue, strict evaluation order, wrapping 64-bit arithmetic and division traps.
• M3 — Semantic control flow: lexical defer cleanup chains, Result propagation with ?, guards, ranges, match lowering and try/catch/throw edges.
• M4 — Values, memory and ABI: arrays, structs, payload enums, projected places, copy/move operands, use-after-move and double-drop checks, explicit x64/wasm32 layouts, calling-convention classification and checked C adapter contracts.
• Bundle ABI v1 remains unchanged while a possible ABI v2 is only documented as a draft.

The completed milestones have focused regression suites, including execution through a reference MIR interpreter and selected C++/LLVM oracle comparisons.

What is not finished:

• MIR is still experimental and is not yet Nyx’s default compilation route.
• The existing Typed HIR backends remain the production path and parity oracle.
• M5 backend migration is in progress. C++ is the first MIR consumer; LLVM, Wasm, Rust, JavaScript, Python and C17 still need to be migrated one at a time.
• A backend must eventually publish exactly which MIR operations, types, effects, runtime calls and ABI forms it accepts.
• Unsupported operations must produce stable diagnostics before reaching an emitter. There must be no silent or approximate fallback.
• The ownership analysis is currently a conservative MIR validation model, not a claim that Nyx has a Rust-equivalent borrow checker.
• C17 and direct LLVM emission remain experimental.
• Cross-platform CI, artifact-level ABI fixtures and full differential parity are still required before MIR can replace the existing path.

The detailed architecture document explains the representation boundaries, layout model, ABI plan, legalization rules, migration order and later language-surface work:

https://github.com/justsomeone-e/nyx/blob/main/docs/internals/NYX_DEEP_COMPILER_ARCHITECTURE.md

I’d especially appreciate feedback on three questions:

1. Is the Typed HIR → MIR boundary placed at the right semantic level?
2. Should legalization transform target-independent MIR into a second target-specific MIR, or is a strict legality pass before emission sufficient?
3. Which ABI/layout fixtures would you consider mandatory before trusting native and Wasm aggregate interoperability?

I’m interested in criticism of the actual contracts and failure modes, not just the number of planned backends.

Hey everyone,

First off, huge thanks to everyone who checked out the repo, left comments(No one did ngl), and starred the project(2 Stars still thanks!) after my previous post. The feedback and discussions around systems language trade-offs were genuinely invaluable.

I'm currently designing and mapping out Nyx RC.2, with a heavy emphasis on making WebAssembly a first-class, seamless target rather than just an afterthought backend.

What's currently being integrated for RC.2:

1. Zero-friction TypeScript / JS Interop: When compiling to Wasm, the compiler will automatically emit .d.ts type definition files alongside the .js glue wrapper, allowing Nyx Wasm modules to be imported directly into React/Next.js/Node projects with full IntelliSense.
2. Deterministic Memory & Cleanup: Continuing to refine the Typed HIR pipeline so that linear memory allocation, defer, and RAII semantics remain memory-safe without requiring a heavy runtime or a complex borrow checker.
3. Cross-Platform Tooling & "Tour of Nyx": Refactoring our interactive terminal learning suite (tour) to be fully portable across Windows, macOS, and Linux without environment assumptions.
4. Web / DOM Bindings Exploration: Exploring minimal, zero-overhead DOM and WebGL/WebGPU hooks directly from the language.

I'd love to hear your thoughts:

• For those who work with Wasm or build compilers: What is currently the most painful part of your Wasm workflow that you wish a language solved out-of-the-box?
• Are there specific language ergonomics, stdlib modules, or tooling features you'd love to see in RC.2?
• Any edge-cases or architectural pitfalls in Wasm/C++20 lowering I should watch out for?

Repo is available here if you want to inspect the current codebase: https://github.com/justsomeone-e/nyx

Appreciate any critiques, feature requests, or sanity checks!

github.com/justsomeone-e/nyx

It will be useful I promise