4 ms·

This sounds very nice, but just to make sure I understand your meaning: If you have a properly designed "systems" programming language(even if manually managed)

This sounds very nice, but just to make sure I understand your meaning: If you have a properly designed "systems" programming language(even if manually managed) you would release resources exactly(or nearly so) at the time when a proper ARC/RAII implementation would. Is that correct for your meaning? If so I fully agree.

twoodfin 4y ago
My point was that if by “systems” programming, you mean prioritizing efficient use of limited system resources (CPU cycles, bytes of memory, … ) then there’s no superior alternative to the precise control & reliability afforded by ARC/RAII.
ncmncm 4y ago
At this late date, a language inadequate to express ARC/RAII is better described as a toy. There is nothing wrong with toys, but they are not to be confused with professional tools. A systems language is, first and foremost, a professional tool.
jandrewrogers 4y ago
It is more subtle than this. Systems programming sometimes involves a resource life cycle that has semantics that map neither to a GC nor RAII/ARC. This is because systems programming often involves the direct management of hardware resources, like storage. For example, while resource acquisition and release may be deterministic, there is no implication that a released resource may be immediately reused or reacquired. This is not pattern most software engineers are used to. The reason for this is that hardware may hold a lingering reference to a software resource even if the software does not -- and hardware doesn't use reference counters or destructors. An arbitrary amount of time may pass between a resource being released in software and that same resource being available for reuse again in software. Many people new to systems engineering make the mistake of reusing a resource that was released but not reusable. Systems programming languages don't just ensure deterministic release of resources, they also need to provide a way to express that the hardware may hold references to objects the software has fully released such that it isn't really released. This is not something the average programmer has to deal with, but this is part of what makes systems engineering different.

twoodfin 4y ago

My point was that if by “systems” programming, you mean prioritizing efficient use of limited system resources (CPU cycles, bytes of memory, … ) then there’s no superior alternative to the precise control & reliability afforded by ARC/RAII.

ncmncm 4y ago

At this late date, a language inadequate to express ARC/RAII is better described as a toy. There is nothing wrong with toys, but they are not to be confused with professional tools. A systems language is, first and foremost, a professional tool.

jandrewrogers 4y ago

It is more subtle than this. Systems programming sometimes involves a resource life cycle that has semantics that map neither to a GC nor RAII/ARC. This is because systems programming often involves the direct management of hardware resources, like storage. For example, while resource acquisition and release may be deterministic, there is no implication that a released resource may be immediately reused or reacquired. This is not pattern most software engineers are used to. The reason for this is that hardware may hold a lingering reference to a software resource even if the software does not -- and hardware doesn't use reference counters or destructors. An arbitrary amount of time may pass between a resource being released in software and that same resource being available for reuse again in software. Many people new to systems engineering make the mistake of reusing a resource that was released but not reusable. Systems programming languages don't just ensure deterministic release of resources, they also need to provide a way to express that the hardware may hold references to objects the software has fully released such that it isn't really released. This is not something the average programmer has to deal with, but this is part of what makes systems engineering different.