I know Go has been touted as a C successor since inception, but most new users seem to be coming from interpreted languages. Like this blogger, they attribute a lot static language advantages as unique to Go.
I don't see a lot of C/C++ developers switching, probably because they have sunk costs with their respective languages and Go doesn't offer very much by comparison.
I would definitely use Go where it seems appropriate, but I don't see it replacing C as a systems language.[0] Sometimes when I write something in Go, I look back and wonder why didn't I just do it in C. However, Go is great in a distributed systems / networking environment where most new code seems to be written.[1]
In the words of a friend, "You can pry raw memory access from my cold, dead fingers."
This is one of the areas where I actually take Go's defence.
Have a look at Native Oberon and AOS, both desktop operating systems developed at Zurich's technical university.
They are done in GC enabled systems programming languages and were used both as desktop systems by the teachers, as well as to teach operating systems classes.
Quite nice desktop environments using strong typed languages, but offering a Smalltalk like user experience.
The problem with any systems programming language is that it is only used as such, if an OS vendor makes it the only way to do OS programming. Like Microsoft does with C++ or Apple with Objective-C.
I worked on GNOME for a summer, and can see Go being a viable option for DE's. GNOME has added a lot of libraries to bring object support to C, but Haskell has proven gc language is fast enough for a WM (xmonad).
Go might need to improve its gc to prevent the occasional stutter, but it would otherwise be sufficient.
However my original statement defined systems as kernel code, since HN tends to have many opinions on the topic.
> The problem with any systems programming language is that it is only used as such, if an OS vendor makes it the only way to do OS programming. Like Microsoft does with C++ or Apple with Objective-C.
I see plenty of new C code still be written outside of systems, the problem is lack of exposure. HN community is fairly web focused but HPC, scientific computing, graphics, engines are still predominantly done in C/C++.
> However my original statement defined systems as kernel code, since HN tends to have many opinions on the topic.
That is how I understood it. Have a look at the Project Oberon book.
Assembly is only used for the boot loader, device driver glue and some GC implementations. The same type of stuff you need language extensions in C as well, as they are not part of ANSI C.
Everything was coded in Oberon or Active Oberon, depending on which OS version we talk about.
This startup is selling embedded compilers for Oberon that target 32 bit ARM since the late 90's.
> I worked on GNOME for a summer, and can see Go being a viable option for DE's.
Desktop applications are not very demanding. You can write them in scripting languages like Python or JavaScript, both has been done in Gnome. The libraries/toolkits are more demanding.
> Haskell has proven gc language is fast enough for a WM (xmonad).
> However my original statement defined systems as kernel code
Rob Pike (one of the Go creators) seems to define it differently:
"We designed it to be a systems level language because the problems we do at Google are systems level, right? Web servers and database systems, and storage systems and those are systems. Not operating systems, I don't know that Go would be a good operating system language but I am not sure it wouldn't be, what was interesting was because of the approach we took in the design of the language, somewhat to our surprise it turned out to be a really nice general purpose language."
http://www.infoq.com/interviews/pike-google-go
>The problem with any systems programming language is that it is only used as such, if an OS vendor makes it the only way to do OS programming.
Well, one has to question then why no vendor made something like Oberon etc "the only way to do" his OS programming.
Perhaps because having POC OSes at some university wasn't enough, and performance was lacking of OS level work, and lacking in a way that Moore's law cannot address?
(E.g we see Go pausing for 1-10 secs every few minutes on large memory loads. Which might be hood for an academic OS, but not for the OS I want to run video editing, audio DAWs, large apps and application servers on. And even the attempt by SUN to write something as basic as a web browser in pure Java was dog slow circa 2000).
> one has to question then why no vendor made something like Oberon etc "the only way to do" his OS programming.
I reckon it is for the same reason we're still mostly running on PC-compatibles with an x86-based architecture. The only reason for that has been compatibility, not any kind of inherent technical superiority.
> Something as basic as a web browser
I am puzzled at how you can make such a statement. That is definitely one of the more complex programs running on a typical desktop.
If Sun did not invest in JIT research Java would already be gone, the same for JavaScript JIT research.
Having used those systems I can say they were fast enough to be able to display videos. The codecs make use of Assembly, but the same is true when C is used.
Those languages were just victims of the C trap, were the OS copied the UNIX model and thus were being developed in C as well.
Which mainstream OS vendor can you imagine bringing an OS to the market, with an alternative systems programming language and being able to succeed at it?
>Which mainstream OS vendor can you imagine bringing an OS to the market, with an alternative systems programming language and being able to succeed at it?
If the language is good for this purpose, and the resulting OS is better, as in equally fast AND far more secure than the current ones (a marginal increase in security won't matter at all), then any big vendor.
If the OS is feature complete and can run current apps (even if recompiled) with a compatible system call API, then why not?
Microsoft certainly have the resources, and some interest as proven by their Singularity experiment. Obviously they haven't found it commercially viable as of yet, we'll see what the rumored Midori can bring.
But if Microsoft with all their resources can't make it performant enough to be of interest outside of academia (where Singularity ended up) then I doubt anyone can.
The thing is of course that native non-garbage collected operating systems aren't crash-prone, if they were then we would have seen a shift in systems language out of pure necessity ages ago. As it stands, bugs are found, bugs get fixed, systems end up stable and very performant.
Actually Microsoft is already heading slowly in that direction in Windows.
C is official legacy and its compiler won't be improved past C90.
C++ got the C++/CX extensions, which kind of make it language with integrated reference counting, if you only care about Windows. Assuming Windows 9 or whatever it will be called will have broader WinRT support and better commercial luck than Windows 8.
.NET applications are compiled to native code in Windows Phone 8, by making use of techniques developed during the Singularity project. So they got something out of it already, even if it is not at kernel level.
However it is a case of "Worse is Better" and I personally think it will take a few generations for young developers to replace the old mentality. Or I am just plain wrong.
I don't see a lot of C/C++ developers switching, probably because they have sunk costs with their respective languages and Go doesn't offer very much by comparison.
I would definitely use Go where it seems appropriate, but I don't see it replacing C as a systems language.[0] Sometimes when I write something in Go, I look back and wonder why didn't I just do it in C. However, Go is great in a distributed systems / networking environment where most new code seems to be written.[1]
In the words of a friend, "You can pry raw memory access from my cold, dead fingers."
[0] systems == OS, drivers, etc.
[1] Motivations summarized in the abstract: http://talks.golang.org/2012/splash.article#TOC_1.