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

Strange, that sentence has already been rewritten.

I am surprised that in 30 years since [8] no one took another step toward the result in this new paper.

Actually that doesn't dereference a nil.

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

Why not learn the language before criticizing it?

To be fair, we don't know if `Baz` is a pointer or value receiver in the parent example. So it could: https://play.golang.org/p/fYO8jBbVQ5

That's true, but it's pretty uncommon for a function to receive a value, and if so you either have a good reason for it or you're doing something wrong.

You created a playground that intentionally avoids the nil ptr dereference.

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

You can actually create meaningful implementations of methods on nil pointers.

    if b == nil {
        fmt.Println(":)")
    } else {
        fmt.Println(b.emote)
    }

In this case, that's useless, but that's an artifact of the chosen example. I use it every so often in places where it happens to have meaning.

Go often treats nil as a legal value, which means that some of the things you might expect to crash don't, and when used idiomatically can sometimes make for shorter code. For instance, the "length" call on slices will happily take a nil and return 0, you can "append" to a nil slice and get a slice back, etc. Ultimately it's still a language with a null in it, though. There's no non-nil pointer type.

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

That's why we have the 'weak' keyword ^_^ I'm confident any algorithm you want to design for a GC world can be implemented in an ARC world, maybe with a tiny bit of tweaking. It's not that there's 'no need for GC' its just that there are many ways to solve a problem.

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.

Obviously you could implement any algorithm using reference counting instead of garbage collection. The question is whether or not you really want to pepper your code with what is essentially manual memory management when necessary.

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