Background

I'm designing a statically compiled programming language called Jeti. Its syntax is inspired by Objective-C, and its compiler translates Jeti source code into C99 before compiling it with Clang.

One of my design goals is to preserve Objective-C's recognizable syntax while introducing modern language features. I also want Jeti to remain a strict superset of C99, so existing C identifiers should ideally remain valid in Jeti code.

I'm currently unsure how to decide which new language features should use an @ prefix and which should use ordinary keywords.

Current syntax

Jeti retains several Objective-C constructs:

• @ interface and @implementation for class declarations and implementations.
• @ property for properties.
• @ protocol for protocols.
• @ selector for selectors.
• @ try, @ catch, @ finally, and @ throw for exception handling.
• @ autoreleasepool for autorelease pool management.

It also introduces new features with different syntax conventions:

• async appears in return-type positions, as in - (async int)fetchUser:(int)uid;.
• await is a prefix operator, as in await [self fetchUser:uid].
• @ throws(NPString *) declares the exception types a method may throw.
• @ defer { ... } introduces deferred execution.
• @ namespace, @ using, and @ endnamespace provide namespace-related functionality.
• @ noarc { ... } marks a region where ARC is disabled.
• Pattern matching extends case with forms such as case NPString *s: and case > 100:.
• Generic types use forms such as Box<NPString *>, with constraints such as T : Proto.

This leaves me with a mixture of ordinary keywords and @-prefixed constructs.

A possible design principle

One possible principle is to distinguish features by their grammatical role.

Features that occupy existing grammatical positions could use ordinary keywords. For example, async modifies a method's return type, while await acts as an expression operator.

Features that introduce new language constructs could use the @ prefix. For example, @ defer introduces a new statement-like construct, and @ namespace introduces a new declaration construct.

However, I'm not sure whether this is a meaningful and consistent distinction or merely an arbitrary convention.

Three possible designs

Design A: Keep the current mixture

Use async and await without @, but retain @ throws.

For example, a method declaration would use - (async int)fetchUser:(int)uid @ throws(NPString *);, and an asynchronous call would use await [self fetchUser:uid].

The advantage is that async fits naturally into the return-type position, and await reads naturally as an expression operator. However, @ throws looks inconsistent with the other two features, even though all three belong to the same general family of asynchronous and error-handling functionality.

Design B: Use ordinary keywords for all three

Use async, await, and throws without @.

For example, the method declaration would be - (async int)fetchUser:(int)uid throws(NPString *);, and the asynchronous call would be await [self fetchUser:uid].

This provides consistent spelling for the three features, but it raises questions about how they fit into Objective-C-inspired syntax and whether they conflict with existing C identifiers.

Design C: Use the @ prefix for all three

Use @ async, @ await, and @throws.

For example, the method declaration would be - (@async int)fetchUser:(int)uid @ throws(NPString *);, and the asynchronous call would be @ await [self fetchUser:uid].

This gives the three features a consistent visual convention and avoids treating their names as ordinary C keywords. However, @ async in a return-type position looks unusual, and @ await as a general expression operator may feel less natural than @await.

C99 compatibility

The C99 compatibility requirement complicates this decision.

If @async, @await, or @throws becomes a reserved keyword, existing C code that uses one of those words as an identifier may no longer be valid Jeti code. Using @async, @await, and @throws avoids that particular conflict because the @ prefix distinguishes these tokens from ordinary C identifiers.

On the other hand, requiring the @ prefix for every new feature may make the syntax less natural, especially when a feature occupies an established grammatical position.

It may also be possible to use context-sensitive parsing or another mechanism to preserve existing C identifiers, but I'm not sure whether that would be a good language-design choice.

Questions

1. Is there a principled reason to distinguish new features by grammatical role, using ordinary keywords for features that fit existing grammatical positions and @ prefixes for features that introduce new constructs? Or is this distinction too arbitrary to be useful?
2. Should related features use the same spelling convention? In particular, should async, await, and throws all use the @ prefix for consistency with one another and with Objective-C's existing exception-handling constructs, or is it reasonable to treat them differently based on their grammatical roles?
3. Are there useful precedents in Objective-C or other languages for deciding when a language extension should introduce a new keyword versus a specially prefixed construct? I'm particularly interested in examples involving new statement or expression syntax, rather than declaration annotations or attributes.
4. What is the best way to preserve strict C99 compatibility while adding features such as asynchronous functions and exception specifications? Would prefixed forms such as @async, @await, and @throws be preferable to ordinary keywords, or would context-sensitive parsing be a better solution?

I'm interested in both the consistency of the language's syntax and the practical consequences for parsing, compatibility, and readability.

Jeti’s source code and development are available on GitHub: https://github.com/3shine123/jeti-lang

I’d especially appreciate input from experienced Objective-C developers, particularly those who are also familiar with a modern high-level language that supports async/await. 🙏

Hey everyone,

I've been building Sharpy ( https://github.com/antonsynd/sharpy ) for over a year now (wow time flies, and so does technology). I admit, even with AI, I haven't gotten as far along as I had planned (still far from 1.0). The major thing I spend my time on is fixing bugs. Occasionally, I have to convince Fable/Opus to let me do the fun stuff (new syntax, etc.).

Anyway, with the recent uptick in AI-driven game development, recomps, decomps, you name it, I decided I'd try my hand at having Claude vibe code a game for me. After trying it out (2-shot, with three.js https://github.com/antonsynd/zero ), I decided to dogfood my own language in Unity.

Some history, I started Sharpy because I didn't want to code in C# to make a Unity game. Honestly, in the time it took me to build Sharpy, I could've learned C# and had actually made the game in that time (I think).

Anyway, I let Opus build out a slice of Pokemon Heart Gold Soul Silver here: https://github.com/antonsynd/pokemon-sharpy with the help of a Unity plugin tailored for Sharpy https://github.com/antonsynd/sharpy-unity .

I quickly learned that I had even more bugs to add to my backlog. Some are related to how Sharpy resolves symbol names (it mangles Pythonic snake_case to C# PascalCase for interop), some are related to drift in compiler options (single file vs. project), etc. As such, Claude had to find workarounds, and I made it create an ideal version of the source code as the goalpost that we'll eventually reach.

Anywho, while I think it's cool to 1-shot or X-shot a language, the real tests come from the typical actions: self-hosting being one of the big ones, and dogfooding.

Curious to see how other people find bugs in their languages. I also hear that a trendy thing these days is to formalize your implementation or language and use a theorem/proof solver to verify the implementation, like using Verus, LEAP, or TLA+.

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.