Lambda the Ultimate

There was quite a bit in the text that I'd agree with, including the reason he gives for C++ programmers not liking Go (although IMHO he misses the other half of the reason, which is that Go doesn't improve over C enough to really make it worthwhile for many).

But the part you quote struck me as confused as well. That criticism indeed is about nominal classes and subclass hierarchies, not about types or parametric polymorphism.

Also, that "someone" mentioned in the first paragraph is right. I have yet to see a safe typed language that got away with not having something akin to parametric polymorphism eventually. In fact, I know people who work with Go on a daily basis and think it sucks big time, a major reason being the constant need to downcast from interface{}.

I have yet to see a safe typed language that got away with not having something akin to parametric polymorphism eventually. In fact, I know people who work with Go on a daily basis and think it sucks big time, a major reason being the constant need to downcast from interface{}.

I've spent about 100 hours rewriting some Java code in Go and that's true (that you are frequently forced to downcast from interface{}).
OTOH, it's not a major issue for me, just like it wasn't a major issue for me in Java 1.

The Go FAQ recognizes the issue and says that generics may be added at some point...
http://golang.org/doc/go_faq.html#generics

Considering how Java generics turned out I am fine with the Go team taking the time to think about a proper design for generics in Go :-)

Java is a good example, but you are drawing exactly the wrong conclusion. The reason Java generics turned out sub-par is mainly because they were added too late! They had to work around all kinds of language design and infrastructure legacy at that point. Compare with C#, where generics were put into the language early on and integrate much nicer. That is, generics should be designed into a language from the very beginning, and not as an afterthought.

Actually we should speak of .NET generics. More specifically .NET 2.0. That's the version of the runtime that introduced explicit support for them.

