Hacker News Reader

Comment by steveklabnik | Hacker News Reader

  > they still result in code being inserted to do things like deallocate objects at run time.

I mean yeah, functions are called at runtime, just like every function. The key is more like static/dynamic typing: is the decision to call the destructor at all determined at compile time, or at runtime?

(and millstone has been making good points about drop flags on this thread, but that's still only in fairly niche cases, only one bit, and is an implementation detail more than a fundamental aspect of the language. We've had several different variants of drop flags over time, and it's going to change even more in the future, as erickt says.)

  > Swift and Rust are far more similiar...

Agree wholeheartedly.

View on HN

"but that's still only in fairly niche cases, only one bit, and is an implementation detail more than a fundamental aspect of the language."

Ok, but isn't the question of whether or not something is done at compile or runtime always an implementation detail? The fact that Rust figures out at compile time whether or not to insert the deallocation functions is super awesome, but it doesn't actually change the semantics of the language relative to if has to check flags or reference counts etc.

This is different, to my mind, from static/dynamic typing because they have very different semantics. Early versions of Java used a VM which was dynamically typed, and PyPy converts python code to machine code that doesn't check types (if I'm lucky). So the distinction really isn't whether or not the decision is made at runtime.

But really, I only objected in this thread because the claim was made that Swing and Rust were very different because Swing had GC and Rust didn't which seemed to be overemphasizing the differences here.

> Ok, but isn't the question of whether or not something is done at compile or runtime always an implementation detail? The fact that Rust figures out at compile time whether or not to insert the deallocation functions is super awesome, but it doesn't actually change the semantics of the language relative to if has to check flags or reference counts etc.

There is no concept in Swift of a dead object that is in scope. There is in Rust, which is why you see "use of moved value" errors. That is a language difference.

"Ok, but isn't the question of whether or not something is done at compile or runtime always an implementation detail?"

No it isn't. It changes the entire semantics of your language. For example Python as it exists today simply can have neither type checking nor GC decisions* done at compile time. The language is not capable of expressing those things adequately. Adding those would require some significant changes to Python the language, its stdlibs, as well as the Python VM.

Conversely, starting to use reference counting in Rust is definitely possible but will jack up your memory-related bug count, a rather undesirable result. The code is also pretty much always more difficult to read, understand and debug. Its only redeeming feature is that some datastructures simply need the flexibility it brings.

* I define a GC decision as deciding what to de/allocate and when to do it, rather than performing the de/allocations themselves. For example, the GC algorithms in Java and Go fall under this definition, as does Swift's ARC mechanism, as well as Rust's ownership based decisions. The former 3 decide at Runtime. Rust usually decides at compile time, the only exceptions I can currently think of being code based on the Rc/Arc/RefCell types, which do reference counting and therefore the de/allocation decisions are deferred until runtime.

Reply on news.ycombinator.com