DEV Community: Void

Lugn - The distraction blocker that's actually on your side

Void — Tue, 23 Jun 2026 19:21:57 +0000

Most distraction blockers treat you like a criminal.

They lock you out. They shame you. They charge you monthly to feel restricted.

There's a better way.

Introducing Lugn

Lugn (Scandinavian for "calm") is a privacy-first browser extension that helps you build real focus habits - without the guilt.

No hard locks. No punishment. Just a simple, mindful nudge:

"Are you sure you want to visit this site?"

Yes or no - your choice. Always.

Why Lugn is different

	Lugn	Cold Turkey	Freedom
Soft blocking	✅	❌	❌
Discipline Score	✅	❌	❌
Public leaderboard	✅	❌	❌
100% local free tier	✅	❌	❌
Privacy-first	✅	⚠️	⚠️

How it works

1. Block distracting sites
Add any site to your blacklist in seconds.

2. Get nudged, not locked out
Visiting a blocked site shows a calm redirect page - not a wall.

3. Build your Discipline Score
Every choice you make is tracked locally. Your score reflects your real habits over time.

4. Climb the leaderboard (Premium)
Opt into the public leaderboard and compete with others building better focus habits.

Free vs Premium

Free - forever:

Site blacklist
Soft-block redirect
Discipline Score
Full local stats — zero accounts, zero tracking

Premium:

Cloud sync across devices
Detailed graphs and analytics
Custom blocked page
Public leaderboard

Privacy is not an afterthought

The free tier runs entirely on your device. No servers. No accounts. No data leaving your browser. Ever.

Premium sync is opt-in, encrypted, and you can delete your data anytime.

Coming soon to Chrome & Firefox

Lugn is currently in development. Follow the build in public on X and be first to know when it launches.

If you're tired of distraction blockers that feel like a punishment - Lugn is for you.

Join Waitlist: https://tally.so/r/RG2QWj

How I Built a Programming Language in C in 30 Days (After Only Coding for a Year)

Void — Sun, 14 Jun 2026 17:06:56 +0000

One year ago, I didn't know how to write a single line of code. I was trapped in what the community calls "tutorial hell," building generic web apps and feeling like I wasn't pushed enough. I had this lingering fear that if I only stuck to trivial, high-level projects, I’d never truly understand how computers work under the hood.

So, 30 days ago, I decided to take the ultimate plunge into low-level engineering. I decided to build my own programming language from scratch.

Meet Arc (not to be confused with the Lisp dialect!): an interpreted language powered by a custom, stack-based bytecode virtual machine written entirely in pure C. It features class-based abstractions, automatic list/string structures, custom error handling (TRY/CATCH), file I/O, and its own modular file-import system.

Here is a quick look at what native Arc code looks like running on my runtime:

IMPORT "math.arc"

FN printSum(a, b) THEN
    print(a + b)
END

VAR i = 0
WHILE i < argc THEN
    print("Arg", i, ": " + argv[i])
    i = i + 1
END

The entire project is completely free and open-source. If you want to dive into the codebase, see the compilation pipeline, or test it out yourself, consider dropping a star on the repository!
Link to Arc Repository on GitHub

The Twist: Completing "Easy Mode" on "Nightmare Mode"

When I started, I didn't know how to write an abstract syntax tree or a compiler pipeline. I found a couple of great videos demonstrating how to build a basic mathematical parser and conditions, but they were written in Python. Instead of copy-pasting the instructor, I forced a brutal constraint on myself: Watch the concepts in Python, but implement them entirely in pure C.
This instantly transformed the project from a standard tutorial into a low-level gauntlet.

Python handles variable sizes, dynamic strings, arrays, and type objects completely behind the scenes.
In C, I had no safety nets. Every time I wanted to append to a list, read a file, or create an object, I had to manually wrestle with memory tracking, pointers, and structures.

The Architectural Evolution:

