10 ms·

C to Go: Could Go replace C?

144 points by hanszeir 15y ago

evilduck 15y ago
I'm surprised nobody has pointed out another major reason Go will not replace C: embedded programming. GC eats valuable kilobytes on hardware that often doesn't have any to spare.
- chrisjsmith 15y ago
  It's all about trade-offs. GC does eat more memory but with the proliferation of reasonably sized chunks of RAM on ARM embedded systems for example, it's of little concern. Not only that, you reduce the time to market and likelyhood of your code falling over due to pointer and memory problems. That is probably preferred (in my experience) when your product is in situ and has no form of upgrade possible other than shipping an engineer out to do it.
  - evilduck 15y ago
    The cheapest ARM chips are still total overkill for most retail embedded electronic devices and many times more expensive per unit. The cheapest ATTiny AVR chip is $0.60/ea bulk. The cheapest ARM chip like an AT91 is about $4.00/ea bulk. Ship a few million units and suddenly the cost difference between developing in C and Go is pittance.
deleted 15y ago
[deleted]
sliverstorm 15y ago
I'm no CS guru, but just reading the Go code makes me long for the C examples. Thankfully they are not far up the page. Aaahhh...
cageface 15y ago
How can a language with garbage collection replace C?
- latch 15y ago
  Like you, I obviously don't grok Go. Is the goal to build a modern general purpose language? Or is it to build a better C? I'm not sure how it can succeed at either when when it borrows a so much from C (a language which is at least a couple generations dated when it comes to general purpose languages) while adding garbage collection.
  - kinghajj 15y ago
    The purpose of Go isn't to replace C at what C does best, like being wicked fast and having very direct access to the hardware. It's meant to replace programs that Google used to write in C++, like web servers, data aggregators, etc. Go was designed by Googlers for Googlers, and that's very obvious from both the design and standard libraries.
- EdiX 15y ago
  The point of the article is that the author doesn't like programming languages like C++ and Java and has therefore stuck with C programming. The question the author poses is if Go can replace C for him. In general, Go isn't meant to replace C but to replace C++ and Java. Regarding garbage collections Go has the ability to use unmanaged memory although I haven't had occasion to try that, so I don't know how good it actually is.
  - MatthewPhillips 15y ago
    Go is meant to replace C++ and Java for systems programming. They have no designs on implementing Go to do UI programming, for example, which is where C++ and Java are used more than anywhere else.
    - EdiX 15y ago
      True, but I don't know about the "more than anywhere else" part.
rookie 15y ago
eww, single character variable and function names make me ill
biotech 15y ago
C is probably the most firmly entrenched programming language that ever existed, and it's not going away in the near future. One big factor here is the fact that all major operating systems are written in (and have core libraries to support) C. I think in order to "replace C", you'd have to develop an OS in the other language, and that OS would have to gain widespread adoption.
- buckwild 15y ago
  Google is likely capable of creating its own operating system (if you don't already consider Chrome OS a legit operating system).
  - biotech 15y ago
    No doubt there are many organizations capable of building an operating system, and a few with enough influence to cause widespread adoption. Indeed, Google is a great example, as they are responsible for more than one OS: Android and Chrome OS. Both of which are Linux-based, and therefore C-based OS's.
    - kamaal 15y ago
      I don't think it will make sense to re write a Unix-like operating system in Go again! or other one. Google can release something else, like high performance webservers, databases or other web infrastructure. They are in as much demand as probably an operating system. And they make good applications for a killer app.
  - rbanffy 15y ago
    > Google is likely capable of creating its own operating system I don't think they are capable of such mistake ;-) There are plenty of free more-than-good-enough OSs to build upon. Unless Google needs something more revolutionary than Plan-9, they don't need to create another OS. The only reason I would find sane to develop an entirely new OS would be to use all these new shiny toys we got in specialized processors inside our computers. It would be awesome to have a machine with lots (hundreds?) of cores of varying capabilities that could be powered up or down according to load, with processes being transparently migrated between binary-compatible ones or between similar virtual machines hosted on diverse cores. It's been a while since I have seen a cool new research OS.
bigblankenship 15y ago
Really? Systems programming with a garbage collected language? I'm sure the kernel developers will love that.
- ryannielsen 15y ago
  Why not have a systems language with garbage collection? From http://research.microsoft.com/pubs/52716/tr-2005-135.pdf http://research.microsoft.com/pubs/52716/tr-2005-135.pdf: 3.4 Garbage Collection Garbage collection is an essential component of most safe languages, as it prevents memory deallocation errors that can subvert safety guarantees. In Singularity, the kernel and processes object spaces are garbage collected. I appreciate that Microsoft Research is saying "why not?" rather than "why?". Singularity is a fascinating OS and I hope it, or some derivative or something like it from someone else, eventually reaches the mainstream market.
  - chalst 15y ago
    BitC, a project started by Jonathan Shapiro of Coyotos project fame and briefly associated with Microsoft's Midori project, is a systems programming language that supports garbage collection but also allows the programming of critical sections of code in which garbage collection is not permitted to take place. http://www.bitc-lang.org/docs/bitc/bitc-origins.html http://www.bitc-lang.org/docs/bitc/bitc-origins.html
- stewbrew 15y ago
  In a talk/interview on Go Rob Pike (on infoq maybe?) explained that with "systems programming" they don't mean OS development (at least not now). GC technology will improve so that sooner or later it won't be an issue.
- malkia 15y ago
  Surely there were kernels written with garbage collecting - smalltalk xerox systems, or lisp machines come to mind.
- sedachv 15y ago
  Garbage collection needs to go into the kernel. Providing fast, fine-grained control over virtual memory mappings gets you a read barrier on any system with virtual memory, which lets you build real-time GCs. Azul's patches to Linux show how this can be done: http://lambda-the-ultimate.org/node/4165 http://lambda-the-ultimate.org/node/4165 They're using the VT-x for the virtualized page tables and still run the GC in userspace, but if you move the GC into the kernel you won't even need virtualized page tables.
CoffeeDregs 15y ago
This seems like a case of premature optimization. C rocks at what it does. The billion other languages are pointing out and improving upon the stuff C does badly, but they don't replace C (a language I've nearly forgotten, but respect). I RTFA (and its subpages) and didn't see anything mindblowing. The payoff of C->Go comes if you have 1M LOC of C. 900k LOC of Go is much better. For most of us, just-getting-it-to-run is awesome and that's why Ruby, Python, Lisp and Clojure dominate. The best part of the post is that (until later) I didn't know that the "ooh-wow" bits on http://www-cs-students.stanford.edu/~blynn/c2go/ch04.html#_full_translation http://www-cs-students.stanford.edu/~blynn/c2go/ch04.html#_f... were Go and were longer than their C equivalents. Sure, the C bits look scary to a noob; they look perfectly sane to a journeyman.
s_tec 15y ago
I remember a time when people asked, "What will replace the floppy drive?" Everyone expected the replacement to look and feel like a floppy drive, but with more speed and capacity. In the end, the "floppy killer" never materialized. Several unrelated technologies ended up taking over floppy's uses one-by-one. CD-ROM's took over software distribution, USB thumb drives took over file transfer between computers, and the network took over everything else. The same thing will probably happen to C. Modern languages like Python or have arguably "replaced C" in several use-cases already. Go will probably claim a few more. On the other hand, Go is completely unsuitable for applications that cannot tolerate garbage collection, such as embedded firmware. Some other language will have to come along and claim that niche from C as well.
- killerswan 15y ago
  The threat there is simply that embedded firmwares are now much bigger and more capable (and more likely to have room for GC) than ever before. I think you're spot on.
