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
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++.