Today I've started a Wave with some of my friends to discuss the recently revealed google programming language called Go.

I've started reading the Language Design FAQ, maybe not the best place be it got my attention first. The first highlights on this document I found most interesting:

it generated C code as its output

Go is an attempt to combine the ease of programming of an interpreted, dynamically typed language with the efficiency and safety of a statically typed, compiled language. It also aims to be modern, with support for networked and multicore computing. Finally, it is intended to be fast: it should take at most a few seconds to build a large executable on a single computer. To meet these goals required addressing a number of linguistic issues: an expressive but lightweight type system; concurrency and garbage collection; rigid dependency specification; and so on. These cannot be addressed well by libraries or tools; a new language was called for.

... there is no type hierarchy: types just are, they don't have to announce their relationships ...

Why do garbage collection? Won't it be too expensive? ... The current implementation is a plain mark-and-sweep

They gotta invest a lot of effort on the item above :)

Of course, implementing garbage collection in a concurrent environment is itself a challenge, but meeting it once rather than in every program helps everyone.

Go's built-in maps and slices, plus the ability to use the empty interface to construct containers (with explicit unboxing)

Why is there no type inheritance? there are no explicit relationships between types and interfaces, there is no type hierarchy to manage or discuss.

These two still 'mystic' languages for the most of us: {Erlang, Occam} share with Go the idea of some builtin concurrency support:

One of the most successful models for providing high-level linguistic support for concurrency comes from Hoare's Communicating Sequential Processes, or CSP. Occam and Erlang are two well known languages that stem from CSP. Go's concurrency primitives derive from a different part of the family tree whose main contribution is the powerful notion of channels as first class objects.

Finally this well written article [Why GO Matters] points out (along with Serodio at our Waveshere) that Go niche is of Systems programming, in his words:

What’s a systems programming language? It’s the kind of language you use when writing a new OS. Or a device driver. Or an I/O stack. Or a piece of networking middleware. Or a very fast web server.

Are we facing the beginning of the end of the C++{0x} era? And did Language D has lost momentum?

Simon Peyton Jones talks about the right measure of success and hence freedom a programing language should have to evolve without the chains of backward compatibility.

As for the second, I don’t know if you know this, but Haskell has a sort of unofficial slogan: avoid success at all costs. I think I mentioned this at a talk I gave about Haskell a few years back and it’s become sort of a little saying. When you become too well known, or too widely used and too successful (and certainly being adopted by Microsoft means such a thing), suddenly you can’t change anything anymore. You get caught and spend ages talking about things that have nothing to do with the research side of things.

Simon works in the design and implementation of the GHC, which is a state-of-the-art, open source, compiler and interactive environment for the functional language Haskell.

A very interesting interview with Bjarne Stroustrup:

HD Have we placed too much emphasis on architecture?
BS No, at least not the way I would define architecture. On the contrary, there is too little emphasis on architecture and too much poor coding with little understanding of structural principles. I suspect a major problem with architecture is that many programmers have only a vague idea of what makes good code good. Being able to recognize it when you see it is not enough. Having rules for what not to do is not enough. We need articulated prescriptive rules.

HD Do you see a serious shift towards dynamic languages in the near future?
BS Not really. I think people are comparing apples and oranges too often. I don't think we have a choice between static and dynamic languages in general and furthermore I don't think languages cleanly fit into those two categories: most if not all dynamic languages have aspects that are statically determined, and all the major static languages can do things that require run-time determination of the meaning of values. There are fashions, of course, and I can't guess about those, but I think that many real-world language choices are rationally made based on the requirements of an application, an application area, and/or the skills of the available developers. For example, I'd not try to implement a Java runtime in (say) Ruby or express a heavily interactive simulation language as C++ (as opposed to its implementation).

From ./, the return of Ada:

"Today when most people refer to Ada it's usually as a cautionary tale. The Defense Department commissioned the programming language in the late 1970s but few programmers used Ada, claiming it was difficult to use. Nonetheless many observers believe the basics of Ada are in place for wider use. Ada's stringency causes more work for programmers, but it will also make the code more secure, Ada enthusiasts say. Last fall, contractor Lockheed Martin delivered an update to ERAM, the Federal Aviation Administration's next-generation flight data air traffic control system — ahead of schedule and under budget, which is something you don't often hear about in government circles. Jeff O'Leary, an FAA software development and acquisition manager who oversaw ERAM, attributed at least part of it to the use of the Ada, used for about half the code in the system."