From Tree-Walking to Bytecode VM
Originally, Arc started as a standard tree-walk interpreter. It evaluated the Abstract Syntax Tree recursively line-by-line. It worked, but it was slow, and I wanted to know how real industrial languages executed code.
So, I ripped the execution engine out and replaced it with a Stack-Based Bytecode Virtual Machine.

[Source Code] ---> [Lexer] ---> [Parser/AST] ---> [Bytecode Compiler] ---> [Custom VM Stack Engine]

Instead of running instructions straight from the parse tree, Arc now compiles code down into raw, compact bytecode array instructions, passing them into an execution loop that mutates values across a lightweight custom VM evaluation stack.

Moving Off-Script (Building Features In the Dark)

After the first few videos, I stopped watching tutorials completely. The remaining features were coded purely by reading documentation, drawing memory layouts on paper, and running experiments. I built:

Scope-Aware Variable Lookups: Managing standard and nested scopes across execution blocks.
Complex Loops: Native execution of WHILE and index-swapping FOR...IN loops.
Explicit Class Architectures: Grouping data and methods seamlessly without an implicit this/self binding requirement, requiring users to explicitly pass data structures back into encapsulated functions.
Native C Function Bindings: Exposing high-performance C standard utilities to the Arc runtime environment.

The Memory Battle: Malloc, Arenas, and AddressSanitizer

Replacing Python's dynamically typed objects with real, explicit C structs was by far the hardest engineering challenge I have ever tackled.
Early on, every string initialization, list manipulation, and class instantiation was handled with messy, individual malloc and calloc calls. This quickly turned into an absolute nightmare of memory leaks, dangling pointers, and segmentation faults.
During weeks two and three, Valgrind and AddressSanitizer (ASan) became my absolute best friends. I spent entire nights tracking down single byte offsets that were corrupting the runtime stack.
To bring order to the chaos, I ended up rewriting major portions of the core architecture to rely on Memory Pools and Arenas. Instead of blasting the heap with thousands of tiny allocations, the runtime requests large chunks of contiguous memory up front and partitions it safely out to strings, structures, and arrays.

What It Feels Like to Run Your Own Runtime

There is a genuinely crazy, indescribable satisfaction that comes from writing a text script, passing it into a binary you wrote, and seeing your custom VM process data perfectly, catch its own errors safely via a TRY/CATCH block, and exit with 0 memory leaks.

TRY
    VAR file = open_file("missing.txt", "r")
CATCH e THEN
    print("Caught expected runtime error safely:", e)
END

Building Arc proved to me that systems programming isn't an exclusive club reserved for veterans who have been coding for twenty years. It's accessible to anyone willing to suffer through the segmentation faults, look closely at the memory addresses, and put in the hours.

What's Next for Arc?

The language is evolving rapidly. My next milestone is to abstract file handles into an entirely native object-oriented file architecture (class File).
The codebase is structured to be highly readable for anyone else who wants to learn how compilers and interpreters work without getting lost in millions of lines of corporate boilerplate.

Have you ever attempted to write a low-level runtime engine?
What strategies do you prefer when managing custom type objects inside an Arena? Let me know your thoughts or feedback in the comments below! Check out the source code, view the standard libraries, and track my updates on GitHub!

How I Migrated My Language (Arc) from a Tree-Walker to a Bytecode VM in 7 Days

Void — Thu, 11 Jun 2026 09:57:18 +0000

If you told me a year ago, when I first started learning how to code, that I would be writing a custom bytecode virtual machine, I would have laughed you out of the room.

But after spending about 1.5 months building my programming language, Arc, as a standard tree-walking interpreter, I hit a wall. Tree-walkers are elegant, but they are notoriously slow because they constantly traverse the Abstract Syntax Tree (AST) during execution.
I wanted speed. I wanted to understand how the big leagues (like Lua or Python) actually execute code. So, I decided to rip out the heart of Arc and replace it with a stack-based bytecode VM.