.NET 2.0 generics aren't erased and an oft-claimed point of .NET/C# doing better than Java is that it's mainly because of this design choice to have the runtime reify both the generic types and their instanciations, including reflection support, on behalf of the .NET languages compilers/interpreters, relieving the latter from the burden to make their own choice (in possibly would-be conflicting fashions). The whole core point of .NET right from the start was not "one language to rule them all" (e.g., C#) but rather "one runtime to serve them all" ("them" : the .NET languages, that is). Compare this to Java, which, from its early design, didn't pay much attention to have the JVM serve other purpose than just the Java language itelf. Or maybe I missed something.

I don't know if the non-erasure argument really holds, I'm no theorician, but I agree that the .NET generics had triggered thorough research and usability work as early as soon after .NET 1.0 release (circa 2001) and were not added "at the last minute" when .NET 2.0 shipped 5 years later. Actually, MSR practically haven't stopped designing and implementing the .NET 2.0 generics as their almost exclusive focus, between the .NET 1.0 release and the first v2 betas in late 2004.

It's known they couldn't use HM type inference for instance in the case of C# (they had to craft their own algorithm) but they sure wished they could have. Anyway C#, thanks in part to the .NET 2.0 generics, has known several, rather "successful" (though it's always a bit subjective) incremental enhancements ever since C# 2 : C# 3's Linq-to-XYZ comprehension syntax and extension methods being one of the famous. C#/.NET 2 generics probably played as nicely as they possibly could to allow and integrate with these additions to the language, which btw aren't absolutely C# specific in fact: even that weird VB.NET (just IMO, a language I never liked) could make profit of some.

It seems to have been seamless enough for them to build on top of .NET 2, at least in those respects.

Actually, although Microsoft always claimed that .NET is language independent, they never really delivered on that. I would argue that all those popular .NET languages are either variations of C# (especially VB), or foreign languages with three quarters of C#'s object system bolted on (e.g. F#).

Back in '99, when .NET was still called Lightning, there was an attempt by MS to get other languages on board, and encourage language groups from around the world to port their languages to the platform. Some tried, but it did not really work out all that great, both because the platform wasn't nearly as universal as they had claimed and because the core development team had other priorities than making it so.

Well, ok, up to some extent that one can always wish for to go beyond, I suppose (e.g., I, too, yes).

Question, though: which other runtime and/or platform is more language independent than the CLR + CTS can we use today?

I'm interested.

None. Except assembly code (or maybe C--). Having been involved in a related project a long time ago (and also in the aforementioned MS initiative), my conclusion is that language-independent VMs don't work. At least not on a level high enough to allow useful cross-language interoperability. Impedance mismatches between different languages are just too significant, and even small ones are already enough to preclude anything that goes beyond simple exchange of primitive data.

Perhaps not popular, but the Integrated Language Environment (ILE) for IBMi is an example of an environment that allowed for multiple languages to coexist and call between each other in a fairly seamless manner. This is a biased option, though as I worked on the C and C++ compilers for ILE in a previous life.

Descriptions and documentation can be found here:

IBM Information Center

Search for "ILE Concepts."

I would argue that all those popular .NET languages are either variations of C# or [...] with three quarters of [its] object system

To be honest, I must say I ve made for myself pretty much the same observation, actually.

Two things, though. First, this strongly C# flavor/influence found in today's .NET Babel Tower is maybe a consequence of C# being somehow "naturally" the canonical language first (arbitrarily) chosen (by MS) to reflect the set of new features of its underlying platform. It happened 3 times already: .NET 1, 2, and 4, with the corresponding C# "ambassador" versions.

C# is seemingly the privileged .NET flag holder. I d venture that .NET language designers, consciously or not, have hard times to detach themselves from C#'s way of phrasing the CLR capabilities to the programmer (in a human readable source syntax).

Second, two notable exceptions to this point of ours, however.

The first is the example of Eiffel (okay, yes, "just" yet another OOPL), which well before .NET or even Java *, didn't fear to investigate really non trivial matters all at once (multiple inheritance, generics, feature renaming, operator overloading, etc, etc).
And I remember reading a pretty enthusiastic Bertrand Meyer, in his article on "The significance of .NET".

Meyer's baby is Eiffel, more than anything else. He never wrote the same about the JVM for one, or that I know of.
My impression is that he was writing mainly from a language designer and implementor point of view. I don't think Meyer ever cared much about C#, for instance (though he stayed polite about it :)

The second is even more interesting though it's not a general purpose language:

XSLT in .NET 2 was heavily refactored, wait, redesigned and reimplemented actually, to compile to IL (compiled on the fly, then cached) mostly to address performance concerns from the first try they made at it in .NET 1 (which was basically "just" a very sophisticated tree visitor + rewriter pair written in C# only).

As you know, even if a DSL, XSLT is considered much more functional than anything (it could have been).

I agree .NET somewhat disappoints a bit as far as language inventivity goes to build upon it, but there are still interesting uses of it ... from time to time.

EDIT
* let's recall that Eiffel's design inception/effort dates back... to the mid 80s; an oft-forgotten fact.

"generics should be designed into a language from the very beginning, and not as an afterthought."

Er, yes. Retrofitting generics into C++ made the language far more complex. Before generics, C++ had too much unchecked downcasting.

(The other classic language design mistake is not having a Boolean type. One is usually retrofitted later, and the semantics are usually slightly off for reasons of backwards compatibility. This happened to Python, C, LISP, and FORTRAN.)

The Go FAQ recognizes the issue and says that generics may be added at some point...

That's not a good sign. The retrofit of generics to C++ was preceded by a denial that they were necessary, and followed by attempts to use them as a compile-time programming language. Neither was pleasant.

There are languages that don't need generics, like Python. And there are languages that had them from the beginning. It's better to pick one of those alternatives.

(The other classic mistake in programming language design is having to retrofit a boolean type. That usually results in weird relational operator semantics.)

Google was silly to let Pike design a language. No sum types or polymorphism? You have to be joking. Pandering to object oriented paradigm? There's some good stuff in there, but please, can't we get designers that at least *respect* theory, even if they're not theoreticians themselves?

The fact is, whilst it's arcane, messy, and broken, C++ has more than mere data polymorphism: it has some capabilities to handle functorial polymorphism. It's not up to Haskell's standard but it's better at it than Ocaml.

I would say the remark that Go doesn't go far enough is a better description of the problems in D which does, in fact, improve on C++ .. just not enough to bother with.

I've re-read more attentively Pike's points. He shouldn't be surprised, indeed.

Well, I used to be a C++ programmer in my early career. Not out of choice but out of necessity. That was my company's and team's prior choice.

If I were still busy with C++ today, I can see easily why Go would fail to convince me that I need it.

On his type taxonomies point (that things shouldn't be all about that, only) :

Let's not be hypocrite. I don't know any seasoned C++ (or Java, or just "OO programmer", for that matter) who is not well-aware of the limitations and bias in OO languages' way of seeing the world (that is, the programs' problem domain) as "taxonomies".

Of course they do. Of course they know that modeling the software's problem domain as hierarchies of objects is intrinsically limited and biased, if only because, before anything else : it's mostly arbitrary.

Or if they don't, then I'm sorry, but "they ain't seasoned", precisely. They're still in their junior times and haven't been biting enough of the OO bullet, or they have vastly misunderstood what OO is not about. That it's not about finding the faithful "taxonomy" to the given problem, because such thing won't exist beyond the first edit of the documentation when you allow, upfront, your object types and modules to be both closed and open.

That's not OO design premises to find the golden taxonomy. The premises are weaker instead: pick up any taxonomy you see fit, then make sure you keep things manageable and under control, with no hidden contracts, or, no better, violated contracts. Also, try learn from the FP folks and keep state in general, and state mutation in particular, as controlled and explicited as you possibly can. Even better, just get rid of state and state mutation whenever you can afford (granted, easier said than done: end user requirements are rarely directly translatable in pure functions).

But then, you'll hopefully debug a little less over what the implicit OO's design bias in modeling the world (sometimes telling or assuming too much about systems' state) is forcing upon you anyway.

Yet, he writes :

If C++ and Java are about type hierarchies and the taxonomy of types, Go is about composition.

Okay, then, but which kind of composition are we talking about here?

Pike seems to view compositions as something that should only be about composing contracts. So, exit behavior reuse ? Why so ?

That's rather too bad news for C++ programmers who do like the freedom to think in terms of well defined behavior reuse sometimes.

Thus, is it that much difficult to achieve ? Even if willing to surrender on the issues introduced by the support for multiple inheritance or even, repeated inheritance, and sticking to a simpler, single implementation inheritance scheme, I would argue that it's not.

Maybe it was somewhat overlooked discipline issue in the early days of, say, Simula 67. But we know a little bit better today. Some languages have already scouted there.

I can see where Pike is coming from and where he wants to go re: more language-driven discipline by less features, but...

I know a language that allows you, if you really care about not having a part of a class' members be misused or inherited by clients or heirs, to stay hidden in that class, and if someone really wants to use and, prior, knows about that part of the implementation, then to do so only through a disciplined contract.

They have to make it very clear : they can only make profit of that part of the class' behavior via an interface.

It's not used frequently, but it's sometimes very useful and very specifically for this purpose and sort of concerns, without requiring you to make much more involved member visibility choices like "private vs. public vs. protected vs. internal".

And it's called, well, "explicit interface implementation".

Easy to look up.

I feel like I should not just post a negative comment about Go without mentioning that I really like Go, and I will definitely be using it more in the future.

I have a lot of 'enterprizey' Java experience. I appreciate Java's static typing but not it's verbosity.
I find the combination of closures, goroutines, and type inference in Go to be thrilling.
Often, after writing some routine in Go, I marvel at the conciseness and clarity of the resulting code.

Sorry for pedantic ranting about a pet peeve of mine, but Go has no type inference. Nor does C++11. What some language communities sell as "type inference" these days is trivial bottom up type derivation for simple expressions. You talk about type inference when type information can be derived non-locally, and from use sites, not just from definition sites. Litmus test is whether you can omit the parameter types from a function, for example.

Would you consider inference of type arguments in parametric polymorphism to be type inference? I do. In Virgil you can't omit types from parameter declarations but you can omit them from uses of parameterized methods and classes, including applications and partial applications. The algorithm to infer the type arguments is much like unification.

But I agree that Go is not object-oriented (they have once-in-a-while described it as such), nor does it have type inference (they often claim this).

Yes, valid point. When you have parametric polymorphism, more is going on. Go does not have that, but C++ does (provided you are willing to count templates). For clarity, I'd still avoid calling it "type inference", though -- it's just inferring the type instantiation, which is only a small part of the full thing, and a very local affair. The C++ crowd calls it "template argument deduction", which seems adequate.

local type inference is a feature in its own right.

Right, and it is used in languages like Scala or (too a much lesser extent) C#. Both pass the litmus test I mentioned, at least in simple cases.

Unfortunately C# only allows this feature to be used for lambda expressions, and not for methods.

Go doesn't really internalize type hierarchies as such. All of the relations between types are boiled out by the time it emits opcodes. Its polymorphic routines are called directly. Although they may be identically named, they actually have no code in common, not even a dispatcher.

It was someone's design decision to have that property of the runtime model reflected in the source code. I respect that, although I feel your pain. I think that interfaces are, to some extent, semantically "cleaner" or "simpler" than inheritance. But when not supported by implementation inheritance they are inevitably more work.

Inheritance of implementation and the resulting labor savings is one of the strongest arguments in favor of type subclassing. What lazy programmers do for its sake when there actually isn't a clear "isa" relationship between two (or more) types is one of the strongest arguments against it.

I think that test code to assure that different implementations of an interface actually mean the same thing, should be "inherited" from interfaces. For example, I think a type with an "addition" interface should inherit (from the interface!) a 'test_addition' procedure which assures that the "addition" implemented by something claiming to use the interface is in fact associative and commutative. I know what you may be thinking, but vector addition on the surface of a sphere, and other such things, do not actually have the same semantics that we think of as being addition. And something that implements a "container" interface ought to inherit a "test_container" procedure that makes sure of things like an empty container which undergoes an insertion becomes a container with one member, and that when a container has had some known element added to it, that element must appear if its contents are listed and so on.

Of course, if there were a way to inherit code from interfaces, people would insist on defining the implementations in the interfaces. Which, depending on your POV, might defeat the point of having interfaces in the first place.

Ray

Go allows some non-constant expressions outside of function declarations to initialize package scoped variables.

Thanks

Ah, a wisdom comment of yours I can relate to, a lot.

The success of the announced and advertised inception of a new language depends indeed a lot on social factors, and for some largely out of reach of any objective, if not just rational, arguments.

A new language really needs to do better and blindingly demonstrate its potential or observable effectiveness at today's problems.

Let's not forget it just even takes a while for a language to be understood in its full potential. Look at Javascript, with all its flaws, but also qualities, that most have misused for a decade before a couple simple patterns be unearthed to keep things written in it cleaner or more manageable.

An oft-heard argument is it's somewhat wrong for a language to have a whole bunch of features rarely or very rarely used. But why so? Of course, if out of 40 keywords, you end up using less than 10 most of the time, something is likely clumsy with your language choice in the first place. But otherwise, what do we do? We program. And as much as we don't need to use, by far, the full set of English nouns and verbs even for vastly different communications, why would I care not using yield in C# that often, let alone other specifics such as the new() constraint on generics? Very most of the time, our design or implementation is fine enough with a more or less humble subset of the full language.

As a early adopter of C# back in late 2000, out of the then codenamed NGWS, I gave myself three full days of studying those unstable experimental compiler and libraries, even tweaking in ugly ways my then Windows 98 to just be able to play with it on the command line. I didn't care about the commercial argument package of MS on how it would bring revolution to the web, etc, blah blah.

All what I wanted to see is what Anders had been busy with after his "betrayal" or kind of, of the Borland Delphi folks 3 years earlier. I wanted to know if some rumors about a better design than Java, the language, were true. So I picked every thing I didn't like or had found clumsy in Java and looked how C# would see things.

I liked what I saw. I had no idea and no specific hope for .NET otherwise. But if, say, C# would be wanted, I knew that at least I would enjoy and feel safer with it than with Java, about which I, too, was maybe seen as a bit cretin not to find "wonderful".

The difficult part is having the language be really innovative in its ways to even allow subsets of it already more useful than the competition. Then yes maybe you can have a chance to overcome the social factors resistance. But it's never immediate anyway.

I don't want you to get the idea I'll never respond. I just don't post unless I have something to add. Responding is flattery enough; remarks about wisdom make me wince. (If you write clearly, people like what you say, even when commonplace. It's like a weird inverse effect of the world view phenomemon. Often folks refuse to understand unless they agree; so if you can get them to understand, they might agree out of habitual association.)

YSharp: A new language really needs to do better and blindingly demonstrate its potential or observable effectiveness at today's problems.

Or ... you can probably get one to take off with funny false social proof. I'm imagining a television commercial for Go featuring incredibly competent Australian commandos from World War II, in a plane returning from a mission, who praise Go as a blinding 'chutist (as if Go was a person, of course). It would be weird, and therefore appeal to geeks. Extremely dry and reserved praise would work best, and be slightly funnier.

(Or you could write Go tutorials in T.H. White style, as conversations between Merlin and Arthur as if pulled from the pages of The Once and Future King, suggesting the idea Arthur can't be effective as king without a jolt of Go under his belt. A little creativity goes a long way, and alleviates the boredom of tech documents. I basically like all anachronistic jokes based on the idea programming has been around for 100's of years, to the extent of turning the tide in ancient battles, like English long bows.)

I read all your remarks, except the ones very heavy with densely packed acronym references to .NET and such, which taste like politics to me. For example, suppose I wrote a post that mentioned several American president names, with a few references to Stalin and Marx, with occasional references to the Constitution. Your internal Bayesian spam filter would route it directly into the nutball category. You wouldn't read it unless you suspected I was being funny. Similarly, you don't want folks to skip your posts as sounding like "Microsoft stuff" if they suspect it's easy to categorize.

Lol !

Did I give you the impression I was writing down a commercial script for Microsoft? Sorry, if I did !

See, I was just sharing my experience.

It just so happens I've made a living with the Microsoft stack for 16 or so years, now. And say what. I actually don't like it, if not downright hate sometimes most of it.

I'm not married to Microsoft, I have a wonderful wife, thank you. But they feed me. Indirectly: my employers have enough money to spend at MS.

Over 16 years, going on 17, on various more or less interesting projects, I have fought with:

DOS protected mode interface, aka DPMI, the DDK, Device Driver Kit, then 16bit 32bit thunking tricks under W95 and NT4, then COM, DCOM, COM+, .NET, SQL Server 7, 2000, up until today, SQL 2008, you name it.

So yeah, I know that Windows beast quite a bit, and people hire me to clean up or develop code hopefully a little better.

Truly, there is very very few things I like on the MS stack. This thing is just a pain and a mess and a waste of memory and disk space. But it's so easy to add to the mess when you hire junior guys that at some point, sometimes, you know...

They need folks like us to step back a little, and... yeah, KISS.

EDIT
Let's be clearer, shall we?

In 17 years of struggling with the MS stuff for my clients or employers, .NET and C# both were the "less worse" thing I've seen from Microsoft before or after then.

And that was 12 years ago. It's getting old, already. The versions 2, 3, 4, didn't surprise me after that.

So, pretty much everything else, IMO, given the company size in consideration and customer base already in place, has been either predictable, or boring, or warmed up, or hyped up, or average/mediocre, or downright painful. I can still hear about folks spending money/time in Sharepoint. Even when its v1 was released I could tell myself how much overkill this thing was promised to be. But that's just me. Maybe I am stupid and a Sharepoint fan can prove I am wrong. I'm just saying from what I saw companies do with Sharepoint so far, it isn't required, unless you are BofA or something, and you decided to NOT look at simpler, nicer CMS, that would do just as well. But you know, sheeple.

Lets just hope it was fun to code for the MS SDEs, at least.

So, their problem at MS is their dependency on their legacy, they need to ensure themselves to be able to milk from version N to N+1. That's their main problem, like any other big vendor. Add scale to this, and you understand that unless they are stupid, they need from time to time to put enough money in research to at least try to do a little better. That's what happened with .NET I think.

Otherwise, alike dmbarbour on these forums, I have rather radical ideas on what I believe we should instead head towards, with languages. But unlike him, I have big difficulties to even express them simply enough so that people can understand. As you can see, my attempts so far largely sucked, but I still trust the idea/my intuition. It's a slow process. It's fairly beyond (read: foreign to) the current interests, which all seem especially focused on opposing either paradigms, or type systems, or both. Which are interesting topics too, I suppose.

I guess I just need more time to put it simpler/more accessible.

A little creativity goes a long way and alleviates the boredom of tech documents.

Well, I hear you fellow coder. :)

Whether or not I agree with part or all of your points, I love your amusing writing style in your comments so far.

I wish I could do the same, thus just know I much enjoy it. It's at the same time serious topics here (I mean, it's about PLs, right? And programs we write, right? And some control people's lives... or even more serious: money! ;) and also lots of nitpicking, etc.

But man, what is more nitpicking than a compiler anyway? And that's what we use 5/7, 12/24. I guess we guys are doomed to be as biased in that arguing dimension as much as politicians can be ... about, say, their (official) views on morality. If that makes any sense.

Anyway, enough with unfair labeling.

How about this. Remember all that craze about UML in the late 90s, for instance? Here's another funny take I loved from B.M. on the topic:

The positive spin

I read Pike's take shared by the OP here.

I can agree with him that less can sometimes be a lot more.

But I feel that language designers often miss the opportunity of using the satire tool, as Meyer did, to contrast more effectively their language baby's assets with what's in the state of art, to make their point in both a pleasant and informative way.

You, as practitioner, for example, have no issue using the casual stories and amusing metaphors to help yourself make your points (It's indeed something I like to encounter, and still too rare)

Why would they? It's effective for getting my attention anyway. :)

Fair and actually correct in my opinion. Both languages make profit of many common features coming from the CLR itself (duh) but they do make different design choices re: the type checking and related error reporting. Not only I like C#'s syntax better but also its ways to do as less as possible to guess on the programmer's intent (via their respective static typing).

Lippert actually wrote several posts on his blog or on stackoverflow about the *different* tradeoff choices made in VB.NET vs. C#'s camp.

AFAIC, if it was *only* all about syntax, I'd have never touched Delphi after C++, or C++ after Eiffel, in college, or Javascript on the command line after dumb batch files syntax, etc, etc.

I'm pretty verbose in natural language, but I prefer more and more terseness in the languages I program with, as I get older.

Evidence, I even try to learn more of Haskell in my spare time, these days. Better late than never as they say. :)

No longer true, C# supports this as well with its dynamic type. C# and VB.NET are incredibly similar.

Hmm... Debatable.

There are still a number oddities that are VB.NET-specific. This is one of them, that some VB.NET fans can point out C# not having.

Note I'm just playing the Devil's advocate here. I'm not using VB.NET, neither for my work or hobby projects.

I'd sum it up as that at runtime, of course, the two language type systems are indeed the same. Obviously since it's the same CLR under the hood. But statically, VB.NET and C# still have non-identical ways to serve the programmer's intent, and not only with shallow differences of syntax.

- the PR about go routines and channels, usually forgets to mention that similar features do exist as libraries for other languages

The big difference is that goroutines are full-blown continuations.
I can literally have 100000 goroutines operating at once.
This is why I am using Go instead of Java. A CSP library implemented on top of threads is no where near as awesome as goroutines.

I think that developers that are currently using NodeJS, or other similar async environments, should check out Go - they can have all that parallel goodness without having to turn their code into a giant hairball of callbacks.

- no support for meta-programming;

There is a reflection package. I know that's not everything people expect for serious meta-programming but I think Go is close to matching C++.

- exceptions;

I am definitely not a fan of Go's error handling style and I miss exceptions terribly but I am learning how to use panic/defer effectively.

- rich set of available libraries;

Actually, I have been pleasantly surprised by how much stuff is available for Go.

I think that developers that are currently using NodeJS, or other similar async environments, should check out Go - they can have all that parallel goodness without having to turn their code into a giant hairball of callbacks.

We're using Node.JS (actually, IcedCoffeeScript), right now, strictly for RPC and web servers that do next to no computation and are doing all the heavy lifting in Go because of exactly this. Well, not the nested callbacks part because Iced makes that better, but because of the parallel goodness of goroutines, better memory management and actually compiling to decent native code.

Another point I'm missing from Rob Pike's argument is the systems programming aspect. Many projects which stick with C++ don't do this because they love the language - they do it because there is no practical alternative.

Things like (some) control over memory layout and allocation strategies are essential for many demanding tasks (see games, etc.). For low level performance critical code garbage collection just is not an alternative. Manual memory allocation makes it harder to write modular code and requires strategies to avoid memory fragmentation but many of its drawbacks can be overcome by using memory pools, etc. And for writing libraries for this kind of code a way to write generic code without imposing runtime overheads due to boxing, etc. is absolutely required.Especially when memory is tight and the application needs to stay responsive at all times. And on mobile platform this gets even more important thanks to slow memory systems, etc.

The reason C++ programmers don't flock to Go might just be this: that it's a competitor for higher level VM/GC based languages and not a viable alternative for the kind of tasks where C++ still enjoys frequent usage.

There I disagree a little bit.

There are operating systems written in GC enabled languages, like Spin(Modula-3), Singularity(Sing#), Native Oberon(Oberon).

Native Oberon is quite impressive, as it was even the official operating system for his researchers back at ETHZ, providing all capabilities that one would expect from an operating system.

All languages need some sponsor with big pockets, or some kind of killer feature, to get adopted. System programming languages have the additional difficulty of only be adopted as such, if someone is able to push an operating system written in them.

I would embrace a systems programming language with GC support, just that language is not Go.

There I disagree a little bit.

There are operating systems written in GC enabled languages, like Spin(Modula-3), Singularity(Sing#), Native Oberon(Oberon).

Native Oberon is quite impressive, as it was even the official operating system for his researchers back at ETHZ, providing all capabilities that one would expect from an operating system.

All languages need some sponsor with big pockets, or some kind of killer feature, to get adopted. System programming languages have the additional difficulty of only be adopted as such, if someone is able to push an operating system written in them.

I would embrace a systems programming language with GC support, just that language is not Go.

It's not clear that people will "embrace" a new language without "big pocket" sponsors even with an educated audience -- otherwise Felix would be used everywhere :-)

Since it has CT based type system including parametric polymorphism, polyadic generalised arrays on the way, Haskell style type classes, optional garbage collection, has had "goroutines" for a decade, and embeds C and C++ (usually) without executable glue (you need type glue!). DSL support is built in: the grammar is written in user space and dynamically loaded. And it generates C++ code which is sometimes faster than C.

Of course the documentation is seriously lacking, but the project is open and desperately in need of type theorists, a few more compiler writers, library implementors .. and of course users. You can get to the bare metal, or you can just scratch it in with Monads but most importantly you can contribute to the code base.

Spin was performance-competitive only on selected criteria.

The main claim for singularity was that language based protection was just as efficient as "classical" hardware-based OS-style protection. This was only true if you didn't compare the quantitative results to other systems; Singularity was orders of magnitude slower than state of the art or state of the practice. The science integrity of the Singularity claims is comparable to dramatic claims from the same authors on previous systems.

I share the view that Oberon is interesting. Deployment for use by researchers is very encouraging, but not a convincing metric for ultimate success.

Personal opinions (albeit fairly well-informed):

1. It's clear that GC can be used in systems code.
2. There is no conceivable reason to use GC in supervisor code, because reliable supervisor code does not allocate. Consequently, the debate about GC in kernels is misguided, and we should be focusing on the use/non-use of [strongly] typed languages.
3. For more general systemic use, the main problem with GC today is the amount of real DRAM required for competitive performance. That is the remaining challenge to be solved.
4. The C4 collector is a hugely promising development.

For context, I'm the BitC guy and also the architect of the EROS and Coyotos microkernels.

Right, the claims of Singularity (or any recent incarnations) were never really understood as no real applications ever ran. The theorem-prover-based successors are getting even less real!

Mozilla's Rust/Servo will be an interesting repeat, albeit at the browser level rather than kernel. Arguably just as relevant and certainly better validated :)

I feel important having you replying to my post! :)

I cannot debate too much about GC in kernels, maybe it is too much, not sure.

What I surely agree is your reasoning about strongly typed languages.

I think the world did a wrong turn betting in a language like C for systems development instead of a Pascal like one.

C is very good language for systems programming, but sadly some of the features that make it great, are also the ones that open the door to security exploits.

For low level performance critical code garbage collection just is not an alternative.

While I agree that this also can be an issue for migrating from C/C++ to other languages, my estimate is that 80% of projects using C++ today are actually ill-advised to do manual memory management, and would work just as well or better in a good GCed language.

Your percentage guess sounds plausible to me, given the latest advances in implementing generational GCs and such over the last 20 or so years, be it before or after Java, .NET, etc.

That said I haven't touched C++ in almost ten years, or not in (business and application load) significant enough projects. So, maybe I lost sight already of what our C++ coders friends are the most busy with today, if it even changed that much (?) I can only guess.

Nor I have ever bumped* into real issue because of the GC "alone" (note the quotes), in managed runtimes.

That said, however-however if you wish, I've never wandered into the real time apps realm either (in the strict sense of "real time"), which I suppose is a relevant and maybe typical use case for C++, C, assemblers, etc.

Now, sure, if one does funny things alike allocating dozens of millions or more of 1-character long immutable strings (totally ignoring StringBuilders and such thru the concatenations that follow, etc, etc) along with high varying degrees of those string instances' life times (to trick the generational GC algo) ... well, of course, one is likely to complain about the GC.

("Too Many Roots, Too Many Almost-Long-Life Objects" don't play nice with today's GCs. And Go knows it, just as Java and .NET have learnt.)

In my experience, today, for non real time apps, with a good enough design and a minimum of implementation quality, even under heavy server load and significant working sets, industrial strength GC isn't the very first issue re: CPU time and lags.

The DB use AND access to the ground remains the major bottleneck kinds to watch out for.

EDIT
* While I promise, I saw a couple times already how deceptively easy it is to run into shameful CPU time consumption just because of silly large object graphs traversed by some reflection-based ORMs **, for example (Hmph!)... But then again, that's a whole different story which is implying much more an application / architecture design issue than an implementation one of a single specific component of the underlying platform, like the GC.

And, yeah, bad, bad point for OO, there, especially when it's left in Oh, sooo innocent/naive! ... coders' hands (brains). 100% granted.

Not everything, but a lot always eventually comes down to what the human actually can be aware of (or not). That's where experience helps a lot to keep things relative. Just stating the obvious I suppose.

** Nah. Won't give names. :p

The problem, as I see it, is most programmers' ignorance on both sides.

C++ programmers delude themselves into thinking that managing every byte of memory and freeing or recycling it as soon as possible is optimal. But few have any idea how malloc() is actually implemented or how much code can get executed constructing a C++ object with nontrivial constructors (or destructing that object, for that matter). Performance transparency on the C++ is lacking in the areas of how much an individual allocation costs as well as how much user code executes creating each object. C++ programs these days can have as much abstraction as Java programs, and all of that has costs.

On the other hand, Java programmers delude themselves into thinking that allocation costs are effectively zero, when in fact, they are not. Even with bump-pointer allocation, memory still needs to be zeroed and constructors run. Some memory barriers are needed to ensure that initialized objects' fields are properly visible in the memory-model sense. Again, the amount of constructor code that runs can be quite large, and how effectively the compiler inlines that is even less transparent than in C++. A lot of people assume VMs do sophisticated escape analysis and avoid allocating objects on the heap by doing scalar replacement and stack allocation; alas, this is more science fiction than reality, at least for JVMs. There are so many things that can go wrong with the stack of optimizations and analyses needed to trigger this that you can't rely on it. But the real killer is that Java applications hit the allocation wall, eating up too much memory and no longer fitting in the data cache. Allocating lots of small objects absolutely murders performance through cache effects.

I'd summarize by stating the difference is that Java programmers have too much faith in the GC and JIT and C++ programmers have too much faith in themselves.

I'd summarize by stating the difference is that Java programmers have too much faith in the GC and JIT and C++ programmers have too much faith in themselves.

No idea whether this is an over general statement or not, but a priori, I'd hope for you to be wrong (in the generality).

However, I can sure confirm you're right in the same observation re: Java to be applicable as well to .NET, for another, and some ("thank God", not all of them) .NET programmers.

That's where the use of profilers can help a lot to educate people (*). I did so several times, you can prepare, wrap your point up, and make it "harsh", in less than one hour, in a face to face meeting with the coder. One should always keep it casual, though, as it's obviously most often about fixing some ignorance or inexperience, not about stupidity.

Bah. Point is, anyway, no matter how good it can be, you can kill any technology when you use it really wrong.

EDIT
(*) Granted, it's probably easier for MS Windows-busy guys like me. That ugly beast can be so much sub-optimal, sometimes, that it's never too difficult for us to find and show the anti-patterns of .NET running on top of it... ;)

Hi Ben,

I was very intrigued by the "place types" of the X10 language, since it seems like a very direct way of talking about memory locality. They introduced it as a way of programming NUMA machines, but I've wondered if something similar could be used for programming with the cache hierarchy.

I haven't really thought hard about these issues, and you have, so I was curious if you had any thoughts about it.

The PGAS folks around here (Kathy Yelick and her students: UPC, Titanium, ...) definitely think that way and bring it up in their talks. Original PGAS analyses were 2 level -- local and global -- but they generalized the analyses to be hierarchical. They work on big multicore machines and supercomputers (racks, clusters, ...), but they also have to heavily research memory use and will mention applications of this stuff towards it.

However, I don't think they have actually gone and applied it to the single node / many region case. Their single node research is more typically low-level perl scripts for autotuners or high-level communication avoiding algorithms. It doesn't sound super far off (hey, you both made the connection): each level of memory hierarchy might be fairly faithfully modeled as a node. Given their approach to algorithms, there seems to be some value (e.g., verifying the autotuners and maybe a road towards composition). Unfortunately, it also seems limited and probably has a large trade-off (e.g., precision, coping with fancy hardware features they like to exploit, etc.). Despite mentioning it, they don't seem to have gone in this direction, and I'm guessing these are some reasons why :)

