"When was the last time you heard of somebody doing a GUI desktop app or web app in C or C++?"

Anyone working in Qt has probably done a GUI desktop app in C++, but I whole heartedly agree with the rest of your statement with some caveats as there's still many projects getting written in C++ as it's often better the devil you know.

all good points, well made.

I find it disappointing that we've come to label systems languages as the languages with the properties to implement the 'systems' of yesteryear instead of the systems of tomorrow; Singularity, for example. One wonders if Pike and co were to build a new OS just where they'd put the managed/unmanaged line.

Wikipedia says http://en.wikipedia.org/wiki/System_programming_language "The distinction between languages for system programming and applications programming became blurred with widespread popularity of C and Pascal." and I'd hazard that Pike was smearing that blur wider by saying Go. The Go FAQ http://golang.org/doc/go_faq.html still starts by saying "No major systems language has emerged in over a decade" and implicitly saying Go is to be it.

Now to my point that C/C++ is usually a bad choice. Most C++ projects I've seen have been misguided, legacy choices from the late 90s when C++ was the rage. Then again, I've always been mystified by the appeal of STL, since it only just got a hashtable. I have always ended up building higher-performance custom collections for stuff and found STL with its iterator-instead-of-ranges clunky.

I've written buckets of C/C++ code for OS and multimedia projects, some fairly recently; but even then, I'd rather have written only the innermost mechanics of them in C and lashed them together in something that was nice to work with, good C interoperability (no I don't think python tooling is nice) and didn't throw completely out all performance concerns. And until Go came along, there really wasn't anything. Python and so on are only useful for coordinating stuff when the task is embarrassingly and massively parallel.

Along comes Go; you can still x-ray some Go code and have a pretty shrewd idea what the resulting machine code looks like, just like C/C++. Its within spitting distance of C/C++ code for performance and will improve. And as the concurrent scheduling is all in the hands of wizards, one expects it to scale multi-core rather better than something working at the lib-level that requires more discipline to use.

Having said that, I'm actually using Java for a current no-compromise-performance rewrite-from-Python project now. Its Go but its tried and tested. Still, I am not enjoying myself too much.

FWIW, had a fun bug in production the other day; turns out I must be the biggest user of Python in a sense, since I discovered - via a crash - that multiprocessing is using `select()` internally and will fail if it it gets a descriptor over 1024.. how come nobody else has discovered this? I see only one person has, and the fix is in ... 3.3. Just a fun story.

>Its within spitting distance of C/C++ code for performance and will improve.

No, it is not. I don't want to make too much of this because I know that these sort of performance characteristics seldom matter at all in the kind of programming most of us would do with Go, but - - based on the benchmarks game (http://shootout.alioth.debian.org/u32/which-programs-are-fas...) - Go is 6x slower than Fortran/C and is quite a lot slower than Java as well. The 6g/8g compilers will never be nearly that fast because they are optimized for compile time rather than runtime. gccgo may eventually be nearly that fast.

Go will never be a systems language because it will never be possible to: * control memory directly (kernel, device drivers) * expose a C compatible binary interface (libraries) * dynamically link to libraries (pluggable modules ala Apache httpd)

That rules out a whole heck of a lot of software that could reasonably be considered systems work. Of those issues, by far the lack of an ABI is the biggest turn-off to me. I would really like to be able to optimize critical Ruby code by writing native extensions in Go rather than C, but I can't and never will be able to. Rust is really the only thing that may someday be a more reasonable choice for that than C. Instead what has happened is a lot of Python and Ruby developers have picked up Go and would like to call their work "systems programming". Go is pretty good for a lot of this work, but it is not systems work.

>> based on the benchmarks game <<

fwiw 8g seems to produce slower programs than 6g, so to be charitable --

http://shootout.alioth.debian.org/u64/compare.php?lang=go

I'm sorry to be this blunt, but it's quite apparent that you haven't done any serious systems programming. That you were surprised by the syscall underlying multiprocessing...says a lot although I could point to other indications.

Please don't make assertions as to the necessities of a specialty you haven't delved in, it makes it very difficult for me to be civil and respectful.

There is...no real comparison between C/C++ and Java for last-mile performance at the bleeding edge, even if Java is a VERY good high-performance replacement for Python for stuff like network services.

There are a variety of other use-cases where C/C++/Fortran/Ada are extremely necessary. Also note how abysmal Java has been for Android compared to Obj-C with its ever-present escape-hatch to raw C for making responsive and pleasant mobile apps. Especially games.

That aside, stuff like Singularity is research-grade only for very clear and obvious reasons. It isn't practical yet, if ever it would be.

Losing a lot of potential performance and control over the machine at the universal OS level is pretty...damaging and limiting.

It's bad enough that an entire programming language ecosystem can put a cap on your power over the computer and the performance/behavior thereof, to do that at the OS level except as a research project is unconscionable.

Please don't act as if Wikipedia articles about Microsoft Research projects are some indication of the vanguard of operating systems.

> you can still x-ray some Go code and have a pretty shrewd idea what the resulting machine code looks like, just like C/C++.

Er, maybe in the trivial case. You won't have anything close to a deterministic or real-time model for memory management available to you though. And never will.

Everything Go provides on top of C in terms of extra features essentially requires GC to function. (goroutines, and related features). The only thing it really adds on top of C that doesn't necessitate the GC is most aspects of the type system. That could be reused in a hypothetical systems language.

Go itself, in its current design, has absolutely zero future as a systems-language-of-first-resort outside of tinkering. (Some people will cross-compile Go code to chumbys and stuff.)

However, it has something more excellent available to it. A potential future as the hero that slayed Java and supplanted it. I would rather it did that than focused on trying to compete with C or C++. It's not suited to the task and cannot be reconciled with that goal as a fundamental property of its design.

Go is an excellent language for network services. Like Java. Doubly so once they replace that awful garbage collector in 1.1

now we both came here to get a discussion going; now we've got one, you can drop out of the troll personal attack mode.

So you have made quite clear that you find the various named non-bare-metal languages used for 'systems projects' distasteful. But you can't make them undone. You can say they were the wrong tool for the job in your opinion, too, but you can't say that others are wrong to consider them system languages.

An easy and accessible rule of thumb goes as follows:

Could I use this language for:

Writing an OS for a PDP-11 that was reasonably close to the assembler in performance albeit not compactness?

&&

Writing hard real-time constrained avionics software?

&&

Writing HPC software for scientific purposes that takes advantage of strict memory control and vectorized, hardware-specific instructions for maximum throughput?

With varying degrees of expertise and specialty, C, Fortran, Ada, and C++ all qualify.

Try writing even a simple linear algebra algorithm in Java. You won't get anywhere near Fortran or C++. Try as you might. Even relatively sundry CV work is unpleasant outside of the prototype phase on anything but C++/et al.

I'm sorry you felt attacked, but the scope of experience is relevant to the subject. I realize it's very difficult to discuss one's limitations, or have them pointed out by others, without internalizing it and making it a subject of ego.

I generally stick to the high level tier of languages until I am forced to drop down a layer. Experience and pain have stripped me of all hubris that could lead me to believe humans could overcome the fundamental semantic and informational constraints involved in optimizing code that needs to concern itself with the machine-behavior from a higher abstraction layer. I've done more JVM and GC fiddling than I care to recall.

There's a glass ceiling, you won't escape it. Even Paul Graham, the master Common Lisper himself, took advantage of the relatively easy to use FFI faculties in Lisp to drop down to C to optimize hotspots. This was a common pattern when he was doing ViaWeb, I'm told.

It doesn't have to be that way. I am genuinely sorry if you felt attacked or that I was uncivil. I will find other ways to express myself if I run into another similar situation here. That was a failing on my part, please forgive me.

I'm not wont to pontificate to plumbers as to how they should go about plumbing. I say that as someone who's actually redone the plumbing in a residence from top to bottom with my bare hands before. Despite that, I know I'm not a professional plumber and I don't have the experience necessary to say much about it even if I've technically "dabbled".

I don't let a little experience overstep its bounds.

I didn't feel bruised, I felt pity ;)

People write hard constrained trading software in Java e.g. http://mechanical-sympathy.blogspot.se/ Googling for java avonics has some hits too e.g. http://www.slideshare.net/keugbang/t-50-avionics-embedded-so...

I was pretty familiar with the intracities of real-time called iirc "guaranteed service" back when I worked at Symbian. That was a kernel written in dialect of C++. And I've written camera and video capture software for, among others, Android phones. So fairly general experience, I'd say. Still so much more to learn.

You, on the other hand Chris, keep calling out Rob, me and anyone else who thinks that PDP-11 is not a necessary requirement for the next decade's "system language" ;) What systems projects have you worked on then?

And lets not forget the Oberon family of operating systems I referred to in another thread.

Indeed I used Oberon (both native and windows-hosted) for a few intense months back some summer in the 90s. I still have a fondness, perhaps rose-tinted by time, for Pascal languages.

I particularly remember when someone made an Oberon pcode VM browser plugin as a 'competitor' to the newfangled Java applets. I think it was caled Juice or something.

Interestingly Chrome NaCL is going in the same direction, distributing pcode (well, LLVM IR iirc) and doing final compilation on-target.

Maybe you should have a look at Native Oberon and BlueBottle.

They are both single user destkop operating systems implemented in GC enabled systems programming language, Oberon and Active Oberon respectively.

The only assembly is the boot loader, GC and some low level glue for device drivers.

Everything else is written in plain Oberon or Active Oberon, and you get a fully working desktop environment.

This has been used at ETHZ since the late 90's. http://www.ocp.inf.ethz.ch/wiki/Documentation/WindowManager

>However, it has something more excellent available to it. A potential future as the hero that slayed Java and supplanted it.

If you had to stay on the JVM platform (for argument's sake) and supplant the Java language - would you choose a particular language ? I have read your comments above on Clojure and was wondering what you thought about Scala ?

>was wondering what you thought about Scala ?

For my preference, I'd rather use Haskell or Clojure but, I appreciate the ecumenical attitude it brings to the table and I think it's an excellent choice for Java developers that want to grow and learn.

As you may not know you can develop with C/C++ on Android , there is something called the NDK, that is used in a lot of games.