- snprbob86 15y ago
  I'm not so sure there are applications which simply cannot tolerate garbage collection. Unless, you have no reasonable way of preventing allocations. Console games, for instance, are often largely garbage collected, despite being hugely performance critical applications. The way this is generally achieved is by allocating 100% of the console's memory upfront as object pools. The game then utilizes domain specific collection mechanisms on those pools. Shawn Hargreaves has a good article on dealing with C#'s garbage collection in XNA games: http://blogs.msdn.com/b/shawnhar/archive/2007/07/02/twin-paths-to-garbage-collector-nirvana.aspx http://blogs.msdn.com/b/shawnhar/archive/2007/07/02/twin-pat... The problem in .NET land is that some base class library methods allocate internally, so you need to completely avoid them if you use "Path 1" (avoid collections). You wind up having to do funky things like re-implementing core methods and pre-allocating pools of strings to avoid concatenation. Presumably, a language designed to be a systems language could avoid these library problems. I don't know much about Go, but if allocations are clearly demarcated and easily avoidable when necessary, you could allocate 100% of memory up front. You could treat virtual memory as an object pool of memory pages and perform domain specific allocation on those. Alternatively, a collector with a richer interface, such as generation control, multiple heaps, etc. Would allow for "Path 2" (avoid latency) by performing very small, simple collections.
