alt Hacker NewsSure. The hang up here is SWEs belief those abstractions must be stored as some syntax they know; C, Python, RoR, Linux, Elixir... whatever.
There is zero obligation to capture the concept of memory safety in traditional software notation. If it was possible to look inside the hardware at runtime no one is going to see Rust syntax.
At runtime it's more appropriate to think of it as geometric functions redrawing electrical state geometrically to avoid collisions. And that's where future chip and system state management are headed.
Away from arbitrary syntax constructs with computational expensive parsing rules of the past towards a more efficient geometric functions abstraction embedded in the machine.
Replies
> The hang up here is SWEs belief those abstractions must be stored as some syntax they know
Contracts need to be written down to be effectively enforced. We don’t like a he said she said in software, right?
> The hang up here is SWEs belief those abstractions must be stored as some syntax they know
What does it matter how it's "stored"? I think (hope?) that most SWEs know that that syntax and its semantic aren't how things work on the metal. Storage format of the syntax seems pretty irrelevant. And surely you're not suggesting that SWEs should be using a syntax and semantics that they...don't know.
So what's the better, non-traditional-software notation? Your conceptualization does sound genuinely intriguing.
However, it seems like it would by necessity be non-portable across architectures (or even architecture revisions). And I take it as given that portable software is a desirable thing.