noone cares about a marginally less-fucked version of C++

Funny, this is exactly my opinion of Go. Of course, the problem here is:

[Erlang] combines lots of parochial weirdness from both Smalltalk and Prolog (message-passing, image-based live-in sandbox, sentential syntax, etc.) making it very inaccessible to industrial programmers.

and:

[Go] is so very familiar.

And then there is this comment:

If you’re trying to teach concurrency, it helps to be able to focus on that alone and not have to address issues that are really about the platform or syntax or evaluation idiom.

You would understand if you’d ever taught Haskell to undergraduates :)

To my knowledge, I haven’t mentioned teaching at all in this discussion- and it certainly wasn’t what I was thinking about. Yes, Haskell is a terrible teaching language. But then I also think that about Ocaml, Java, and C++. Maybe in their senior year, but not before then. You don’t learn to fly in a 747 for F16, despite the fact that those are what the professionals fly.

So, for an industrial language to catch on, it has to be:

1. familiar, by which we mean not very different from Algol-68 or C++, otherwise it’s just too hard to learn,
2. it has to be capable to being taught as a first programming language, because learning a second language is just too hard, and
3. it has to be backed by a giant corporation, because we don’t trust small corporations or long haired hippy hackers (who are way too likely to violate requirement #1).

Given these requirements, what you’re going to get is slightly less fucked-up C++s. Always. Especially from the perspective of someone who is quite willing to roam farther afield, and who doesn’t think that smalltalk is too weird to be learned.

By the way, there are a lot of languages that compile to native code that don’t have the pointer/value distinction- Ocaml and Haskell being two. Oh, and all those Java native mode compilers, like gcj.

By exposing them, the user can write tight code that making strong assumptions about how data structures are copied, and what kind of memory footprint will result.

This is exactly what I’m talking about! It not only allows the programmer low-level control over how the data structures are laid out, and require the programmer to control how the data structures are laid out, whether the programmer wants to or not!

I’d love to point out a compiler that unboxed non-trivial data structures if the compiler thought it worthwhile, but I honestly don’t know any- primarily because it’s generally not worth it. If you have a copying garbage collector, then if A has a reference to B, generally A and B will be near each other in memory. So you get most of the cache locality advantage of unboxing B into A right there. You save some memory- you have the pointer in A and the per-object overhead of B you could eliminate. But just as often you lose memory, as this forces you to keep multiple copies of B around instead of sharing one B (this is especially true if B is immutable and thus more easily shared). And you complicate the garbage collector, because now the GC has to look not only for pointers to A, but also to pointers to the B part of A. And what happens if a reference to the B part of A outlives all references to A- do you hold on to A as well? The cost/benefit ratio is just too large.

I agree that tail call optimization and pointers both have large impacts on the programming style. So does limiting variable names to six characters. Not all things that impact the programming style are good.

Tail call optimization is about correctness in the face of the lack of language features- not about performance. Loop constructs tend to be imperative in nature. And they also tend to accrue more complex exit conditions and variations- for vr.s while vr.s repeat vr.s do-while loops with return, break, continue, next, previous, etc. continuations. So functional languages tend to ditch looping entirely or severely limit it, and use recursion instead (every loop can be implemented as a recursion). This allows the languages to avoid the complexity most pragmatic imperative languages end up with in their looping constructs. If you had an infinite stack, you wouldn’t need tail call optimization to do your looping with recursion- but since you don’t, tail call optimization is necessary. Not for performance. For correctness. What’s the similar story for Go- what advantage (other than requiring the programmer to lay out his data structures and deal with boxing explicitly) does Go gain from having pointers?

I’d be interested to know why, as you comment, “Erlang ain’t it”

It combines lots of parochial weirdness from both Smalltalk and Prolog (message-passing, image-based live-in sandbox, sentential syntax, etc.) making it very inaccessible to industrial programmers. OTP’s reliability is perfect, but only if you use it as Ericsson intended: it falls over easily if there’s any impedance mismatch in how you architected your system.

Erlang is obviously successful, and will continue to be so for quite a long time, but just in a very narrow category of infrastructure applications.

From where I sit, the three main advantages Go has over various competitors like D and Erlang and Cilk, is threefold: 1, Google, 2, Brian Kerninghan, 3. Rob Pike. In this sense, Go is like Arc, in that the main reason everyone is gaga over it is who is behind the language, not the language itself. If you or I had released Go, it’d have disappeared without a ripple, and no one would care about it. If you don’t believe me, ask Walter Bright. Who’s he? Precisely.

I already knew all about Walter from having explored D, which seems to have been an obvious failure nearly from birth — noone cares about a marginally less-fucked version of C++, especially not one controlled by a proprietary compiler company. Cilk manages to apply that same proprietary stink to a project that already had the innate unsuccessfulness of private academia (see Cyclone for a language that never even made that leap).

It’s uncouth to apply the Arc slur to a language that shipped with two full compiler suites targeting many native architectures, with it’s own complete standard library. Arc is ~100kb of shitty macros that only work on an old version of MzScheme and break its string support.

I am more than a little bit disturbed at the implication that the only way for a language to gain widespread adoption is to have it backed by a large corporation.

I’m saying something else: that a language backed by a tiny corporation is meaningless. I know of three things that can really get a language off the ground: early total openness, backing by a megacorp, and multiple independent implementations.

Yes, as far as I’m concerned, being owned and pushed by a big corporation is a minus for a language. Languages should be open sourced and publicly standardized (ANSI, ISO, ECMA, pick one).

Have public standardization bodies ever been anything but facilitators for corporate bullying? I guess there are languages for which standardization has been a tombstone — Smalltalk multiple times!

The existing industrial languages that are otherwise suitable have tons of baggage: Scala, Clojure, Haskell, and Erlang are all idiosyncratic in their own ways, and all have major features that have nothing to do with concurrency.

Are you seriously suggesting that Go is not idiosyncratic in it’s own way?

Of course it is, but save for CSP (and maybe interfaces), its oddities are ones of omission and clarification. It is so very familiar.

Or that every feature has to be related to concurrency? Including all of Go’s features?

If you’re trying to teach concurrency, it helps to be able to focus on that alone and not have to address issues that are really about the platform or syntax or evaluation idiom.

You would understand if you’d ever taught Haskell to undergraduates :)

Dereferencing is automatic in common cases
No pointer arithmetic is allowed
No such thing as “undefined behavior” — it is possible to manually construct an invalid pointer, but dereferencing one will always cause the runtime to halt

They’re present because you’re going to have to tackle the reference/value distinction somehow, and Go is intended to compile to machine code. By exposing them, the user can write tight code that making strong assumptions about how data structures are copied, and what kind of memory footprint will result.

Pointers are not “just an optimization” — They’re a lot like Tail-Call Elimination — theoretically it’s just an implementation detail, but it’s one that has a massive impact on programming style. Any code that takes advantage of it is invalid in its absence and immune to refactoring it out.

Unfortunately it does suffer from a most intractable problem — timing attacks. Because your code runs directly, you can do things like detect the contents of the CPU’s caches by brute force. Researchers have written timing-based exploits for NaCL, but noone’s found any other ways through the sandbox.

The JVM’s massive girth and added latency make this a lot more difficult due to all the introduced noise, but it’s still possible. That girth also makes it incredibly hard to write nice applets in.