Not just Ada...

Posted Apr 25, 2013 12:21 UTC (Thu) by phred14 (guest, #60633)
In reply to: Ada should be mentioned when speaking of programming languages on safety by lonely_bear
Parent article: A taste of Rust

There was a strong bout of "safe programming languages" 30 or 40 years ago, and it seems that Ada is the only barely viable survivor, with FreePascal also making a minor presence. Now it looks like there are emerging efforts to get to a "safe programming language" again.

Which begs the question... Would it be easier to "make C safe" or to "make Modula-2 or Modula-3 usable"?

I focus on Modula-2/Modula-3 because others have mentioned that Ada has certain deficiencies which ought to be fixed. But Ada is rather rigidly standardized, and though there is a process to eventually change it, that takes time and makes experimentation difficult. Modula-2/Modula3 could make a better test-bed or starting point, recognizing that those would need work, as well. They're also less complex to begin with.

Even the usability argument against the old "safe languages" may have some issues, because while as defined they may not have been usable, most vendors back in the day had significant extensions. Back in the 1980s I used JPI Modula-2 to write a TSR (MSDOS Terminate-and-Stay-Resident, for those who are not fossils like me.) that implemented a reentrant interrupt handler for low-level communications. I also interfaced to a C module for (at the time) high-performance graphics, and both read and wrote legacy binary data files. It could be done, and it wasn't that hard.

Not just Ada...

Posted Apr 25, 2013 14:55 UTC (Thu) by viro (subscriber, #7872) [Link] (1 responses)

And how safe does it remain after you add those extensions?

Not just Ada...

Posted Apr 25, 2013 18:44 UTC (Thu) by phred14 (guest, #60633) [Link]

At least part of the idea has always been to mark those extensions as unsafe. You can't always be safe, but you can at least identify and minimize the times when you're not. You have a better idea of where the dragons are likely hiding.

Admittedly once you're messing with the stack frame, which I was with the interrupt handler, you've kind of unlocked the doors for the dragons, too. But I only played with the stack frame in that one example, knew it was a very risky thing, and tried to use extra care.

Not just Ada...

Posted Apr 25, 2013 17:13 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

The elephant in the room here is garbage collection. It's impossible to make a real and usable safe language without garbage collector of some sort. You might try to get away with reference counting and region inference (like in Ceylon) but it soon becomes too problematic.

Not just Ada...

Posted Apr 25, 2013 18:31 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

Did you mean Ceylon or Cyclone?

Not just Ada...

Posted Apr 26, 2013 14:55 UTC (Fri) by ibukanov (subscriber, #3942) [Link] (2 responses)

Rust model is to use referenced-counted objects for a thread-shared heap and separated GC-heaps for each thread. As long as one keep number of thread-local objects small, the GC pauses should be on the scale of microseconds, not milliseconds, as with typical global GC solutions.

Not just Ada...

Posted Apr 26, 2013 22:20 UTC (Fri) by neilbrown (subscriber, #359) [Link] (1 responses)

This is not quite how I understand the documentation.

The thread-local heap is managed, though they currently use reference counting rather than mark/sweep garbage collection. That might change.

The thread-shared heap is not reference counted. The compiler tracks references of which there may only be on primary reference and possibly several borrowed references that can only exist within the scope of the primary reference. When the primary reference is dropped, the object is freed. No counting.

Not just Ada...

Posted Apr 26, 2013 23:18 UTC (Fri) by ibukanov (subscriber, #3942) [Link]

> The thread-shared heap is not reference counted.

You are right, the ownership is fully tracked with the compiler.

> The thread-local heap is managed, though they currently use reference counting rather than mark/sweep garbage collection.

It is reference counting plus a cycle collector. For practical purposes it is just a form of GC with different trade-offs compared with a mark and sweep case. In Rust the reference counting allowed for simpler compiler implementation as one does not need to track the native register and stack roots. Plus for non-cyclic cases the garbage is collected faster. But when the cycle collector runs, it runs much slower than a mark-and-sweep due to significantly more complex algorithm.