(no title)
JhonPork | 1 month ago
Falcon’s profiles are not meant to be “dialects you mix freely” like Rust’s unsafe blocks. They represent different execution contracts, not different safety levels inside the same runtime.
In Rust, unsafe still lives inside one program with:
- one allocator - one runtime model - one ABI - one set of linking assumptions
In Falcon, each profile defines a different world:
- userland assumes a runtime: heap, panics, rich abstractions - kernel assumes no runtime: no heap, no panics, stricter aliasing - baremetal assumes no OS at all: raw pointers, direct memory, UB allowed
Mixing them at runtime would force the strongest constraints everywhere, or require dynamic checks — which defeats the goal.
Instead, Falcon treats profiles as compile-time execution modes, not scoped escape hatches.
The reason non-selected profiles are erased before IR is so:
- LLVM never sees incompatible assumptions - no dead-code elimination or guards are needed - profile-specific rules can be enforced structurally, not heuristically
You still share logic by compiling the same source multiple times:
falcon build app.fc --profile=userland
falcon build app.fc --profile=kernel
falcon build app.fc --profile=baremetal
Or: falcon build app.fc --profiles=all
This produces multiple artifacts from one codebase, each valid by construction for its environment.So the comparison isn’t “why not Rust unsafe blocks”, but: “Should fundamentally different execution contracts coexist at runtime, or be selected at compile time?”
Falcon chooses the latter to avoid hidden coupling and runtime cost.
platinumrad|1 month ago
``` int add(int a, int b) { #ifndef FREESTANDING printf("adding %d and %d\n", a, b); # return a + b; } ```
> You still share logic by compiling the same source multiple times
What's the benefit of this approach over sharing code via libraries?
JhonPork|1 month ago