We're in a funny boat today, where, with and without automatic GC, app designers consistently come to the only 'sane' solution being to reboot the server every N minutes. Going to full automatic memory management leads to sloppy programming, while manual memory management leads to brittle programming. I suspect making a decision of automatic vs. manual isn't of across-the-board "well or better," but of picking your battles.

Picking C++ is the surprise: for what programmers value when picking a language (I can show you some fun statistics ;-) ), C++ generally rates low relative to say Java. I'm guessing new projects either have momentum (legacy in code or people) or, if people know what they're doing, they're against the wall on one of these battles. Languages like C# are exciting because they help straddle the decision: you can pin an object for a bubble of native programming rather than the language designer going religious on it.

Going to full automatic memory management leads to sloppy programming, while manual memory management leads to brittle programming. I suspect making a decision of automatic vs. manual isn't of across-the-board "well or better," but of picking your battles.

Yup, you nailed it, IMO. That's pretty much the crux of today's languages' (and their users') dilemma. I have the exact same feeling, if one asks me.

Back to the OP's post about Go, I believe the choice of the language to provide a GC is probably not, today, the first or main design attribute one may not be happy with (e.g., as a C++ programmer invited to consider Go).

Wouldn't be mine anyway.

Please bring on those fun statistics!

Funny. I was about to ask the same thing.

