LOGIN | REGISTER NOW | SUBSCRIBE
 
Print

Code Watch: On the Go


By Larry O Brien


 Larry O Brien
Email
June 20, 2012 —  (Page 1 of 2)
C and C++ are so widely known and broadly supported that it borders on heresy to suggest that they may not now and forever be the best languages for high-performance systems programming. The Go language, originally designed by Robert Griesemer, Rob Pike and Ken Thompson, dares speak that heresy. The three chief distinguishing characteristics of Go are fast compilation, garbage-collected memory, and concurrency via Communicating Sequential Processes.

Of those, "fast compilation" seems to be the one that causes the most surprise. If you've never been given a "speed up the build" assignment on an industrial-sized C/C++ codebase, know that you have avoided a nightmare corner of the software world. (You really find out who your friends are after you commit a "fix" that takes the build from overnight to "overnight and into the next workday.")

Walter Bright, designer of the D language, has said that it takes seven passes just to tokenize C++ text! In the same post, he lists non-parallelizable dependencies, preprocessor semantics, overuse of "#include," and the lack of context-independence as other insuperable obstacles. Bright implemented Zortech C++, the first native-code compiler for DOS, more than 20 years ago, and if he's never figured out how to reduce the number of text passes below three, I'm ready to bet that no one else has, either.

Of course, it's doubtful that anyone outside of Google looking at a major infrastructure system with hundreds of compilation units is thinking, "Oh, hey, why don't we try it with a new language and see how that goes?" While it's sensible to explore Go with a pilot project or two, it would be foolish to fully commit to a language with such a short track record and so few developers.

Garbage-collected memory is not a surprising language feature in mainstream development, but relying on it at the systems level is one of Go's bolder design decisions. The current garbage collector in Go is stop-the-world, non-generational and non-compacting, so it's not a state-of-the-art leap forward. On the face of it, there is no easy way to use manual memory management with Go short of linking in a C-based module, so I could definitely see scenarios where that would seem to disqualify Go from consideration.


Related Search Term(s): Go

Pages 1 2 


Share this link: http://sdt.bz/36735
 
Most Read  Latest News  Resources
SAP unveils SAP HANA platform innovations for Big Data and spatial processing
Features include smart data access and expanded cloud deployment options
Alteryx raises $12 million to put Big Data analytics in the hands of all business analysts
Quest founder's firm, Toba Capital, selects Alteryx as its first analytics investment
Google I/O kicks off
Developers get new APIs and tools, and the Go language hits version 1.1
Jelastic launches new version of its Java and PHP hosting platform
Jelastic today announced the launch of a new version of its ultra-scalable cloud hosting platform
Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter


close
NEXT ARTICLE
Letters to the Editor: Be wary of Go
One reader is unsure about Go’s staying power; another sees why Microsoft’s logo change is no big deal Read More...
 
 
 




News on Monday  more>>
Android Developer News  more>>
SharePoint Tech Report  more>>
Big Data TechReport  more>>

   
 
 

 


Download Current Issue
MAY 2013 PDF ISSUE

Need Back Issues?
DOWNLOAD HERE

Want to subscribe?