|
Over the last few days, the software development world has been buzzing with news about Google's latest experiment - the Go programming language. For those of you haven't already heard, it's Google's take on what a modern systems programming language should look like.
It's been in the open for no more than 4 days and there have been a fair number of news articles reporting on the language. After having read these articles and their entailing comment-baggage, I've concluded that a majority of the interviewees, journalists and nerd-raging commenters do not have the slightest clue as to what they're talking about when they dispense their wisdom.
I'm not an expert but I'm pretty damn sure it takes longer than 4 days to be able to accurately judge a language for its strengths and weaknesses.
Commenters and interviewees don't seem to be able to back any of their statements with relevant information or comparisons as to what's really good or bad about Go. A fair number of these folk can't even differentiate a scripting language and a systems language. We have web developers who've only dealt with the likes of Ruby, PHP and Perl, which are scripting languages by the way, never having touched a single strand of systems programming in their lives, attempting to provide 'insightful' feedback on the language.
Stating that "Oh it's nearly as fast as C!" is simply naive and demonstrates a severe lack of understanding of computer architecture. What are you comparison benchmarks for C or Go? If I run a process that spawns a thousand threads to do independent calculations in Go, how would that differ in performance if I ran a single thread in C to do the same amount of work? Do the compilers optimize for the separate system architectures?
The answer to these questions is always the same - it depends. For example, Go implements a garbage collector, lacking any means to manipulate memory (as far as I can tell), while C requires you to specify the points of execution where memory is allocated and deallocated. Memory manipulation can cause huge performance bottlenecks issues if not done right and programmers who claim that memory efficiency isn't important, obviously don't write programs that care about squeezing the last ounce of performance from the systems. But in that case, why would you even consider using a system programming language?
Now, take Tim Burrell.
Here is a man who spent a year and a half working with the D programming language, using it to create several real-world applications, from commercial software to a thesis project. In his blog post, he discusses the pros and cons of the D language from his extensive usage and provides comprehensive facts and relevant examples as to how the language may rise or fall.
It is people like Tim who write useful frameworks and libraries that 'user' programmers will take advantage of. For the rest of us 'user' programmers, we should keep our premature evaluations of things we don't fully understand to ourselves or we'd just end up looking like fools. Read 1 Comments... >>
|