While Go is quickly eating into my use cases for Python in my own work, I'm not really sure that there's a connection here. Guido's employment at Google was a little more than simply, "Python's a cool language, so let's hire the main Python developer so we can use Python at Google."
Furthermore, Google's vision for Go isn't as a replacement for what Python does - the fact that Go can satisfy many of Python's use cases is by coincidence more than by design.
It bears mentioning that Python can satisfy many of Go's use cases too. A fairer way to put it is that there is a lot of overlap across modern programming languages
That's not exactly true: that' why something like twisted (and later async frameworks) was invented in the first place.
What is not possible is non-process-based, CPU-bound concurrency. Generally, python is poor choice in those cases anyway (there are exceptions of course).
You don't. But without something like them (or microframeworks + libs) you're going to be rewriting a bunch of stuff yourself. On top of that, security sensitive parts (session management, CSRF protection) that get hand-rolled will need a significant amount of testing.
If you have the time and resources though... go for it!
Edit: But it does seem like there's already some contenders for Go's go-to framework (Like Django/Rails are for their respective language)
My point was that you don't need huge frameworks with high barrier to entry to write web applications -- the things you mentioned can be handled by external modules just as well. Need captcha? Find the best captcha package and use it.
Yes, and tomorrow that captcha package is abandoned, left to rot, etc. Or some other library you used. Especially since most Go packages are one man shows in GitHub (3-4 abandoned MySQL drivers, etc).
I'd rather have a framework with a community that ensures that it is guaranteed to be maintained in the future.
C++ gives you an insane amount of control, is exceedingly manual, hard to use, hard to learn, and you can easily screw yourself over by using it - but it gives you so much performance that it's worth the necessary expertise.
Go tries to be safer and more automatic, like Java. While it's more organized and prescriptive than C or C++, it's less religious than Java about everything being a class. So it encourages the pragmatism and low-levelness of closer-to-the-metal languages while also abstracting out a lot of the details which get in the way of just writing systems.
I still can't grok why people pick C++. Is it just a Windows specific thing? If someone wanted speed of execution, why not use Ansi C? If someone wanted object oriented programming, why not the myriad other languages? (Java comes to mind) What does C++ do better than all the languages?
> If someone wanted speed of execution, why not use Ansi C? If someone wanted object oriented programming, why not the myriad other languages?
Because they want both speed and OO programming? :)
C++ is a multi-paradigm language. It has more abstractions than C, while retaining the ability to get down to the metal when you need to. Arguably, these higher level features are desirable when working on larger code bases. C++ also has features that make it easier to write clean and correct code (such as RAII). Templates and operator overloading makes for writing expressive libraries. I remember reading and article that compared C and C++ in the context of a matrix library. The C++ code was much more concise and readable, and was easier to get right compared to C, mainly due to those two features.
Furthermore, C++ can actually be faster than C. The canonical example is the templated std::sort() vs C's quicksort(). The C++ compiler is able to inline the comparator argument to the former, whereas qsort() takes a function pointer.
While I don't have personal experience with it myself, things like games lend themselves well to a limited use of OOP but also require performance-critical code and tight control over the language. With static analysis tools, I bet that C++ could be audited more comprehensive through automated tests than C could be.
Apparently the remaining C++ users are really fixated on something called zero cost abstractions, and it's not a goal of Go: "Zero cost isn't a goal, at least not zero CPU cost. Go's claim is that minimizing programmer effort is a more important consideration."
(though I don't think C++ succeeds in "zero cost abstractions")
You show your ignorance again. Do you think that go does not use operatingsystem threads in the background? Do you think the same abstraction could and has not been built for java? How do you think does the Erlang impmentation on Java work? How do you think that scala can start so many actors? How do you think the forkjoin framework works?
You quote things you don't understand. n goroutines (where n is big) get multiplexed to m threads (small m, typically numbers of cores). Goroutines are cheap: each goroutine starts at a size of 4k, and creating them is a really cheap operation. Please show me a Java thread implementation with the same properties. Good luck with that.
>n goroutines (where n is big) get multiplexed to m threads (small m, typically numbers of cores).
You had the same thing in early Java with green-treads -- it is abandoned for modern JVMs, but you can mimic it. You can have millions of Scala actors.
>Goroutines are cheap: each goroutine starts at a size of 4k, and creating them is a really cheap operation.
Yes, but handling and migrating them is a "not really cheap operation". They are mostly useful as abstractions, as for performance you don't get anything over Java (if not worse: checkout Go vs Java concurrency benchmarks).
>Please show me a Java thread implementation with the same properties. Good luck with that.
Not sure I need all that "luck" you wish me. How about Java on Solaris, which multiplexes java threads to native threads?
Why do you need to hire the developer of Python in order to use it at google? Or do you mean they got him to better use python or to have close insight about a core language?
Or do you mean what he's going to be doing at a Python-heavy company like Dropbox that's trying to scale hugely performance-wise while building a lot of new features? (And yes, the link is in the original post as well as everywhere else on the net.)