It was a wild 3-day sprint. Here is how it went down.

The Timeline

Day 1: The Valley of Despair

Status: Very tough day. Code is completely half-baked. Most things are broken.
The Reality: I underestimated bytecode. Turning an AST into a linear stream of instructions (opcodes) and operands is a massive mental shift. I spent hours wrestling with stack offsets and trying to emit correct bytecode. By the end of the day, the codebase was a graveyard of compiler errors. I went to bed questioning my life choices.

Day 2: It Works... But It's Slower?

Status: Basic support is finally there, but the VM is incredibly slow.
The Reality: The VM finally successfully executed its first program! The excitement lasted for exactly five seconds until I ran my benchmarks. The bytecode VM was slower at EVERYTHING... except for a recursive Fibonacci function. Why? Because the tree-walker had massive overhead for function calls, while my VM handled call frames a bit better. But for loops, math, and variable assignments? The VM was dragging its feet.

Day 3: The Optimization Breakthrough

Status: Optimizations kicked in. Matches the tree-walker, and smashes Fibonacci.
The Reality: Day 2's slowness was because of naive decoding loops. On Day 3, I tightened the main loop, used a flat array for the stack, and streamlined instruction decoding.
The Result: The bytecode VM is now neck-and-neck with the old tree-walking approach on basic scripts, and it absolutely annihilated the recursive fib(30) benchmark, running almost 500ms faster!

Day 4-7: Coming soon...

What is Next?

The core architecture is finally handling the heavy lifting, but the sprint is not over yet.
For the second half of the week, the focus shifts entirely to stability, refinement, and edge cases. Up next is tracking down some elusive memory leaks, hunting down edge-case bugs that crash the stack, and polishing the codebase so it is ready for prime time. Stay tuned for the next update.

Repository: https://github.com/VxidDev/Arc

Moving From Tree-Walk to Bytecode: Announcing My Ultimate C Programming Challenge

Void — Mon, 08 Jun 2026 11:00:46 +0000

For the past few months, I’ve been building a custom, dynamically typed programming language from scratch in pure C. Up until now, it has lived comfortably as a classic, textbook AST Tree-Walk Interpreter.
If you’ve ever built one, you know the drill: your parser spits out a nested Abstract Syntax Tree, and you evaluate operations on the fly by recursively executing visit() functions down the nodes. It’s elegant, intuitive, and highly rewarding to write.
But recursive pointer-chasing and host-stack overhead eventually hit a performance wall.
So, I've decided to issue myself a massive technical challenge: I am going to completely tear down my comfortable tree-walk interpreter and rebuild it as a linear Bytecode Compiler and Virtual Machine.
I am giving myself a strict timeline to get a minimal, stack-based VM running. I haven't written a single byte of the new engine yet, this is a raw, ground-zero start. Here is why I'm taking on this architectural migration, the design hurdles I'm preparing to face, and how the mental models are about to collide.

The Core Problem: Why the Tree-Walker Has to Go

In my current interpreter, the execution pipeline is completely unified. A binary operator node evaluates its subtrees down to raw host pointers immediately, runs the C math logic on the spot, and passes the result up:

// MY CURRENT APPROACH: Direct recursive evaluation
Object* visitBinOpNode(ASTNode* node, Interpretator* ctx) {
  BinOpNode* binOper = (BinOpNode*)node;

  Object *srcObj = binOper->leftNode->visit(binOper->leftNode, ctx);
  Object *destObj = binOper->rightNode->visit(binOper->rightNode, ctx);

  // Runtime evaluation happens RIGHT HERE
  return (Object*)addNumber((Number*)destObj, (Number*)srcObj);
}

The challenge of moving to a bytecode VM is that I have to split this execution into two completely distinct phases. I will no longer be evaluating expressions on the fly; I have to linearize them.
My new compiler pass will have to traverse the tree and flatten it into a one-dimensional array of instructions (uint8_t), which a completely separate Virtual Machine runner will execute later via a tight switch loop.

