Hi T.J.,

> 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.

Yeah, finer-grained GC control would be good. An "UNSAFE" keyword like
Hendrik pointed out would be a welcome. Also, the ability to control when
and how often the GC gets invoked, and perhaps some static analysis tool
that helps make sure that the GC gets invoked at appropriate intervals
along all code paths, would make it less painful.

I should point out at this time that my knowledge of GC implementations
isn't particularly deep, so maybe these features (or equivalents) already
exist somewhere and I just don't know it :) I know that Modula-3 and
Oberon both have GCs, and complete operating systems have been written in
them, so I suspect that there's an ars arcanum to using them effectively
for systems-level projects (maybe it involves tastefully turning the GC off
in some places?). I'd be curious to know if there's a "lessons learned"
write-up somewhere as to what it takes to make GCs work well in this
context, or a "lessons learned" that explains why these languages' GCs
aren't commonly used today (maybe there are some obscure cases they don't
handle well, for example).

I'm looking forward to seeing the Rust developers' take on this, once they
reach 1.0.

> 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.

These are all excellent points. I hadn't taken a look at the licensing
text myself, but a lack of an irrevocable patent license is cause for
concern.

-Jude

On Sat, Dec 20, 2014 at 6:08 AM, T.J. Duchene <t.j.duchene@???> wrote:
>
>
>
>
>
> Ø 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.
>