Last time I checked Leo's nice survey's bubbles and clouds and all that... there was a bit too much data for me to grok.

Can't wait to see some more synthetic figures. :)

I think we'll start writing in a few weeks. Some relevant numbers on a recent survey about the reason programmers picked a language for their most recent coding project (total votes and % of votes)

1. Describe how your team picks programming languages

The manager strongly influences the choice of language 304 18%
Someone above the manager strongly influences the choice of language 134 8%
Teammates strongly influence the choice of language 567 34%
I strongly influence the choice of non-key languages 497 30%
The project / product strongly influences the choice of language 897 54%
Other 237 14%
People may select more than one checkbox, so percentages may add up to more than 100%.

2.
What factors most influenced choosing that language? - Performance (speed, power, memory, etc. )
does not apply 76 5%
no influence 290 17%
slight influence 414 25%
medium influence 463 28%
strong influence 417 25%

3. What factors most influenced choosing that language? - Safety/correctness (e.g., static types)
does not apply 115 7%
no influence 504 30%
slight influence 397 24%
medium influence 353 21%
strong influence 291 18%

4. What factors most influenced choosing that language? - Tools (e.g., IDE)
does not apply 105 6%
no influence 502 30%
slight influence 385 23%
medium influence 357 22%
strong influence 311 19%

