throwa990323249

The paper addresses that directly:

"Thus, while our proof of RH might look too short to be true, it really involves at least two rather long papers [6, 8], not to mention [9]."

Actually that doesn't dereference a nil.

https://play.golang.org/p/cjmflMBhF7

Why not learn the language before criticizing it?

>The language itself not much. It doesn't offer anything new that Java 1.0 with Quasar doesn't already have.

It offers lots of abstractions Java didn't/doesn't: Lots of concurrency features, Ad hoc interfaces, Closures, Stack resizing, Type switches, Multiple returned values, Slices.

Chicken and egg... But if there was good Python 3 support maybe more companies would contribute.

I too want 3.3+ support but I know some claim that there's very little demand from people actually doing something with PyPy for Python 3 support. I really think it may be a chicken and egg problem: that is, support will generate demand.

In any case the 3.3 branch seemed good when I compiled it last, it'd be nice to see a partial release.

ARC languages are Turing complete, but some algorithms require more than just "peppering weakrefs" and actually require you to essentially build your own GC.

Your "confidence" is wrong.

Consider a graph which can have nodes added, and edges added or removed. Say you want to keep track of the part of the graph that is connected to a node.

You can't know ahead of time which references can be weak. So all must be strong and you will leak memory when a circular part of the graph becomes disconnected.

In general, garbage collection is a difficult problem that solves a lot. You can't trivially do without it. It's not just a tool of laziness.

ARC won't work when you cannot determine ahead of time where the cycle can end safely. Pretty sure for an interesting set of algorithms this is a problem.

It's something I find annoying about some ARC/Rust enthusiasts: their belief that because they haven't found need for a GC, that there isn't one.