This repository contains the Request for Comments (RFCs) that define the Raccoon programming language specification, implementation, and ecosystem. Raccoon is a general-purpose, async-by-default systems language with TypeScript-like syntax, garbage collection, race-free concurrency, and a comprehensive standard library optimized for building APIs, workers, and CLIs.
Version: v0.1 (Draft) Status: Active Development
An RFC (Request for Comments) is a design document that describes a new feature, specification, or process for the Raccoon language. RFCs serve as the primary mechanism for proposing major changes, documenting design decisions, and ensuring community involvement in the language's evolution.
RFCs provide several benefits over other communication channels:
- Asynchronous collaboration - No implicit demand for immediate responses
- Thoughtful feedback - Reviewers have time to consider and propose changes
- Parallel collaboration - Multiple people can collaborate without conflicts
- Searchability - RFCs are easily searchable and referenceable
- Permanent record - RFCs are retained indefinitely for historical context
- You want to frame a problem and propose a solution
- You need thoughtful feedback from team members
- You want to surface an idea, improvement, or architectural change
- You need to define a feature or design specification
- You're making a decision that impacts multiple components or modules
- Making minor implementation details or bug fixes
- You're the sole decision maker and the change is within your scope
- The change is trivial and doesn't require discussion
- Use the RFC Template as a starting point
- Assign the next available RFC number (format:
RFC-XXXX) - Start with Status: WIP or Draft
- Include all required sections from the template
- Author name and date are required
Each RFC has a status label that provides context for readers:
- WIP: Work in Progress - Still being drafted, not ready for review
- Draft: Initial complete proposal ready for early feedback
- Reviewing Problem: Focus feedback on the problem statement
- Reviewing Solution: Problem is understood, reviewing the proposed solution
- Accepted: Decision made, proposal approved for implementation
- Implemented: RFC's proposal has been built and merged
- Closed: Discussion complete, no specific implementation required
- Rejected: Proposal not accepted after review
- Abandoned: RFC purposefully set aside with no plans to proceed
- Superseded: Replaced by a newer RFC
Files should follow the pattern: RFC-XXXX-Title-Using-Kebab-Case.md
- Authors update the status label as the RFC progresses
- Reviewers provide feedback via comments or pull requests
- Discussion continues until consensus or decision is reached
- Final status reflects the outcome
- RFC-0001: Language Goals - Fundamental goals and philosophy
- RFC-0002: Grammar & Parser - Formal grammar and parsing rules
- RFC-0003: Error Model - Errors-as-values approach
- RFC-0014: Type System & Inference - Static typing and inference
- RFC-0009: Concurrency & Tasks - Async-by-default model
- RFC-0010: Garbage Collector - Memory management strategy
- RFC-0006: Package Management - Package structure and management
- RFC-0007: Module Resolution - Import/export mechanics
- RFC-0015: Module Graph & Tree Shaking - Dependency optimization
- RFC-0019: Registry Client - Package registry interaction
- RFC-0060: Registry API - Registry service specification
- RFC-0011: Standard Library (WebSocket) - WebSocket support
- RFC-0018: Standard Library (HTTP) - HTTP server and client
- RFC-0024: Logging & Observability - Structured logging
- RFC-0004: Coding Standards - Code style guidelines
- RFC-0005: Project Structure & Hexagonal Pattern - Architecture patterns
- RFC-0008: Naming Conventions - Naming rules and patterns
- RFC-0013: Functional Programming - FP paradigms and patterns
- RFC-0016: CLI & Tooling - Command-line interface
- RFC-0017: Formatter & Linter - Code formatting and analysis
- RFC-0020: Build System - Build pipeline and optimization
- RFC-0021: IR Specification - Intermediate representation
- RFC-0022: Codegen & Linking - Code generation and linking
- RFC-0023: Testing Framework - Testing infrastructure
- Async by default - All functions are implicitly async
- No exceptions - Errors are values via
Result<T, Error> - TypeScript-like syntax - Familiar syntax for JS/TS developers
- Scoped packages only - No relative imports (
./,../) - Garbage collected - Automatic memory management
- Race-free concurrency - Built-in safety guarantees
@raccoon/*- Core language and standard library@scope/*- User-defined scoped packages
.rcc- Raccoon source filesmain.rcc- Entry point for executablesproject.toml- Monorepo configurationpackage.toml- Package configuration
import { serve, router } from "@raccoon/std/Http"
import { Result, Ok } from "@raccoon/core/result"
function main(): Result<void, Error> {
const r = router()
.get("/healthz", _ => json(200, { status: "healthy" }))
.post("/api/users", handleCreateUser)
serve(r, { port: 8080 })
return Ok()
}
function handleCreateUser(req: Request): Result<Response, Error> {
// Async by default - no await needed
const body = req.json()
// Error handling via Result type
return body.map(data =>
json(201, { id: generateId(), ...data })
)
}
- Review existing RFCs to avoid duplication
- Create a new RFC using the template
- Submit for review via pull request
- Participate in discussion and iterate
- 0001-0099: Core language features
- 0100-0199: Standard library
- 0200-0299: Tooling and ecosystem
- 0300-0399: Implementation details
- 0400+: Community proposals
- RFC Template - Starting point for new RFCs
- Language Website: (Coming Soon)
- Community Forum: (Coming Soon)
- Implementation Repository: (Coming Soon)
All RFCs in this repository are licensed under [LICENSE] unless otherwise specified.
Raccoon Core Team
For questions or discussions about RFCs, please open an issue in this repository.