Impressive! Very complete on first glance. You might want to soften or qualify the RTOS statement so people focus on its compactness and low latency. As you are already seeing in the comments the RTOS aspect has a lot of opinions depending on what one is trying to accomplish.
I would appreciate an honest comparison with FreeRTOS. Building something like this is an excellent learning exercise for the coder, but someone who has to balance the risks, learning curve and feature set has to justify the adventure in a different way.
One thing that would be interesting to hear more about would be your own recounting of the places where you made opinionated decisions about how things should work.
Looks like a fun project, but I’m curious what you actually tested on. There’s real numbers for estimated context switch timing, and you mentioned implementing context switching, but I can’t find any actual implementations of the context switching routine in your code.
You don’t need to do this yourself, but it’s weird to talk about it if you haven’t.
Yeah, I read that note and stopped looking further. I was hoping that maybe the hardware-specific code was in a different project and just wanted to be nice in case.
I just don’t get the point of making AI slop out of something like a toy RTOS, which is inherently a learning project more than anything else. There’s nothing even fun about doing it if you won’t even try to get it to run on an STM32 or something.
I love Python's productivity for AI/ML, but I've often been frustrated by the "Python tax" — that overhead you pay when orchestrating many small operations or running tight loops outside of C++ kernels.
I started Flux to see if we could have a language that feels like Python (indentation-based, clean) but lives natively in the Rust ecosystem. Unlike Mojo, which is its own massive ecosystem, Flux aims to be a lean, Rust-powered alternative that might eventually allow seamless blending of high-level ML logic with Rust's safety.
It's very early (experimental!), but it already handles basic tensor ops and Python interop. I'd love to get feedback on the syntax and whether the "native orchestration" approach resonates with you.
Thanks for the question!
On real codebases: Currently, the transpiler works best on "clean" C++ (logic-heavy code, algorithms, and data structures). It can handle a significant portion of the syntax, but for large, complex codebases using heavy template metaprogramming or platform-specific APIs, there are still limitations.
Compilation & Manual Fixes: Does it compile out-of-the-box? For small to medium-sized snippets and standard logic, yes. However, for real-world projects, manual fixes are usually required, especially for:
- Rust's Borrow Checker: C++'s pointers don't always map 1:1 to Rust's ownership model. The transpiler generates code that is syntactically correct, but you might need to adjust lifetimes or use Arc/Mutex where C++ was more permissive.
- External Dependencies: Mapping C++ libraries to their Rust/Go equivalents still requires some manual configuration.
Goal isn't necessarily "100% automated migration" (which is the holy grail), but rather to automate the tedious 80-90% of the porting process, allowing developers to focus on fixing the architectural differences.
I have some examples in the repo, and looking for more "real-world" test cases to improve the conversion logic
Hi HN, I'm building a transpiler specifically focused on migrating C++ to Rust and Go.
Modernizing legacy C++ codebases is a huge challenge. While there are some tools for C++ to Rust (like c2rust), I wanted to create a more flexible approach that handles both memory-safe (Rust) and concurrency-focused (Go) targets from the same C++ source.
What it does:
Parses C++ code and maps it to equivalent constructs in Rust and Go.
Aims to reduce the manual effort in language migration.
Current Status:
Focus is strictly on C++ to Rust/Go (no other languages planned).
It's in the early stages, and I'm currently refining the AST mapping.
I would love to hear your thoughts on:
What are the biggest pain points you've faced when migrating C++ to Rust/Go?
Are there specific C++ patterns you'd like to see automated first?
I’ve been working on a tiny RTOS as a personal project to better understand how operating systems and schedulers work internally.
This project includes: - Basic task scheduler - Context switching - Simple memory management - Runs on (your target hardware or environment)
Motivation: I wanted to learn OS internals by building everything from scratch rather than relying on existing frameworks.
Challenges: - Implementing context switching correctly - Designing a minimal but usable scheduler - Keeping the codebase simple and readable
I’d really appreciate feedback, especially on: - Architecture design - Scheduler implementation - Code structure
GitHub: https://github.com/cmc-labo/tinyos-rtos