Challenge 1: Migrating the Memory System

One design constraint I'm setting for myself is to reuse my existing, heavily optimized type system. I already have robust, pooled constructor functions like initInt(), initFloat(), and initString().
My plan is to have the VM's computational evaluation stack literally hold arrays of these exact same host data structure pointers (Object* stack[256]).
The real test will be handling memory ownership. Right now, my AST visitor functions have clear rules for when to call freeObject(). In a VM, values will be flying off the evaluation stack constantly. My VM execution loop is going to have to take full, manual ownership of freeing intermediate, short-lived objects without destroying my persistent memory pools or causing catastrophic memory leaks.

Challenge 2: Control Flow Without a Safety Net

This is the part of the project I am dreading the most. In a tree-walk interpreter, implementing a while loop or an if statement feels like cheating because you lean entirely on the host language. You literally just write a native C while loop inside your visitor function and recursively execute the body node.
In a bytecode engine, there are no native loops. There are only directional jumps (OP_JUMP, OP_JUMP_IF_FALSE).
To make a loop work, I have to implement a backpatching mechanism. When compiling an if condition, the compiler has to emit a jump instruction before it even knows how many bytes the interior body block will take. I'll have to emit dummy placeholder bytes for the jump target offset, compile the interior statements, calculate the exact byte distance, and then surgically go back into my bytecode array to rewrite those placeholder bytes with the correct offset.
Getting those offsets right down to the exact byte without causing the instruction pointer to derail into illegal memory is going to be an absolute nightmare to debug.

The Roadmap Ahead

My goal for the next few days is simple:

Define a core set of fundamental Opcodes (OP_CONSTANT, OP_ADD, OP_RETURN).
Implement a dynamic array structure to hold raw bytes (the Chunk) alongside a Constant Pool for my objects.
Build a simple stack-based VM loop that can execute hardcoded math arrays before hooking it up to the parser. Stripping away the abstraction of recursive AST interpretation is going to force me to reckon with how hardware actually processes instructions. I’m fully expecting a week of segmentation faults, index-out-of-bounds errors, and broken logic.

Wish me luck. I’ll be posting updates on my progress, design mistakes, and whatever breakthroughs happen along the way.

Arc v0.0.2-alpha, Release notes

Void — Sat, 06 Jun 2026 14:03:41 +0000

Release Notes - v0.0.2-alpha

Version Overview

Version: v0.0.2-alpha
Status: Alpha (Experimental)
License: GPL-3.0

This release focuses on stability, performance, and memory safety improvements. Several critical bugs have been fixed, the internal architecture has been refined, and the interpreter is now measurably faster across all benchmarks.

Highlights

Fixed parser stack overflow caused by unbounded mutual recursion.
Fixed interpreter stack overflow on deeply recursive function calls.
Fixed multiple memory management issues, including a double-free and a zero-argument function call crash.
Reduced "Token" size from 88 bytes → 56 bytes.
Reduced "Position" size from 40 bytes → 24 bytes.
Replaced AST visitor dispatch "switch" statements with per-node dispatch tables.
Added "--cleanup" ("-C") flag for Valgrind and memory leak analysis workflows.

Bug Fixes

Stack Overflow in Parser

Fixed unbounded mutual recursion between "exprParser", "blockParser", "andOrParser", and "compExprParser" that caused a segmentation fault on files with many statements or deeply nested expressions.

A per-statement depth reset and recursion depth guard have been added.

Stack Overflow in Interpreter

Fixed unbounded recursion in "visitNode" that caused a segmentation fault on deeply recursive Arc functions (e.g. "countdown(5000)").

A configurable call depth limit has been introduced.

Double-Free in Function Calls

Fixed a double-free in "initFunctionCall" where "calleeObj" was freed both inside the function and by the caller.

Zero-Argument Function Call Crash

