4 ms·
Yikes, I don't see any legitimate use for this, other than hacking for the sake of hacking. Interesting read though.
by pstuart 8mo ago
Yikes, I don't see any legitimate use for this, other than hacking for the sake of hacking. Interesting read though.
- maccard 8mo agoHot reloading for development loops is _the_ canonical use case for this.
- throwa356262 8mo agoWell, we are on Hacker News after all...
- antonvs 8mo agowdym, now it will be possible to implement Wordpress in Go
- lokar 8mo agoI’ve seen this in large C++ systems to allow for a runtime patch, generally to add a simple debug call at the start of a function.
- jerf 8mo agoWhile I would never consider this approach advisable in any language that doesn't build in support for this sort of thing from the start, the thinner the runtime, the less dangerous it is. Go's runtime is fairly thick, and also, concurrent. The odds of something blowing up are rather too high for me to even dream of putting something like this into production in Go. In C++ it may merely be somewhat crazy rather than completely crazy. (I suppose Rust is arguably an exception to this; thin runtime, but there's a lot of things the replaced function could do that would still blow Rust up if the rest of the code isn't compiled and correctly optimized to account for whatever the new code does.)
- lokar 8mo agoYou just put in a few NOP instructions at the start of each function to give yourself room :)
- xmcqdpt2 8mo agoIn Java you have instrumentation agents that can do arbitrary code rewrite at runtime, including for code that has already been JITted (causing a deoptimization of it). It's first-class supported, unlike in Go. It's used extensively to (for example) add debugging or tracing to functions in libraries or to sanitize certain code path. At work, we were able to kill off jndi from Log4J to prevent Log4Shell within hours of the announcement this way while waiting for updates of thousands of dependencies.