mkelly 15y ago
Is this person intentionally trying to make the C harder to read? What's with all the missing newlines? I didn't get past the first few examples, because the C was so unnecessarily difficult to read, I assumed the Go was in similarly bad style. (I don't know Go.) Maybe there's a point in there somewhere, but bad code samples distract from it.
- barrkel 15y ago
  It seemed clear and fairly idiomatic to me, though it was clearly trying to reduce the line count. For maintainable code, I'd expect more newlines and a little more separation of assignments from comparisons, but not much more. Intuitions like these are rough though - it depends on how low in your perception stack you have the C operators etc. embedded.
- etaty 15y ago
  His formatting style is just the best way to get lost ! if(...) ...;ELSE { } That's the first time I see this and hope the last.
- dreeves 15y ago
  "We deviate from standard style for compactness."
  - jeffreymcmanus 15y ago
    Compactness is not a very good reason to deviate from the standard style, particularly since in Go, the standard style can in some cases have an impact on the syntax of the code.
  - mkelly 15y ago
    To what end? Is vertical space at some kind of premium? I have a scroll bar.
- k_kisiel 15y ago
  Agreed. Besides crappy formatting, he also makes his programs do confusing things. Why does the first example run in the infinite loop?
wcsun 15y ago
Go is designed more like a language for the web. it has a special niche in server programming with ease in memory management and concurrency.
wazoox 15y ago
As a rule, never start a new line with an opening brace; it belongs with the previous line. I'm always using the "one true brace style", so that wouldn't be a problem for me personally; however I feel the pain for people using BSD style. Using a consistent indentation and brace style across all languages you're working with, be it C, Java, Javascript, Perl, PHP is a must, and that Go idiosyncrasy seems really wrong to me; this kind of detail may hamper Go acceptance quite a lot.
- joelthelion 15y ago
  I'm pretty sure you'd get used to it very fast. I think it's a good idea to enforce one style from the start: it kills all stupid arguments in the egg, and lets people focus on the important stuff.
- uriel 15y ago
  This whole topic is another thing where Go is a godsend, gofmt has ended all silly arguments over formatting style.
- wmil 15y ago
  Actually BSD style causes problems in Javascript due to semicolon insertion. http://robertnyman.com/2008/10/16/beware-of-javascript-semicolon-insertion/ http://robertnyman.com/2008/10/16/beware-of-javascript-semic...
silon 15y ago
-1 to Automatic semicolon insertion (seriously).
- cageface 15y ago
  Agreed. It achieves a marginal increase in readability at the cost of all kinds of screwy implicit behavior. I like languages with dumb syntax that editors and IDEs can understand.
  - uriel 15y ago
    Go's syntax is one of the 'dumbest' around, it is extremely easy to parse compared to pretty much any other mainstream language (except scheme I guess). All the bitching about ';' comes from people that clearly have not used Go or tried to parse it.
- deleted 15y ago
  [deleted]
- smosher 15y ago
  Yup. I stopped following Go when that happened. Not intentionally but adding yet more things (invisible ones, no less) that I need to be wary of is not what I consider convenience in a syntax. Other more awkward languages became less inconvenient to use and I just stopped using Go. I probably would have kept at it a bit longer if the dev team was more accepting of feedback presented in good faith. I'm not really surprised -- it's often hard to tell the difference between fruitless bikeshedding and oh guys FYI you might consider this a problem, I do. I am biased towards semis though, when I first saw OCaml's ';;' I was pleased.
  - silon 15y ago
    I mostly stopped too. I still read the mailing list occasionally, but haven't bothered to download any snapshots.
- limmeau 15y ago
  It's a lot more systematic than in JavaScript, rather similar to Python's semicoloning rules.
jergosh 15y ago
This is just a facet of a bigger issue: how come when you want a dynamically typed, scripting language you have plenty of choice but when you want an alternative to C/C++ (i. e. general purpose, compiled to actual machine code -- no VM, no GC), there is hardly anything (Fortran anyone?) If you add 'object-oriented,' you're pretty much left with C++ and, um, OCaml? Even when you want a functional programming language (still semi-esoteric in my book), you have more to choose from.
- leon_ 15y ago
  I bet there are many static typed, compiled languages. But they never get any traction because they are not "sexy" like the newest hyped dynamic language. There are many devs who don't care for static typing - they just want to hack their backend in a weekend and be done. Those devs seem to be the vocal ones with blogs and social media power users behind them. Look at Python. Python is over 20 years old. It has been here since before Windows 95 but only got prominent (in the broad public) in the last few years because some opinion leaders of the hip and young crowd found out you could make cool web apps with it and hyped it into oblivion. I bet if Go hadn't the names behind it it wouldn't get any more traction than any other of the gazillions of programming languages that die silently. I guess not many home brew languages get talking time at a Google conference. Let's be just happy that Go seems to get a little popular - maybe it will be enough for a break through. I'd love that.
  - deleted 15y ago
    [deleted]
  - jergosh 15y ago
    Python is too good a language not to have made it. Google endorsement helped a lot, but they chose it because it's great.
    - kamaal 15y ago
      Not true, I remember a few years back being a major Perl shop. The advice from senior guy in the hierarchy to use Python was 'If Google is using it, it must be good'. And I know whole bunch of people around me in many projects used it just because of Google. Every tool has its own merit Python is nothing special in this regard. Python's low barrier to entry has invited many newbie's to pick it up in a day or two and get going with solving problems. But it has its own flaws and isn't that great as often people project it to be. My own experience with Python, after being a heavy Perl and Ruby user isn't that good. Especially if you are coming from a language like Perl, Python as a language has an interesting trend. At first you feel very happy that things are so simple with it. Then slowly once you learn the language and start getting deeper into it, you try to use it for day to day work. Suddenly you realize that text processing sucks badly, something that is very big problem on Unix based environments. Writing a single regex takes a 10's of lines of exception handling. You try to use it for quick dirty scripting, again the language runs out of steam very soon. Its just too verbose for scripting class. Now coming to more important reasons. Sacrificing power for readability might be great for newbie's but isn't good experienced programmers. Lack of multiline lambda's, no good support for TOC, GIL, barely there object system(compared to Moose), lack of extensibility, lack of syntax plugins. Forcing one way of doing things, all this is great hindrance if one wants to climb upper steps in the ladder of programming. And above all lack of thing like CPAN is just something more than sufficient reason above everything else. I left Python for Perl, but had to go back again. Python wasn't just serving the need for day to day quick scripting. Which I often need to do twice or thrice a day. Text is uneliminable part of large IT projects. Tools like Perl, sed , awk help me do my job quickly everyday. Slowly I realized if I'm using Perl every 50 minutes, I might as well use it for long term projects. On the other hand, Best practices matter for every project. You can writeable and un maintainable code both in any language. We are back to being a Perl shop again. And its the best decision we have made.
raz0r 15y ago
Really? Replace C? Really? http://golang.org/src/ http://golang.org/src/
old-gregg 15y ago
To replace C, one must create a language which, first and foremost, can target shared libraries, because that's how most of systems software operates on virtually all current day's operating systems. This is by far the #1 requirement: extensions to all VMs and scripting languages are shared libraries. Plugins for various servers are shared libraries, heck pretty much everything which is not a web app is a shared library, either on windows or linux. In my life as a C++ developer (about 7 years) I have never, even once, worked on an executable. All my code, at all companies where I worked, always ran inside of either a DLL or a so-file loaded by some hosting process. In fact, I believe that so-files must have been the default compilation target for both Go and D. So millions of Ruby/Perl/Python/Java/<anything goes> programmers could have used those languages for performance-critical or OS-dependent code in their programs, after all that's what "systems languages" are for.
- leon_ 15y ago
  I know that shared libs are prominent and a better support for them would probably help Go's popularity. (Though the idea behind shared libs is somewhat flawed.) But it rocks to deploy a Go app by just sending the binary to a dozen of servers and never have to worry about any dependencies on shared libraries.
  - mattgreenrocks 15y ago
    Savvy Win32 devs used static linking whenever they could to minimize deployment hassles way back when. :)
  - deleted 15y ago
    [deleted]
