Link Details

Link 320949 thumbnail
User 225256 avatar

By mswatcher
Published: Dec 16 2009 / 02:43

Here's my TL;DR summary of the following long rant: Google's Go programming language is a boring entry in the world of programming that got undeserved buzz only because of some names attached to it.
  • 43
  • 2
  • 4630
  • 8
User 230306 avatar

Eric Burke replied ago:

2 votes Vote down Vote up Reply

Too much complaining and name calling to catch my interest. Repeatedly calling Unix a "virus", for example, is unnecessary.

User 393686 avatar

RawThinkTank replied ago:

2 votes Vote down Vote up Reply

Go is bore because they didnt focus on productivity nor platform independence.

Adding features is not just enough, the code has to be readable too.

User 46563 avatar

rv49649 replied ago:

1 votes Vote down Vote up Reply

I've written a fair amount of Go code by now and the only thing that I see as really significant in this complaint list (the subjective criticisms per syntax examples can be applied against any popular language), was the point about lack of exception handling. All the critique mentioned on that point I agree with completely - down to the obfuscation of code that results from constantly examining return codes.

I think that criticism should go even deeper, though. Go is being billed as a systems programming language that could be suitable for replacement of C in that respect. Well, if one is writing kernel code, device driver code, or even an application server, then it is absolutely essential to be able to catch various processor interrupts, faults, or traps and handle them. Microsoft added structured exception handling to C (__throw, __catch, __finally) in order to be able to write all the Win NT system code in a high level language. Consequently I can easily write a Windows C program that directly interacts with memory fault exceptions or, say, the virtual memory paging system. If I were to write an an OS strictly in Go language, then my users would be frequently hitting blue screen and core dumps and having to reboot their computer. Or, say, an application server. The first fault caused by a loaded bean, and the whole app server process faults and quits running. If written 100% in Go, there is no defensive way to write that app server to be robust and continue operation despite badly behaved beans. So much for the "systems programming" moniker.

Now this angle is hugely serious for a so-called self-styled systems programming language, and if Go doesn't add exception handling features that are at least comparable to what Microsoft did with their C, then Go ain't going to 'go' anywhere - despite the fact that channels and goroutines are quite terrific.

As to generics - not missing that one at all. The arrays, maps, and channels can be declared and used with type safety.

Love the type inference that permits terse variable declarations via ':='.

Compile/link time is indeed very fast and therefore very productive.

I miss doing code reuse through inheritance - there can be a time and place for that.

Surprised there was no complaint about Go enumerations - or lack thereof. Is an area of Go that takes the C philosophy too far.

Add your comment

Html tags not supported. Reply is editable for 5 minutes. Use [code lang="java|ruby|sql|css|xml"][/code] to post code snippets.

Apache Hadoop
Written by: Piotr Krewski
Featured Refcardz: Top Refcardz:
  1. Play
  2. Akka
  3. Design Patterns
  4. OO JS
  5. Cont. Delivery
  1. Play
  2. Java Performance
  3. Akka
  4. REST
  5. Java