Fixed a crash when calling a function with no arguments caused by "arenaAlloc" returning "NULL" for a zero-size allocation.

Performance Improvements

Dispatch Table on ASTNode

Each AST node now carries a "visit" function pointer assigned during parsing.

Internal visitors now call "node->visit" directly, reducing dispatch overhead during AST traversal.

Smaller Token and Position Structs

Removed "filename" and "filetext" from "Position", reducing:

Parser stack frames now consume significantly less memory, increasing the safe nesting depth before overflow.

Parser Token Locals Reduced

Replaced full "Token" locals used only for error reporting with lightweight "Position" pairs, further reducing parser frame size.

Architecture Improvements

filename and filetext Moved off Position

"filename" and "filetext" are now stored on the "Parser" structure and dispatch arguments rather than duplicated inside every token.

This reduces memory usage and more accurately scopes file metadata for imports and multi-file compilation.

Memory Management

Optional Cleanup Mode

Added an explicit opt-in cleanup mode:

arc --cleanup program.arc

arc -C program.arc

When enabled, Arc frees all arenas, pools, and tables before exiting.

By default, memory is reclaimed by the operating system on process termination for maximum performance.

This behavior does not affect memory usage while programs are running.

Arena Block Size Pre-Sizing

Token array capacity is now estimated from source file length, reducing arena reallocation churn during lexing.

CLI

New Flag

Flag| Description
"--cleanup", "-C"| Free all memory before exit. Useful for Valgrind and leak checkers.

Benchmarks

Measured against CPython 3.x.

Benchmark| Python| Arc| Notes
"fibonacci(30)" recursive| 95 ms| 1163 ms| Symbol table allocation per call, to be optimized
"fibonacci(1000)" iterative| 0.06 ms| 0.22 ms| 3.6× slower
"sum(1..1000000)"| 51 ms| 133 ms| 2.6× slower
String concat ×10000| 0.58 ms| 39 ms| O(n²), to be optimized
Nested loops (1000×1000)| 42 ms| 124 ms| 3× slower
Variable churn ×100000| ~42 ms| 25 ms| 1.7× faster than Python

Roadmap

[ ] Fix symbol table allocation per function call (major speedup for recursive code)
[ ] Fix O(n²) string concatenation
[ ] Stop copying objects on every variable access (reference counting or static number interning)
[ ] Scoped environments for local variables
[ ] Bytecode Virtual Machine (VM) for improved execution speed
[ ] Expanded standard library (Networking, JSON support)
[ ] Enhanced REPL with history and auto-completion

Arc is currently in alpha. Feedback and contributions are welcome as we move toward a stable 1.0 release.

Arc v0.0.1-alpha - A Lightweight C-Based Programming Language

Void — Thu, 04 Jun 2026 18:28:32 +0000

We are excited to announce the first alpha release of Arc, a lightweight, C-based programming language and interpreter designed for simplicity, performance, and educational clarity.

Version Overview

Version: v0.0.1-alpha
Status: Alpha (Experimental)
License: GPL-3.0

This initial release establishes the foundational pipeline of the Arc language, from lexical analysis to AST-based interpretation, featuring a robust set of core language constructs and a custom memory management system.

Key Features

Language Core

Variable System: Declaration and updates using the VAR keyword.
Functions: Support for custom functions (FN) with parameters and RETURN values.
Control Flow: Conditional branching with IF, THEN, ELIF, and ELSE.
Iterative loops with WHILE, FOR, and THEN.
Loop control with BREAK and CONTINUE.
Exception Handling: Graceful error recovery using TRY...CATCH blocks.
Data Types: Integrated support for Numbers (Integers/Floats), Strings, Booleans, and Lists.
Import System: Modularize projects by importing other .arc files using IMPORT.

Syntax Highlights