- masklinn 15y ago
  > I believe that so-files must have been should, no? Considering you can not — as far as I know — compile to shared libraries in Go.
  - delinka 15y ago
jergosh 15y ago
There is a lot to be gained by designing a language that is easier to use than C++ while being at least as fast and that's what Google is probably betting on. GC saves a lot of programmer's time and they don't care about tiny embedded systems not being able handle it. Examples of D and other alternatives only show you need a company behind a language to make anyone use it. On the other hand, C can't be improved much without compromising the 'as much speed as possible but handle with care' philosophy (like introducing GC while sacrificing a bit of speed).
trezor 15y ago
Serious question. Does Go really have anything unique going for it, apart from the fact that it comes from Google? I have yet to see a convincing argument why I should choose Google's little (and relatively immature) language over anything else and I'm very close to assuming this thing is pure hype and has nothing actual newsworthy. Ofcourse, as always I'd love to be proved wrong.
- limmeau 15y ago
  It occupies a sweet spot on at least two axes: 1. Procedural -- OO (with its interface subtyping resembling Haskell type classes with default instances for every type) 2. Languages without safe automatic memory management -- languages with an explicit VM Occupying sweet spots is usually opposed to having radically unique features.
- chrisjsmith 15y ago
  It's as easy and as expressive as python, nearly as fast as C and less complicated than both. That's good enough in my book.
  - bfung 15y ago
    nearly as fast as C not quite; using comparisons from the The Computer Language Benchmarks Game [http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php?gpp=on&gcc=on&java=on&ghc=on&csharp=on&go=on&racket=on&python3=on&yarv=on&calc=chart http://shootout.alioth.debian.org/u32/which-programming-lang...], Go is currently (in general) slower than C++ gnu g++, C gnu gcc, Java 6 -server, Haskell GHC, C# mono, just to name a few. Sure, it's not a definitive view, but it's better than code not run and compared.
    - uriel 15y ago
      Go's compilers are still very young and do almost no optimizations. Also, the 32bit compilers are specially bad as they are not really used by most of the Go developers, the 64bit compilers do much better as you can see here: http://shootout.alioth.debian.org/u64/which-programming-languages-are-fastest.php http://shootout.alioth.debian.org/u64/which-programming-lang...
smosher 15y ago
I see too many other languages defeating Go at its strengths. The only one that survives is its fast compilation, but others are not so slow to make that a deciding factor. If you happen to like/need its particular combination of strengths it may be a good choice, but I think much better can be done. It's a good experiment, but I think they're taking it too seriously in some regards and not seriously enough in others. I just don't see it lasting.
- supersillyus 15y ago
  I want a simple language that compiles to native code, has easy concurrency support, is garbage collected, allows me to distinguish between values and references, and has a compiler/standard library that is useable for real tasks. What other language betters fill that?
  - smosher 15y ago
    That depends. I don't have a good answer because I don't personally think Go qualifies. Rhetorically: is that really all you want out of it? Does Go really do it well enough in your opinion? The thing about compiling to native code is interesting. Why is that important? And are you excluding VM languages which nevertheless produce system binaries in that?
c00p3r 15y ago
No. But surely it can replace C++ and especially Java. ^_^
sigzero 15y ago
I don't see a lot of buzz for Go or at least not nearly enough to make me even ponder "Could Go replace C?".
Symmetry 15y ago
I don't know that much about working on operating systms, but here's Linus Torvalds on maybe using Go in the kernal: "Hey, I think Go picked a few good and important things to look at, but I think they called it "experimental" for a reason. I think it looks like they made a lot of reasonable choices. But introducing a new language? It's hard. Give it a couple of decades, and see where it is then." http://www.realworldtech.com/forums/index.cfm?action=detail&id=110624&threadid=110549&roomid=2 http://www.realworldtech.com/forums/index.cfm?action=detail&...
- TheBoff 15y ago
  From Linus, that's practically a shining endorsement.
  - Symmetry 15y ago
    Yeah. I should have mentioned that the quote was in marked contrast to the rants about the evils of C++ he had been delivering earlier in that thread.
jff 15y ago
We used Go to re-write our cluster management system. In 2,000 lines, we have master and slave daemons that launch programs, exchange files, and forward output from running programs; "launcher" functionality in the same codebase allows users to start jobs and check the status of the system. Switching to Go made everything significantly easier.
- Maro 15y ago
  I'm wondering why you didn't use a scripting language like Python?
  - jff 15y ago
    1. We wanted to try out Go 2. We wanted something that would give us a single, staticly-linked binary that we could easily push out to the nodes. Does Python allow that? 3. Go's goroutines and channels fit beautifully with what we were trying to do.
andhow 15y ago
If the title was "Could Go be used instead of C for a great many applications?" then the author would stand a chance at making a point. However, asking whether Go can "replace" C shows a deep misunderstanding of why people still use C: to do the type of stuff that a safe, typed and garbage collected language won't let you. Need to poke hardware? Need to use efficient memory layouts for your data structures that confound non-dependent type systems? Need exact control over generated code to achieve competitive performance? (And, apparently for Go's case) need to handle OOM conditions? (The "some systems don't even have malloc() return NULL on OOM" argument was particularly weak.) True, these things can be handled by C/C++ and called by Go through a FFI, but then C hasn't really been "replaced". Really, the title should be "Can simple C programs be written in Go in about the same number of lines?" because that's all that was demonstrated.
SRG 15y ago
Related: simple Unix tools written in Haskell. Most of them become just one-liners. Everything is linked to a single executable. http://www.haskell.org/haskellwiki/Simple_unix_tools http://www.haskell.org/haskellwiki/Simple_unix_tools

