Hot Reloading in Swift | Hacker News Reader

Hot Reloading in Swift

merowing.info

99 pointsmgrayson34 comments

Ironically, I think Brad Cox had something like this in mind, after coming up with Objective C. Or at least, pluggable components [1]

I wonder what the threat model would be? Injectable binaries seem like a decent attack vector. But, if we're talking 2040, maybe a signable Merkle tree would do the trick.

Meanwhile, have been experimenting with recompiling Metal code at runtime. Was kinda fun with ObjC/C++/OpenGL, a few years ago.

[1] https://thenewstack.io/objective-cs-roots-in-the-life-of-bra...

Erlang has had hotloading for a long time and seems to be fine security wise AFAIK.

Hot reloading’s quality (and to a degree, security) depends mostly on how fine-grained a change can be. The reason Lisp-REPl workloads are so well loved is that very small scopes can be changed easily, Erlang also has a sane encapsulation that can be swapped without much fuss.

just wanted to say i really like the clarity of that explanation

Most of (traditional) Erlang deploymens are in embedded systems. They have a different threat model.

Erlang has a very limited security model. In the default distribution, any process on any node can spawn a process on any other connected node to run any function --- you can send the function too. Modules can have a function to run on load, too. Loading an untrusted module is asking for that module to take over your whole system. Best to make sure nobody unauthorized can do that.

Objective-C used to support reloading but now explicitly does not (dlclose() doesn't do anything) because it's unsafe.

Xcode used to have these features (called Zero Link and fix and continue) but they were quickly removed because nobody used them.

Hot reloading is typically considered to be concept of swapping out an implementation rather than literally unloading the code from memory. Objective-C is mildly limited by its C heritage but one can go pretty far with runtime trickery to get a similar effect. The other features were removed because they were not fully fleshed out and too unreliable to use.

For iOS, we used some runtime trickery to access private APIs. Was needed to access calendar invite details. Could see how a less benign developer could sneak malicious code past Apple's review process.

A famous example of self-modifying code was Microsoft's AARD code, which was decrypted on the fly to check if the user was running a competitor's OS. [1]

I always wondered if the perceived threat of runtime method constructors was an incentive for Apple to push for Swift.

[1] https://en.wikipedia.org/wiki/AARD_code

Self-modifying code is prohibited on iOS by codesigning. However, achieving Turing complete execution capable of calling any API not behind an entitlement is very feasible and regularly passes App Store review for simple cases. The more complicated ones might too, but they aren't delivered via the store very often ;)

… take me through this? Is it evaluating through NSObject keypaths? I’m a noob and just curious.

Easy one is to embed an interpreter and let it call arbitrary Objective-C code

If you can convert data into an API call, then it becomes an issue of steganography. The only way to trust a binary is through 100% code coverage through all possible inputs, which is intractable.

Code signing and a secure enclave may help protect against local use cases, like ransomware, but doesn't protect against hybrid attacks, like granting access to 3rd parties.

Maybe this means that all binaries in 2040 should be derived from open source with AI doing the threat detection.

  > quickly removed because nobody used them

what is the definition of "nobody"?

n=1 and all that, but as a developer i used it all the time and was totally dismayed it was removed...

If you read the first edition of his book[1], it's pretty clear about what he was trying for, which IIRC was essentially resumable software components as black boxes that you could buy off the shelf and integrate in your own products.

I find this quote interesting:

> But in addition, “I had just become incredibly annoyed with proprietary languages,” he said. Fortran vendors, for instance, would add extra features to try to lock customers into their particular version.

But this is exactly what he did with Objective-C -- it was a proprietary language until NeXT bought his company! It could have had widespread adoption had there been a widely available implementation.

[1] https://archive.org/details/objectorientedpr00coxb

> resumable software components as black boxes that you could buy off the shelf and integrate in your own products.

Wasn't that one of the goals of CORBA? [D]COM?

I know it was one of the lynchpins of OpenDoc, but that took it even farther, with a document-centric approach to applications.

It was, and COM is pretty much alive on Windows as its main "modern" API (in quotes because VS tooling keeps lacking versus Borland/CodeGear tooling, despite its relevance on Windows APIs).

Hot reloading is a user(/developer) facing tool. You open up the application and put some of your own code in it. Platform vendors have almost universally rejected this model because it takes away control from them, but just like all apps load system libraries because they’re signed and trusted the solution here is to allow the hot reloader to add their own root of trust along with the one in the OS. Then you can just sign your own interpositions and load them safely.

This is one of the main reasons I like Common Lisp, and Clozure CL in particular, which has a blazing fast compiler: my debug cycles are measured in seconds. Over dozens or hundreds of cycles it really adds up.

Isn't lisp a scripting language though? Different flavor of language.

I mean JS used to be a scripting language, but thanks to Reasons there's a lot more involved to get fast development cycles.

> Isn't lisp a scripting language though?

No. Where did you get that idea?

You can hot-reload any language that can load a dynamic library. Compile the hot-reloadable portion of your app to a dylib and use a hotkey to reload the lib.

That is only the beginning, isn’t it? The hard part is figuring out how to migrate state, and clearly saying “no” when that fails instead of leaving the user to debug a configuration that could not have arisen had the new code been started from a clean slate. (I don’t think that’s actually possible to disprove, even, but at the very least guaranteeing that memory contains the types the new code thinks it does would be good.)

"Microsoft has been killing it over the last decade regarding dev tooling and experience, so it is not a big surprise."

To be fair, for all the flack Microsoft got/gets, the dev tooling for Windows ecosystem is miles ahead of anyone else and world class. Perhaps I am biased as I worked there at one point, but since I don't anymore, I have also seen tooling from Apple and Google and they are a couple of decades behind. There is some truth to why Steve Ballmer went ballistic with his Developer chant, they really built great tooling for developers.

MS had "edit and continue" (aka hot reloading) in Visual Basic in the 90s. Then I switched to other languages and I've gone without it the rest of my career. I don't think VB the language is very good, but the developer experience still beats anything I've used since then.

With the caveat that Borland is even better before they decided to focus on enterprise customers, and went through all those acquisitions and name changes.

Delphi and C++ Builder are still unmatched in many capabilities on the Visual Studio side.

This is an odd response given the article calls at Google as having the gold standard for this, and I'm not sure there's any equivalent at all at MS? They push Flutter too

You mean like this?

https://docs.microsoft.com/en-us/visualstudio/debugger/hot-r...

"Microsoft has been killing it over the last decade regarding dev tooling and experience" was a direct quote from the article.

Thank you! That context makes it much clearer

Maybe they mean internal at Google? Internal Google tooling is pretty hit or miss, especially with older products that are a patch work of different internal only Google stacks.

The gold standard are Smalltalk and Common Lisp environments, that people pushing Flutter tend to ignore on their marketing, as they ignored the existing work on Java and .NET ecosystems.

There's emoji after "killing it"

I believe it changes meaning of this sentence.

No it doesn't? In that context, "killing it" means doing a great job.

Agreed. Visual Studio is an excellent piece of software, along with .NET and C#.

I think Apple isn't that bad either, yet still behind MS.

Google is a disaster though. A few weeks ago I needed to download Android Studio. Downloaded a clean stable release from its official site for my machine (M1 Mac). From that clean install literally erroring while trying to launch AVDs to cryptic error messages about JDK environments, Google's the only IDE out of these big three where I get countless of errors and losing hours on something that literally doesn't work out of the box.

Hope Xcode and VS never becomes something crappy like Android Studio.

Reply on news.ycombinator.com