5. What factors most influenced choosing that language? - Extending code already written in that language
does not apply 147 9%
no influence 257 15%
slight influence 223 13%
medium influence 347 21%
strong influence 686 41%

(similar results for internal legacy and open source, but not for closed source)

6. What factors most influenced choosing that language? - Portability/platform (e.g., web, phone, hardware)
does not apply 121 7%
no influence 412 25%
slight influence 320 19%
medium influence 371 22%
strong influence 436 26%

Basically, speed is more compelling than safety, and platforms/portability more so, but most of all is legacy and libraries. It's also interesting to compare "slight/medium" vs. "strong" in the categories -- non-feature, value add, and must have.

Are you considering doing a preliminary writeup for PLATEAU? I was thinking about doing a writeup of my critical programming language design ideas; convenient since we are all going to Onward.

I'll definitely be attending PLATEAU :)

We were planning to do a full paper sometime August, so a short writeup for PLATEAU may be inappropriate (?). It does seems like the right crowd!

Workshops generally don't have policies against concurrent or redundant submissions (with the sense that workshop papers don't really "count"), just make everything obvious in your submit notes.

Cool, double checking with the PC now. I've gone to some workshops which seemed more 'real' ( W2SP, Hot*), so don't want to step on anyone's toes :)

Btw, feel free to send the critical programming draft over. It sounds like a productive twist for pushing and distilling DSLs and calculi design!