144 points by hanszeir 15y ago

I'm surprised nobody has pointed out another major reason Go will not replace C: embedded programming. GC eats valuable kilobytes on hardware that often doesn't have any to spare.

chrisjsmith 15y ago
It's all about trade-offs. GC does eat more memory but with the proliferation of reasonably sized chunks of RAM on ARM embedded systems for example, it's of little concern. Not only that, you reduce the time to market and likelyhood of your code falling over due to pointer and memory problems. That is probably preferred (in my experience) when your product is in situ and has no form of upgrade possible other than shipping an engineer out to do it.
- evilduck 15y ago
  The cheapest ARM chips are still total overkill for most retail embedded electronic devices and many times more expensive per unit. The cheapest ATTiny AVR chip is $0.60/ea bulk. The cheapest ARM chip like an AT91 is about $4.00/ea bulk. Ship a few million units and suddenly the cost difference between developing in C and Go is pittance.

deleted 15y ago

[deleted]

sliverstorm 15y ago

I'm no CS guru, but just reading the Go code makes me long for the C examples. Thankfully they are not far up the page. Aaahhh...

cageface 15y ago

How can a language with garbage collection replace C?

latch 15y ago
Like you, I obviously don't grok Go. Is the goal to build a modern general purpose language? Or is it to build a better C? I'm not sure how it can succeed at either when when it borrows a so much from C (a language which is at least a couple generations dated when it comes to general purpose languages) while adding garbage collection.
- kinghajj 15y ago
  The purpose of Go isn't to replace C at what C does best, like being wicked fast and having very direct access to the hardware. It's meant to replace programs that Google used to write in C++, like web servers, data aggregators, etc. Go was designed by Googlers for Googlers, and that's very obvious from both the design and standard libraries.
EdiX 15y ago
The point of the article is that the author doesn't like programming languages like C++ and Java and has therefore stuck with C programming. The question the author poses is if Go can replace C for him. In general, Go isn't meant to replace C but to replace C++ and Java. Regarding garbage collections Go has the ability to use unmanaged memory although I haven't had occasion to try that, so I don't know how good it actually is.
- MatthewPhillips 15y ago
  Go is meant to replace C++ and Java for systems programming. They have no designs on implementing Go to do UI programming, for example, which is where C++ and Java are used more than anywhere else.
  - EdiX 15y ago
    True, but I don't know about the "more than anywhere else" part.

rookie 15y ago

eww, single character variable and function names make me ill

biotech 15y ago

C is probably the most firmly entrenched programming language that ever existed, and it's not going away in the near future. One big factor here is the fact that all major operating systems are written in (and have core libraries to support) C. I think in order to "replace C", you'd have to develop an OS in the other language, and that OS would have to gain widespread adoption.

buckwild 15y ago
Google is likely capable of creating its own operating system (if you don't already consider Chrome OS a legit operating system).
- biotech 15y ago
  No doubt there are many organizations capable of building an operating system, and a few with enough influence to cause widespread adoption. Indeed, Google is a great example, as they are responsible for more than one OS: Android and Chrome OS. Both of which are Linux-based, and therefore C-based OS's.
  - kamaal 15y ago
    I don't think it will make sense to re write a Unix-like operating system in Go again! or other one. Google can release something else, like high performance webservers, databases or other web infrastructure. They are in as much demand as probably an operating system. And they make good applications for a killer app.
- rbanffy 15y ago
  > Google is likely capable of creating its own operating system I don't think they are capable of such mistake ;-) There are plenty of free more-than-good-enough OSs to build upon. Unless Google needs something more revolutionary than Plan-9, they don't need to create another OS. The only reason I would find sane to develop an entirely new OS would be to use all these new shiny toys we got in specialized processors inside our computers. It would be awesome to have a machine with lots (hundreds?) of cores of varying capabilities that could be powered up or down according to load, with processes being transparently migrated between binary-compatible ones or between similar virtual machines hosted on diverse cores. It's been a while since I have seen a cool new research OS.

bigblankenship 15y ago

Really? Systems programming with a garbage collected language? I'm sure the kernel developers will love that.

ryannielsen 15y ago
Why not have a systems language with garbage collection? From http://research.microsoft.com/pubs/52716/tr-2005-135.pdf http://research.microsoft.com/pubs/52716/tr-2005-135.pdf: 3.4 Garbage Collection Garbage collection is an essential component of most safe languages, as it prevents memory deallocation errors that can subvert safety guarantees. In Singularity, the kernel and processes object spaces are garbage collected. I appreciate that Microsoft Research is saying "why not?" rather than "why?". Singularity is a fascinating OS and I hope it, or some derivative or something like it from someone else, eventually reaches the mainstream market.
- chalst 15y ago
  BitC, a project started by Jonathan Shapiro of Coyotos project fame and briefly associated with Microsoft's Midori project, is a systems programming language that supports garbage collection but also allows the programming of critical sections of code in which garbage collection is not permitted to take place. http://www.bitc-lang.org/docs/bitc/bitc-origins.html http://www.bitc-lang.org/docs/bitc/bitc-origins.html
stewbrew 15y ago
In a talk/interview on Go Rob Pike (on infoq maybe?) explained that with "systems programming" they don't mean OS development (at least not now). GC technology will improve so that sooner or later it won't be an issue.
malkia 15y ago
Surely there were kernels written with garbage collecting - smalltalk xerox systems, or lisp machines come to mind.
sedachv 15y ago
Garbage collection needs to go into the kernel. Providing fast, fine-grained control over virtual memory mappings gets you a read barrier on any system with virtual memory, which lets you build real-time GCs. Azul's patches to Linux show how this can be done: http://lambda-the-ultimate.org/node/4165 http://lambda-the-ultimate.org/node/4165 They're using the VT-x for the virtualized page tables and still run the GC in userspace, but if you move the GC into the kernel you won't even need virtualized page tables.

CoffeeDregs 15y ago

This seems like a case of premature optimization. C rocks at what it does. The billion other languages are pointing out and improving upon the stuff C does badly, but they don't replace C (a language I've nearly forgotten, but respect). I RTFA (and its subpages) and didn't see anything mindblowing. The payoff of C->Go comes if you have 1M LOC of C. 900k LOC of Go is much better. For most of us, just-getting-it-to-run is awesome and that's why Ruby, Python, Lisp and Clojure dominate. The best part of the post is that (until later) I didn't know that the "ooh-wow" bits on http://www-cs-students.stanford.edu/~blynn/c2go/ch04.html#_full_translation http://www-cs-students.stanford.edu/~blynn/c2go/ch04.html#_f... were Go and were longer than their C equivalents. Sure, the C bits look scary to a noob; they look perfectly sane to a journeyman.

