Its not just that many programmers want more control. Its also the case that many programmers want more complication. They really prefer the most complicated and difficult way to do things. They don't trust things that are easier or simpler. I think that maybe they believe deep down that ease-of-use versus power is truly a zero-sum game, and you just can't get more of one thing without giving up some of the other. Also, I think that many of them are afraid of losing some of their masculine programmer identity if they adopt an easier way to accomplish things. Also, many of them have invested such an enormous portion of their life and identity to becoming fluent in all of the complications that it is nearly impossible for anything to come around that would make them give up that investment.
But it boils down to the fact that selection of base technologies, like all of the most important human decisions, is generally a NOT rational process, but rather an emotional and subconscious one.
One thing that's interesting to me, and I know this will be hard to buy/comprehend for many Go/C++ programmers, but a similar thing is actually happening with JavaScript versus CoffeeScript.
Its amazing because the languages actually have the same capabilities and the syntactical advantages are so obvious.
`` You really need a transpiled language to save you some time from learning the right way to write JavaScript in the first place? Learn JavaScript's pain points and just don't do them.
It's like that C/C++ quote goes:
"In C++ it's harder to shoot yourself in the foot, but when you do, you blow off your whole leg."
-- Bjarne Stroustrup. ``
Some people don't trust black boxes because they have been burned too many times in the past. I don't want to make this an age thing, but in my observation the people who are chomping at the bit to jump on the next big thing are generally those who haven't yet really suffered because of someone else's mistake.
Cryptography's got the right attitude. Don't use things that are proven to be broken, but at the same time don't trust anything that hasn't been under the harsh glare of professional scrutiny for a while.
I'm 34. I started teaching myself software development when I was seven. I have done PC assembly, C, C++, OpenGL, Win32, MFC, OCaml, .NET, PHP, Python, Twisted, AS3, JavaScript, WordPress, CoffeeScript and other types of programming. I have suffered because of mistakes in the underlying platform implementation in some cases, but in my experience more often I am suffering because of fundamental design limitations of the platform.
People move on to the next thing because they know it solves fundamental engineering problems built in to the platform they are on that are causing constant problems and they are tired of suffering through that. Such as manual memory management or traditional threading.
For example, back in my C/C++ days, I worked on a number of projects that were threaded and manually memory managed. No matter how genius the team members were we always spent a significant amount of time either guarding against those types of issues or diagnosing them, or working on Make scripts or other build-related distractions.
So that was one reason why I moved to C#/.NET many years ago. The advantage of being able to access source code in open source projects, cost benefit and lack of vendor lock in moved me away from that.
Or for example my main project right now is based on Etherpad which was originally written in Rhino which is a Java-based JavaScript. They saved a lot of lines/characters of code by doing it in JavaScript originally which was good software engineering since less code means fewer defects and JavaScript runs on both the browser and server which is also helpful. However, it was built on Java which has dated overly complicated APIs and Rhino is an inferior JavaScript engine. And we can't get it to stop freezing up/crashing at random times, which according to one of the former Etherpad team members is normal.
So we are following the lead of Etherpad and converting the application to be based on Etherpad Lite which is a running on Node.js which is another next big thing. There are no threads, so I know that can't cause any freezing. The V8 memory management and code generation is state of the art. The system will use an order of magnitude fewer resources than the old one. The asynchronous Node execution model and APIs are obviously superior to Java. At least its obvious to me.
>So we are following the lead of Etherpad and converting the application to be based on Etherpad Lite which is a running on Node.js which is another next big thing. There are no threads, so I know that can't cause any freezing. The V8 memory management and code generation is state of the art. The system will use an order of magnitude fewer resources than the old one. The asynchronous Node execution model and APIs are obviously superior to Java. At least its obvious to me.
All of those assumptions are broken, some more heavily than others...
I imagine using Go to write high-performance code or interact well with system libraries is not easier or simpler than a C++ approach, and certainly having worse results.
Also, the comparison to CS/JS seems unfair as Go is not just a syntax change to C++ and has very different a programming style and design goals.
Maybe it would be better to learn more about Go and rationally evaluate its use in those cases rather than using your imagination.
I'm not sure what you mean by unfair. Its certainly far from an exact analogy but there are interesting similarities.
That is true that Go is not just a syntax change to C++ and that it has a very different programming style. Many of the design goals of Go may be different, but maybe not quite as many as you think. My impression is that a primary design goal for Go is to be a powerful systems programming language allowing high performance processing, especially (but not instead of) via parallelism.
I based my assumption off of a quote I heard that was along the lines of, "It is often better to write in the language of the OS when doing systems programming." My personal experience with FFIs and C bindings was extremely boring and tedious. C and C++ may be worse languages but are the obvious choice when dealing with libraries written in their own language.
> My impression is that a primary design goal for Go is to be a powerful systems programming language allowing high performance processing, especially (but not instead of) via parallelism.
That seems true, although unfortunately the current implementation isn't there yet judging from the Benchmark Game:
The top implementations for languages like Haskell and CL are both higher level _and_ faster than Go's.
I can't agree more with your quote, "selection of base technologies, [...], is generally a NOT rational process, but rather an emotional and subconscious one." Let's face it, Go is only popular because it's creators are popular. There's nothing really wrong with it, but there's also nothing it truly shines in.
Specifically say you want an application which is both highly concurrent and also binds to some C libraries. How does that actually compare in terms of complexity, ease of adaption for someone with a traditional imperative background, tedium and performance to C/C++ or Haskell/CL?
I would also argue that although Haskell and Common Lisp are higher level, they have other issues with complexity, syntax and possibly the actual paradigm, libraries, etc.
But it boils down to the fact that selection of base technologies, like all of the most important human decisions, is generally a NOT rational process, but rather an emotional and subconscious one.
One thing that's interesting to me, and I know this will be hard to buy/comprehend for many Go/C++ programmers, but a similar thing is actually happening with JavaScript versus CoffeeScript.
Its amazing because the languages actually have the same capabilities and the syntactical advantages are so obvious.
Here is an example rationalization against the adoption of CoffeeScript from http://oscargodson.com/posts/why-i-dont-use-coffeescript.htm... :
`` You really need a transpiled language to save you some time from learning the right way to write JavaScript in the first place? Learn JavaScript's pain points and just don't do them.
It's like that C/C++ quote goes:
"In C++ it's harder to shoot yourself in the foot, but when you do, you blow off your whole leg." -- Bjarne Stroustrup. ``