Ø Sorry for the terse reply at first; I didn't have a lot of time to look
at it in great detail (I've only read the first few sections and conclusion
so far). I must also confess that my domain of expertise is in distributed
computing, not programming languages, so please take my thoughts on this
work with a grain of salt :)



Oh that’s fine. In many ways, I suspect your knowledge surpasses mine. I’m
more of a generalist, who knows a little of everything, and all of nothing.
I’m more comfortable with language semantics, but a lot of that probably has
to do with the fact I spent most of my college years in the English
Department, as much as in the Engineering labs.





Ø If I understood correctly, the researchers created and evaluated a hybrid
static analysis/runtime verification technique (a compensation stack) that
allows a program to guarantee certain safety properties regarding resource
usages. They focus specifically on exceptional cases where resource
availability changes due to external factors beyond the program's control
(such as disk I/O failing, or a network partition occurring). From a
practical standpoint, the system focuses on ease of use: the developer
writes a safety policy and declares which (supported) resources a set of
methods can access, and the compiler ensures that the resulting program
exhibits behavior consistent with the policy.



I confess that I was mostly interested in the techniques that they used to
manage external resources in exceptions and avoiding cascades. I found it
very interesting that they were focused on reliability.





Ø I would totally use a system like this for distributed systems
programming. I read a paper a while back that suggested that major errors
in popular distributed systems come from not handling certain exceptions
correctly [1]. It would be interesting to see what percentage of these
errors would be handled by the technique presented here, and I suspect this
technique would go a long way toward mitigating them.



I only skimmed it myself so I expect that you gleaned more from it than I
did.



Ø Personally, I try to avoid exception-handling altogether when possible in
favor of plain old C-style error codes. I don't like how the non-local
nature of exception handling can allow an uncaught exception to propagate
through the call stack and get caught (and incorrectly handled) somewhere
else. As such, I make it a habit to encapsulate all "unsafe"
(exception-generating) behaviors like I/O into their own methods with
catch-all exception handlers to keep their side-effects isolated and easy to
reason about, and I try to do all unsafe behavior in one "big step" so the
program can fail fast before taking any partial actions on it (heh, maybe
one day I'll go full FP).





I agree. However, I should note that IF I understood the paper correctly,
some of their suggestions have not been ignored. C# for example, has a
“finally” construct that is executed regardless of whether a catch is made,
which can be used to make sure that resources are released.





Ø I'm not really a fan of garbage collection for system-level code (I just
use valgrind instead to catch leaks early and often), but can .NET actually
leak memory?

Oh my, yes!    In the case of .NET,  there are  resources that the garbage
collector cannot reclaim, such as file handles or any objects that  use
“unmanaged” libraries. If not properly handled, these things can leak when
exceptions are called or collection is performed.

> What's the point of it having a garbage collector then?

Any language can leak memory.  Contrary to popular belief, garbage
collection (aka GC) is not the “end all problems” solution for memory
management.  In fact, it can be fairly flawed and sometimes worse than the
traditional C malloc or C++ new, and is generally an expensive feature in
terms of execution efficiency.  What is really a matter of annoyance are
potential flaws in languages that use or require automatic collection as the
default.   You won’t be able to repair those leaks without access to the
source for the runtime.    I suspect that is why C++ still does not have GC
even though a number of younger programmers have asked why.

I’ve a strong dislike for any language that forces you to use any form of GC
over manual release. GC is sloppy, habit forming, and generally a bad
design paradigm. I’d rather have the compiler flag it, and refuse to
compile.





Ø Heh, good thing the CLI got open-sourced--at least we can fix it if so!


As far as this new initiative goes, I have yet to see a RAND patent grant in
writing. Then I’ll be convinced. Just because they are opening the code
for the CLR and for the experimental Roslyn compiler does not mean that the
language specifications other than v2 will be unencumbered or even
completely licensed. As with all things corporate, read between the lines
and do not trust a thing they tell you, unless they are willing to put in an
ISO/ECMA spec. Such a spec requires that they give everyone an irrevocable
license to whatever patents are involved.

Past efforts, like the Microsoft Open Specification Promise were essentially
a worthless PR stunt. The only patent protection that you have in regard to
.Net is what has already been essentially granted as part of ECMA/ISO
specification from 2006, that .Net v2. There are large portions of the
specific libraries missing from the spec that make certain that .Net
anywhere else other than Windows will always be incomplete and never a fully
cross-platform solution.

I have to work with .Net for Windows, but quite frankly I wouldn’t touch it
with a 50 foot pole anywhere else, including Mono. On Windows, the .Net
license covers you, but only there. It makes no sense to use a language
anywhere that can open you to a lawsuit. IMHO, the same essentially goes
for any language that does not have an official ECMA or ISO spec. Examples
would include such things as Python, C# 4, or Java.

Regardless of whether it is opensource or not, patents and other rights can
be asserted against the language, and thus against you or anyone else using
it.