s_tec 15y ago

I remember a time when people asked, "What will replace the floppy drive?" Everyone expected the replacement to look and feel like a floppy drive, but with more speed and capacity. In the end, the "floppy killer" never materialized. Several unrelated technologies ended up taking over floppy's uses one-by-one. CD-ROM's took over software distribution, USB thumb drives took over file transfer between computers, and the network took over everything else. The same thing will probably happen to C. Modern languages like Python or have arguably "replaced C" in several use-cases already. Go will probably claim a few more. On the other hand, Go is completely unsuitable for applications that cannot tolerate garbage collection, such as embedded firmware. Some other language will have to come along and claim that niche from C as well.

killerswan 15y ago
The threat there is simply that embedded firmwares are now much bigger and more capable (and more likely to have room for GC) than ever before. I think you're spot on.
snprbob86 15y ago
I'm not so sure there are applications which simply cannot tolerate garbage collection. Unless, you have no reasonable way of preventing allocations. Console games, for instance, are often largely garbage collected, despite being hugely performance critical applications. The way this is generally achieved is by allocating 100% of the console's memory upfront as object pools. The game then utilizes domain specific collection mechanisms on those pools. Shawn Hargreaves has a good article on dealing with C#'s garbage collection in XNA games: http://blogs.msdn.com/b/shawnhar/archive/2007/07/02/twin-paths-to-garbage-collector-nirvana.aspx http://blogs.msdn.com/b/shawnhar/archive/2007/07/02/twin-pat... The problem in .NET land is that some base class library methods allocate internally, so you need to completely avoid them if you use "Path 1" (avoid collections). You wind up having to do funky things like re-implementing core methods and pre-allocating pools of strings to avoid concatenation. Presumably, a language designed to be a systems language could avoid these library problems. I don't know much about Go, but if allocations are clearly demarcated and easily avoidable when necessary, you could allocate 100% of memory up front. You could treat virtual memory as an object pool of memory pages and perform domain specific allocation on those. Alternatively, a collector with a richer interface, such as generation control, multiple heaps, etc. Would allow for "Path 2" (avoid latency) by performing very small, simple collections.

mkelly 15y ago