You might get more consistent answers if instead of "no/slight/medium/strong influence", you ask all those questions in 1 question this way:

How much do these factors influence language choice?

[    S   ][C][ T ][      L     ][  P  ][   O   ]

S = speed
C = correctness
T = tools
L = legacy
P = platform
O = other

Describe other: {textbox}

where you can change the relative sizes of the bars to indicate how much it influences. "Other" is important because it lets you know if you missed an important category.

Agreed about other -- we did pretesting & free response for that.

Our scale helps because imagine several factors are critical vs. several factors are nice-to-have (e.g., you don't care so much). They may both show up as equal. I wanted to know things like value-add vs. critical, which changes things like how a designer should make trade-offs.

I agree that our form won't be super consistent, but expecting quantitative studies to be that good anyways seems to be a classic modeling mistake. In our case, for example, I detected some disturbing demographic biases: by getting users from Slashdot/Wired/LtU/etc., we only had 1% women!

What about productivity (and/or expressiveness)? Do people even think about that?

Perhaps closest to what you want is "Development/prototyping speed (as opposed to performance or correctness)":

does not apply 115 7%
no influence 482 29%
slight influence 334 20%
medium influence 345 21%
strong influence 383 23%

Dev speed is pretty similar to tooling -- so still trumped by ecosystem concerns. "Little/simple language" was even less important. What I found interesting is, again, the divide between value-add and must-have. Most are nice, but very little is crucial (given the choice between other langs).

I want to do a public release of our data, but that probably won't be until after we do a writeup. There are a few concerns there that will take time we don't really have.

Or how about a chart? :) It's sorted by increasing "strong + medium influence."

