It currently supports two boot paths: a direct 512-byte BIOS boot sector and GRUB Multiboot. The direct path loads the kernel from disk, switches the CPU into 32-bit protected mode, and enters a freestanding C kernel_main(). The GRUB path performs the same MMUKO boot sequence through Multiboot.

The project runs under QEMU and includes assembly entry points, linker scripts, a freestanding C kernel, serial/VGA output, and Windows/Unix build paths.

I’m exploring how far the architecture can evolve toward a small, modular kernel with a stable ABI and independently replaceable components. Feedback on the boot architecture, kernel boundary, and next steps would be very welcome.

Comments URL: https://news.ycombinator.com/item?id=49554102

Points: 9

# Comments: 2

The architecture is program-first rather than binding-first, with a stable C ABI, FFI bindings, Polycallfile/Polycallrc configuration, runtime state management, and telemetry.

I’ve recently completed the Windows build path producing both libpolycall.dll and libpolycall.a, and I’m working toward using the same runtime across Python, Node.js, Java, Go, and other language environments.

I’d particularly appreciate feedback on the ABI design, runtime architecture, configuration model, and approach to cross-language dynamic loading.

Comments URL: https://news.ycombinator.com/item?id=49553255

Points: 4

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49525163

Points: 1

# Comments: 0

Configuration-based language building (not code generation) Compile-time safety through token triplets (type, memory, value) Stage-bound execution pipeline (0-6 stages) R-syntax for inline regex without escape hell Build a working language prototype in days

Key Innovation: The token triplet system ensures compile-time safety: ctypedef struct { token_type; // identifier, keyword, constant token_memory; // static, dynamic, fluid token_value; // immediate, deferred, computed } rift_token_t; Real Usage: I'm using RIFT to build GosiLang – a polyglot language that talks to any programming language (interpreted or compiled). What took a year with YACC now takes weeks. Technical Details:

Written in C (migrating to Rust for R-syntax support) Stage-bound configuration: .riftrc.N files Error zones: 0-3 (OK), 3-6 (Warning), 6-9 (Critical), 9-12 (Panic) Detach mode for full language independence

Currently building the community around RIFT philosophy. Looking for "RIFTers" who want to build languages without the traditional pain. GitHub: https://github.com/obinexus/rift Video walkthrough: https://www.youtube.com/watch?v=rLkzHF7LXUA (28min technical deep dive) Ecosystem: https://github.com/stars/obinexus/lists/the-rift-ecosystem

Comments URL: https://news.ycombinator.com/item?id=45190796

Points: 2

# Comments: 2

Single API definition → automatic polyglot implementations Zero-trust security at the protocol level Cryptographically-seeded GUIDs for perfect bug reproduction Silent telemetry capturing every interaction Hot-swappable adapters without downtime

Key Innovation: We've moved from "binding-first" to "program-first" architecture. Instead of writing language-specific bindings, you define your API once and LibPolyCall handles the translation. Real Metrics:

Reduced integration time by 75% in pilot deployments Zero-overhead FFI calls through direct memory mapping 100% state reproducibility for debugging Supports Python, Node.js, Rust, Go (more coming)

Use Cases:

Legacy COBOL systems talking to modern microservices Cross-language microservice communication Unified telemetry across polyglot systems Hot-swapping components without downtime

Currently in v1trial. Looking for feedback from teams dealing with polyglot complexity. GitHub: https://github.com/obinexus/libpolycall Docs: github.com/obinexus /libpolycall/docs Video Demo: ionhttps://youtube.com/@obinexus/playlists (search libpolycall) Happy to answer questions about the architecture, zero-trust implementation, or our approach to solving the polyglot problem!

Comments URL: https://news.ycombinator.com/item?id=45190762

Points: 3

# Comments: 0