Is this person intentionally trying to make the C harder to read? What's with all the missing newlines? I didn't get past the first few examples, because the C was so unnecessarily difficult to read, I assumed the Go was in similarly bad style. (I don't know Go.) Maybe there's a point in there somewhere, but bad code samples distract from it.

barrkel 15y ago
It seemed clear and fairly idiomatic to me, though it was clearly trying to reduce the line count. For maintainable code, I'd expect more newlines and a little more separation of assignments from comparisons, but not much more. Intuitions like these are rough though - it depends on how low in your perception stack you have the C operators etc. embedded.
etaty 15y ago
His formatting style is just the best way to get lost ! if(...) ...;ELSE { } That's the first time I see this and hope the last.
dreeves 15y ago
"We deviate from standard style for compactness."
- jeffreymcmanus 15y ago
  Compactness is not a very good reason to deviate from the standard style, particularly since in Go, the standard style can in some cases have an impact on the syntax of the code.
- mkelly 15y ago
  To what end? Is vertical space at some kind of premium? I have a scroll bar.
k_kisiel 15y ago
Agreed. Besides crappy formatting, he also makes his programs do confusing things. Why does the first example run in the infinite loop?

wcsun 15y ago

Go is designed more like a language for the web. it has a special niche in server programming with ease in memory management and concurrency.

wazoox 15y ago

As a rule, never start a new line with an opening brace; it belongs with the previous line. I'm always using the "one true brace style", so that wouldn't be a problem for me personally; however I feel the pain for people using BSD style. Using a consistent indentation and brace style across all languages you're working with, be it C, Java, Javascript, Perl, PHP is a must, and that Go idiosyncrasy seems really wrong to me; this kind of detail may hamper Go acceptance quite a lot.

joelthelion 15y ago
I'm pretty sure you'd get used to it very fast. I think it's a good idea to enforce one style from the start: it kills all stupid arguments in the egg, and lets people focus on the important stuff.
uriel 15y ago
This whole topic is another thing where Go is a godsend, gofmt has ended all silly arguments over formatting style.
wmil 15y ago
Actually BSD style causes problems in Javascript due to semicolon insertion. http://robertnyman.com/2008/10/16/beware-of-javascript-semicolon-insertion/ http://robertnyman.com/2008/10/16/beware-of-javascript-semic...

silon 15y ago

-1 to Automatic semicolon insertion (seriously).

cageface 15y ago
Agreed. It achieves a marginal increase in readability at the cost of all kinds of screwy implicit behavior. I like languages with dumb syntax that editors and IDEs can understand.
- uriel 15y ago
  Go's syntax is one of the 'dumbest' around, it is extremely easy to parse compared to pretty much any other mainstream language (except scheme I guess). All the bitching about ';' comes from people that clearly have not used Go or tried to parse it.
deleted 15y ago
[deleted]
smosher 15y ago
Yup. I stopped following Go when that happened. Not intentionally but adding yet more things (invisible ones, no less) that I need to be wary of is not what I consider convenience in a syntax. Other more awkward languages became less inconvenient to use and I just stopped using Go. I probably would have kept at it a bit longer if the dev team was more accepting of feedback presented in good faith. I'm not really surprised -- it's often hard to tell the difference between fruitless bikeshedding and oh guys FYI you might consider this a problem, I do. I am biased towards semis though, when I first saw OCaml's ';;' I was pleased.
- silon 15y ago
  I mostly stopped too. I still read the mailing list occasionally, but haven't bothered to download any snapshots.
limmeau 15y ago
It's a lot more systematic than in JavaScript, rather similar to Python's semicoloning rules.

jergosh 15y ago

This is just a facet of a bigger issue: how come when you want a dynamically typed, scripting language you have plenty of choice but when you want an alternative to C/C++ (i. e. general purpose, compiled to actual machine code -- no VM, no GC), there is hardly anything (Fortran anyone?) If you add 'object-oriented,' you're pretty much left with C++ and, um, OCaml? Even when you want a functional programming language (still semi-esoteric in my book), you have more to choose from.

leon_ 15y ago
I bet there are many static typed, compiled languages. But they never get any traction because they are not "sexy" like the newest hyped dynamic language. There are many devs who don't care for static typing - they just want to hack their backend in a weekend and be done. Those devs seem to be the vocal ones with blogs and social media power users behind them. Look at Python. Python is over 20 years old. It has been here since before Windows 95 but only got prominent (in the broad public) in the last few years because some opinion leaders of the hip and young crowd found out you could make cool web apps with it and hyped it into oblivion. I bet if Go hadn't the names behind it it wouldn't get any more traction than any other of the gazillions of programming languages that die silently. I guess not many home brew languages get talking time at a Google conference. Let's be just happy that Go seems to get a little popular - maybe it will be enough for a break through. I'd love that.
- deleted 15y ago
  [deleted]
- jergosh 15y ago
  Python is too good a language not to have made it. Google endorsement helped a lot, but they chose it because it's great.
  - kamaal 15y ago
    Not true, I remember a few years back being a major Perl shop. The advice from senior guy in the hierarchy to use Python was 'If Google is using it, it must be good'. And I know whole bunch of people around me in many projects used it just because of Google. Every tool has its own merit Python is nothing special in this regard. Python's low barrier to entry has invited many newbie's to pick it up in a day or two and get going with solving problems. But it has its own flaws and isn't that great as often people project it to be. My own experience with Python, after being a heavy Perl and Ruby user isn't that good. Especially if you are coming from a language like Perl, Python as a language has an interesting trend. At first you feel very happy that things are so simple with it. Then slowly once you learn the language and start getting deeper into it, you try to use it for day to day work. Suddenly you realize that text processing sucks badly, something that is very big problem on Unix based environments. Writing a single regex takes a 10's of lines of exception handling. You try to use it for quick dirty scripting, again the language runs out of steam very soon. Its just too verbose for scripting class. Now coming to more important reasons. Sacrificing power for readability might be great for newbie's but isn't good experienced programmers. Lack of multiline lambda's, no good support for TOC, GIL, barely there object system(compared to Moose), lack of extensibility, lack of syntax plugins. Forcing one way of doing things, all this is great hindrance if one wants to climb upper steps in the ladder of programming. And above all lack of thing like CPAN is just something more than sufficient reason above everything else. I left Python for Perl, but had to go back again. Python wasn't just serving the need for day to day quick scripting. Which I often need to do twice or thrice a day. Text is uneliminable part of large IT projects. Tools like Perl, sed , awk help me do my job quickly everyday. Slowly I realized if I'm using Perl every 50 minutes, I might as well use it for long term projects. On the other hand, Best practices matter for every project. You can writeable and un maintainable code both in any language. We are back to being a Perl shop again. And its the best decision we have made.

raz0r 15y ago

Really? Replace C? Really? http://golang.org/src/ http://golang.org/src/

old-gregg 15y ago

To replace C, one must create a language which, first and foremost, can target shared libraries, because that's how most of systems software operates on virtually all current day's operating systems. This is by far the #1 requirement: extensions to all VMs and scripting languages are shared libraries. Plugins for various servers are shared libraries, heck pretty much everything which is not a web app is a shared library, either on windows or linux. In my life as a C++ developer (about 7 years) I have never, even once, worked on an executable. All my code, at all companies where I worked, always ran inside of either a DLL or a so-file loaded by some hosting process. In fact, I believe that so-files must have been the default compilation target for both Go and D. So millions of Ruby/Perl/Python/Java/<anything goes> programmers could have used those languages for performance-critical or OS-dependent code in their programs, after all that's what "systems languages" are for.

leon_ 15y ago
I know that shared libs are prominent and a better support for them would probably help Go's popularity. (Though the idea behind shared libs is somewhat flawed.) But it rocks to deploy a Go app by just sending the binary to a dozen of servers and never have to worry about any dependencies on shared libraries.
- mattgreenrocks 15y ago
  Savvy Win32 devs used static linking whenever they could to minimize deployment hassles way back when. :)