Slicing on managers vs. programmers and startups vs. big companies will probably be a fun follow-up to this one.

Thanks, that is nice indeed!

How are the results sorted? I would have liked them to be sorted by "Strong" score, but that seems not to be the case.

They are (by visual inspection) sorted by strong + medium, whether or not that's how they were sorted.

Yep!

C is not just a simple language. Heck, it's nowhere near as simple as, say, Scheme or Haskell. C is a simplistic model of the machine, memory, and runtime environment. It provides a few facilities for abstraction, but as a deliberate design choice, it makes sure that there are specific, simple, known ways for programmers to *break* every abstraction. That's really what the ultra-simple memory model of C is all about; enabling programmers to break abstractions.

That isn't a mistake or a design failure; That is exactly what the designers of the language set out to do. It is a goal in which they succeeded. It was first a language for writing compilers and operating systems in, after all. It was only reasonable to them that if a language is specifically for building things up out of the non-structured, non-abstracted memory locations and bytes you have on a "naked" (no operating system) machine, then the facilities the language provides should be viewable and usable in that language as having been built up in exactly the same way.

In C, abstraction is defined by what you do and don't do, rather than by what you can and can't do. Abstraction as considered by other languages, ie, abstractions you can't break, are specifically an anti-pattern, because C programmers *RELY* on being able to reduce the abstraction level and provide new operations as needed.

