Erlang is a bytecode VM, so "compiled" for sure, and is pretty much the pioneer of hot upgrades.
Plenty of Lisps and Schemes are compiled (though often to bytecode) and can typically dynamically replace parts of the program.
I think ability to hot upgrade seamlessly is more a statement of "how much of the data structure shape is carried at runtime" / "how likely it is old and new API data structures happen to interoperate", and how likely it is that one can convert old runtime state to new runtime state. And that one can be seen as a trade-off; close to the metal control over memory layout is a performance gain, but in practice trades off this kind of flexibility (in theory you could make it work, but it's probably a lot of work).
https://www.theseus-os.com/ is an experimental kernel that can restart/reload/upgrade Rust components at ELF library boundaries. (State internal to a component has to be discarded unless you program a converter. Then again most JS web development hot reload discards internal state of a component.)
Plenty of Lisps and Schemes are compiled (though often to bytecode) and can typically dynamically replace parts of the program.
I think ability to hot upgrade seamlessly is more a statement of "how much of the data structure shape is carried at runtime" / "how likely it is old and new API data structures happen to interoperate", and how likely it is that one can convert old runtime state to new runtime state. And that one can be seen as a trade-off; close to the metal control over memory layout is a performance gain, but in practice trades off this kind of flexibility (in theory you could make it work, but it's probably a lot of work).
https://www.theseus-os.com/ is an experimental kernel that can restart/reload/upgrade Rust components at ELF library boundaries. (State internal to a component has to be discarded unless you program a converter. Then again most JS web development hot reload discards internal state of a component.)