- deleted 15y ago
  [deleted]
masklinn 15y ago
> I believe that so-files must have been should, no? Considering you can not — as far as I know — compile to shared libraries in Go.
- delinka 15y ago

jergosh 15y ago

There is a lot to be gained by designing a language that is easier to use than C++ while being at least as fast and that's what Google is probably betting on. GC saves a lot of programmer's time and they don't care about tiny embedded systems not being able handle it. Examples of D and other alternatives only show you need a company behind a language to make anyone use it. On the other hand, C can't be improved much without compromising the 'as much speed as possible but handle with care' philosophy (like introducing GC while sacrificing a bit of speed).

trezor 15y ago

Serious question. Does Go really have anything unique going for it, apart from the fact that it comes from Google? I have yet to see a convincing argument why I should choose Google's little (and relatively immature) language over anything else and I'm very close to assuming this thing is pure hype and has nothing actual newsworthy. Ofcourse, as always I'd love to be proved wrong.

limmeau 15y ago
It occupies a sweet spot on at least two axes: 1. Procedural -- OO (with its interface subtyping resembling Haskell type classes with default instances for every type) 2. Languages without safe automatic memory management -- languages with an explicit VM Occupying sweet spots is usually opposed to having radically unique features.
chrisjsmith 15y ago
It's as easy and as expressive as python, nearly as fast as C and less complicated than both. That's good enough in my book.
- bfung 15y ago
  nearly as fast as C not quite; using comparisons from the The Computer Language Benchmarks Game [http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php?gpp=on&gcc=on&java=on&ghc=on&csharp=on&go=on&racket=on&python3=on&yarv=on&calc=chart http://shootout.alioth.debian.org/u32/which-programming-lang...], Go is currently (in general) slower than C++ gnu g++, C gnu gcc, Java 6 -server, Haskell GHC, C# mono, just to name a few. Sure, it's not a definitive view, but it's better than code not run and compared.
  - uriel 15y ago
    Go's compilers are still very young and do almost no optimizations. Also, the 32bit compilers are specially bad as they are not really used by most of the Go developers, the 64bit compilers do much better as you can see here: http://shootout.alioth.debian.org/u64/which-programming-languages-are-fastest.php http://shootout.alioth.debian.org/u64/which-programming-lang...

smosher 15y ago

I see too many other languages defeating Go at its strengths. The only one that survives is its fast compilation, but others are not so slow to make that a deciding factor. If you happen to like/need its particular combination of strengths it may be a good choice, but I think much better can be done. It's a good experiment, but I think they're taking it too seriously in some regards and not seriously enough in others. I just don't see it lasting.

supersillyus 15y ago
I want a simple language that compiles to native code, has easy concurrency support, is garbage collected, allows me to distinguish between values and references, and has a compiler/standard library that is useable for real tasks. What other language betters fill that?
- smosher 15y ago
  That depends. I don't have a good answer because I don't personally think Go qualifies. Rhetorically: is that really all you want out of it? Does Go really do it well enough in your opinion? The thing about compiling to native code is interesting. Why is that important? And are you excluding VM languages which nevertheless produce system binaries in that?

c00p3r 15y ago

No. But surely it can replace C++ and especially Java. ^_^

sigzero 15y ago

I don't see a lot of buzz for Go or at least not nearly enough to make me even ponder "Could Go replace C?".

Symmetry 15y ago

I don't know that much about working on operating systms, but here's Linus Torvalds on maybe using Go in the kernal: "Hey, I think Go picked a few good and important things to look at, but I think they called it "experimental" for a reason. I think it looks like they made a lot of reasonable choices. But introducing a new language? It's hard. Give it a couple of decades, and see where it is then." http://www.realworldtech.com/forums/index.cfm?action=detail&id=110624&threadid=110549&roomid=2 http://www.realworldtech.com/forums/index.cfm?action=detail&...

TheBoff 15y ago
From Linus, that's practically a shining endorsement.
- Symmetry 15y ago
  Yeah. I should have mentioned that the quote was in marked contrast to the rants about the evils of C++ he had been delivering earlier in that thread.

jff 15y ago

We used Go to re-write our cluster management system. In 2,000 lines, we have master and slave daemons that launch programs, exchange files, and forward output from running programs; "launcher" functionality in the same codebase allows users to start jobs and check the status of the system. Switching to Go made everything significantly easier.

Maro 15y ago
I'm wondering why you didn't use a scripting language like Python?
- jff 15y ago
  1. We wanted to try out Go 2. We wanted something that would give us a single, staticly-linked binary that we could easily push out to the nodes. Does Python allow that? 3. Go's goroutines and channels fit beautifully with what we were trying to do.

andhow 15y ago

If the title was "Could Go be used instead of C for a great many applications?" then the author would stand a chance at making a point. However, asking whether Go can "replace" C shows a deep misunderstanding of why people still use C: to do the type of stuff that a safe, typed and garbage collected language won't let you. Need to poke hardware? Need to use efficient memory layouts for your data structures that confound non-dependent type systems? Need exact control over generated code to achieve competitive performance? (And, apparently for Go's case) need to handle OOM conditions? (The "some systems don't even have malloc() return NULL on OOM" argument was particularly weak.) True, these things can be handled by C/C++ and called by Go through a FFI, but then C hasn't really been "replaced". Really, the title should be "Can simple C programs be written in Go in about the same number of lines?" because that's all that was demonstrated.

SRG 15y ago

Related: simple Unix tools written in Haskell. Most of them become just one-liners. Everything is linked to a single executable. http://www.haskell.org/haskellwiki/Simple_unix_tools http://www.haskell.org/haskellwiki/Simple_unix_tools