Kernighan himself expressed this as expectation by moaning, "there is no escape," in his famous essay about Pascal (you can read it online at http://www.lysator.liu.se/c/bwk-on-pascal.html). What he means by "no escape" is very specifically no way to break the abstractions of Pascal and provide new operations. Breaking abstractions is what C was designed to do and the reason he preferred it to Pascal.

This approach is powerful (perhaps even necessary!) at the lowest level of interfacing with the machine. But it creates a requirement that programmer knowledge, cooperation, and discipline goes with every part of the system, and programmer knowledge, cooperation, and discipline, unfortunately, does not scale easily or well to gigantic projects worked on by herds of programmers who barely communicate with each other.

What classes add to C++ is a means of specifically refusing to cooperate with another programmer who wants to reduce the level of abstraction relied on by your code.

That sort of 'non-cooperative refusal' abstraction paradigm simply hadn't been necessary in projects the size of those contemplated by C's designers. They'd have looked at you and said, "Wait, he's doing something that breaks the program, and some idiot thinks it's your job to stop him from doing it rather than his job to fix his damn code?! That makes no sense!" It would also have made no sense to them that, a few weeks later, he still hadn't fixed his code and hadn't yet been fired, and his abuse of the system was still considered to be your fault, and the aforementioned "some idiot" was now threatening to fire *you* for failing to prevent it.

The situation of not knowing who was doing it, or of not being able to get him to care about or understand the breakage he was causing, or not being able to get *him* to cooperate with the requirements, and therefore needing to actively prevent him from calling the code you'd specifically commented "/* DO NOT CALL THIS FROM ANYTHING EXCEPT THE FOLLOWING TWO ROUTINES!! */" or frobbing the struct field you'd specifically marked "/* DO NOT FROB THIS UNLESS YOU ALSO REMOVE THE REFERENCE FROM THE MAP! */"would have been foreign to their understanding of how programmers worked together, and, not to put too fine a point on it, how programmers remained employed.

So, anyway. C is a medium-complex language built on an ultra-simplistic model of memory and runtime. C++ provides abstraction facilities on top of a language specifically designed to enable programmers to break abstractions at will, which makes the parts that were added to C at least three times as complex as they might have been otherwise and probably qualifies Bjarne Stroustroup as a Mad Scientist for even believing that he could do it.

But, in a bizarre way, it kind of turns out to have been worth it. Being able to get right down to the metal and break low-level abstractions to build new primitives in, say, device drivers, in the same language where you have template metaprogramming and classes, makes both the low-level and the high-level parts of the language more valuable than they'd have been otherwise.

I don't see that kind of range with Go. It doesn't provide low-level abstraction-breaking nor high-level abstractions as good as C++'s.

C is not just a simple language. Heck, it's nowhere near as simple as, say, Scheme or Haskell. C is a simplistic model of the machine, memory, and runtime environment.

I supose this raises the question of what a simple language is. Some parts of C are not especially simple, I suppose, with respect to creatig complex function pointers or the whole array/pointer decay thing.

From some points of view, there is almost no abstraction between the language and the hardware which is what makes it very simple. In other words, you can very easily explain every language construct in terms of which op-codes it generates. In that way, the language is very simple in that there is only a very thin layer between the source code on the screen and the op-codes run by the computer. (ok that completely ignores optimising compilers)

I suppose you could say it's the machine model, rather than the language that is simple (I would agree), but I feel that the two are not really seperable. From some points of view, assembler is an even simpler language (for certain architetures) in that the syntax is very uniform and it is directly obvious what each line of code does. Of course, since it provides no abstraction whatsoever, doing anything with the language is difficult.

This might seem like an odd point of view, and I think it very much depends on the person. In teaching, i found that a small but noticable proportion of students seemed to grasp assembler programming much more naturally than higher level languages initially, because of the `obviousness' of it.

Don't confuse simple with low-level. Today's machines' semantics actually is insanely complicated when you go into the details, because of its complex state model and all the arcane technical artifacts that leak through. Just consider weak memory semantics.

Student perception is a bad indicator, because you usually get highly biased results. In my experience, high-level languages (e.g. functional ones) tend to be "simple" for those with no prior programming experience. The hacker types are struggling more, mainly because of the impedance mismatch with what they have already internalised and thus find "obvious".

It also depends of course on what each student considers as understanding a language. Experienced hackers may find it frustrating not to understanding the execution model, say, of a declarative language. More experienced hackers may find it frustrating not to understand the pipeline architecture of the microprocessor when taught assmbly. Even more experienced hackers are simply used to the feeling and don't complain as much...

Don't confuse simple with low-level. Today's machines' semantics actually is insanely complicated when you go into the details, because of its complex state model and all the arcane technical artifacts that leak through. Just consider weak memory semantics.

That all depends on the machine. And it all depends on what you're doing with the machine. If you steer away from true concurrency, things get a lot simpler for example. Besides, the machine in question was is a PIC12F675. It was chosen for teaching purposes in this case to be an accessible and cheap MCU (with a cheap dev kit), with pretty much the standard gamut of integrated peripherals, for an introduction to microcontrollers.

It's a fairly modern microcontroller, but one with at least somewhat simple semantics. It has a grand total of 64 bytes of memory, one accumulator, one condition register, and a regular RISC-like instruction set. Like all machines, it has quirks, but significant chunks of the execution model can be internalised quite easily.

Student perception is a bad indicator, because you usually get highly biased results. In my experience, high-level languages (e.g. functional ones) tend to be "simple" for those with no prior programming experience. The hacker types are struggling more, mainly because of the impedance mismatch with what they have already internalised and thus find "obvious".

I would say it does depend very much on the student. Additionally, I'm pretty much exclusively referring to students with no programming experience. For some students (again not a huge number, but a noticable number nontheless) starting from asm was easier, in that they could understand it.

I would say that a reasonable definition of simple is how unerstandable it is to a complete novice. For some, very low level is simpler than very high level, because they can see what every individual step does, even if that makes reasoning about a block of code much harder.

Don't confuse simple with low-level. Today's machines' semantics actually is insanely complicated when you go into the details [...] The hacker types are struggling more, mainly because of the impedance mismatch with what they have already internalised and thus find "obvious".

I agree with you.

To me, one possible, and likely objective way to measure a language's overall "simplicity" --as opposed to it going up the slope of complexity (essential or accidental)-- is when our brain after enough practice (in time and interests) is able to embrace the greater portion of it (the language), be it Turing complete or not, and in such a way that reading a formal specification (presumably "short" for simple languages) afterwards, when available, surprises us the least.

E.g., for schema languages, RELAX NG's formal semantics vs. XML Schema's :

https://www.oasis-open.org/committees/relax-ng/proofsystem.html

(I, for one, am still "miles away" from having mentally internalized XML Schema's full semantics after a decade of regular practice ! Granted, done much relunctantly, too.)

And there, quite unsurprisingly enough, it seems that the simplicity vs. complexity debate often turns out to be only loosely related to what we sometimes refer to as the language's "expression power" (or the relative/always debatable lack thereof, depending on the sort of applications one targets).

It's not very hard to make something that is strictly better in isolation if we can persuade people that it is all right to end up with something that isn't compatible with the C or C++ (code, tools and knowledge) they possess. Which I agree is a tall order.

Even so, one wonders why languages that are supposed to be well-suited for low-level and systems programming just aren't. There still is no good standard way in C to describe an arbitrary memory layout (with specified bit fields, endianness and alignment).

I realise who I am replying to, but should add that I found it enlightening to read the motivation behind EASTL. Only then I really understood why only C++, for better or worse, is so hard to replace for some purposes.

Worse is better applies here as elsewhere. Ada has very nice features in this department, which are often to its detriment.