Case Sensitivity: Keywords (e.g., VAR, WHILE, IF) are case-insensitive.
Identifiers (variable and function names) are case-sensitive.
Operators: Comprehensive set of arithmetic (+, -, *, /, ^), comparison (==, !=, <, >, <=, >=), and logical (AND, OR, NOT) operators.
Comments: Single-line comments starting with #.

Built-in Standard Library

I/O Operations: print, get_input, open_file, read_file, write_file, close_file.
Data Manipulation: len_of, typeof, to_int, split_string, append_list, range.
Math Library: A comprehensive math.arc providing constants (PI, E) and functions (sin, cos, tan, sqrt, log, etc.).

Tooling & CLI

Arc comes with a powerful CLI and an interactive REPL:
Interactive REPL: Run code line-by-line with syntax highlighting.

CLI Options

--debug (-d): View tokens and AST tree during execution.
--code (-c): Execute a string of code directly.
--float-precision (-p): Control decimal output.
--mempool-size (-m): Tune the custom memory allocator.
--last-result (-l): Print the result of the last evaluated expression.
--disable-colored-formatting (-n): For plain text environments.

Architecture

Clean Pipeline: Modular separation of Lexer, Parser, AST, and Interpreter.
Memory Management: Implements a Memory Pooling system to minimize malloc/free overhead and prevent fragmentation.
Zero External Dependencies: Built entirely in standard C.

Getting Started

Prerequisites

GCC or Clang
Make

Build

make release
Run
./arc script.arc

Roadmap

Scoped environments for local variables.
Bytecode Virtual Machine (VM) for improved execution speed.
Expanded standard library (Networking, JSON support).
Enhanced REPL with history and auto-completion.

Arc is currently in alpha. We welcome feedback and contributions as we move toward a stable 1.0 release.

Building Arc: A Programming Language Written in C

Void — Tue, 02 Jun 2026 06:25:30 +0000

For the past month, I've been building Arc, a programming language written in C.

As someone who started coding roughly a year ago, I wanted a project that would push me beyond application development and into language implementation.

The project started as a way to learn more about interpreters, language design, parsing, and runtime systems. Over time, it evolved into something much larger: a language that aims to stay simple while remaining powerful enough for real scripting and automation tasks.

Repository: https://github.com/VxidDev/Arc

Why Build Yet Another Programming Language?

Programming languages are one of the best ways to learn how software works beneath the surface.

Building Arc forced me to understand:

Lexical analysis
Parsing
Abstract Syntax Trees (ASTs)
Runtime execution
Symbol tables
Error handling
Memory management

Instead of reading about these topics, I wanted to implement them myself.

Design Goals

Arc is heavily inspired by the simplicity of languages such as Python and Lua.

The goals are:

Easy-to-read syntax
Small and understandable implementation
Fast iteration on language features
Lightweight scripting capabilities
Potential for embedding into larger applications

At the same time, I want to keep the implementation straightforward enough that contributors can understand how the entire language works.

Current Features

Arc currently includes:

Lexer
Parser
AST generation
Tree-walking interpreter
Variables
Functions
Control flow statements
Error reporting
Basic type system

Example:

VAR i = 0

WHILE i < 10
    PRINT(i)
    i = i + 1
END

Challenges

The hardest parts so far haven't been adding new features.

They've been:

Designing clean language semantics
Managing memory correctly
Avoiding interpreter architecture mistakes
Improving diagnostics and error messages

It's surprisingly easy to add syntax. It's much harder to keep a language coherent as it grows.

What's Next?

Some areas I'm currently working on:

Better error messages
More standard library functionality
Further interpreter optimizations
Stabilizing the type system
Exploring a future bytecode VM

What I've Learned

The biggest lesson so far is that programming languages are much more than parsers and syntax.

A language is a collection of design decisions. Every new feature affects readability, maintainability, implementation complexity, and future growth.

Building Arc has been one of the most educational projects I've worked on.

If you're interested in language design, interpreters, or compiler construction, feedback is always welcome.

Repository: https://github.com/VxidDev/Arc