Hacker News Reader

Comment by jasode | Hacker News Reader

>I still cannot even grasp this trope. Seems like some try to apply "fake it till you make it" approach.

It's not a fake trope. There are tons of blog posts from programmers describing experiences of switching from Ruby+Rails to Go, or Python+Django to Go, or Javscript+NodeJs to Go. Some defections were high profile such as Nodejs uber-contributor TJ Holowaychuk switching to Go.

Compare that to virtually zero notable stories of C++ projects switching to Go. If people are using C/C++, they very likely depend on it for the performance characteristics and therefore switching to Go to suffer a speed penalty makes no sense. On the other hand, people leaving Python/Ruby report performance gains. That's why the reality on the ground looks the way it does.

View on HN

    Compare that to virtually zero notable stories of
    C++ projects switching to Go.

A lot of projects at Google have switched from C++ to Go, and the people I know who work on them are pretty excited about working in Go. Here's a blog post by a coworker who leads the Chrome Data Compression Proxy project:

http://matt-welsh.blogspot.co.uk/2013/08/rewriting-large-pro...

Thanks for the example. I think your coworkers' rewrite further reinforces the "sweet spot" for Go.

The transcoding was left as C++ but the other stuff including the networking was rewritten in Go. That makes sense to me because transcoding is performance intensive and cpu-bound instead of io-bound. (E.g. CPUs pegged at 100% while bytes being read at a slow 10MB/sec.) In other words, if people tried to rewrite ffmpeg in Golang, a conversion job such as avi to mp4 would run slower.

If Google's internal cpu-bound projects switched from C++ to Golang, that would be a very interesting data point. In other words, I don't expect Google would switch their machine-learning algorithms scanning petabytes of data from C++ to Go (or create greenfield machine learning projects using Go instead of C++).

Well... you know, G+ is full of Google Employees...

People also seem to underestimate the performance difference. Sure, Go is around 20% slower than unoptimized C/C++ (at least, with a numerically heavy algorithmic trading library I use that I've ported to Go). But when I use a great C++ compiler that vectorizes and gives me hints to improve cache performance (eg; Intel's compiler) it's often 2-3x slower.

In a tight loop, you can't afford to have a gc or green-threads or a runtime for that matter. You want excellent cache performance, minimal context switching, and very predictable memory access patterns.

Manual memory management is here to stay.

Don't get me wrong, I love Go (for the right uses) but it's just never going to be a replacement for C/C++/Fortran for high performance code.

Performance is not always the most important factor.

Also I don't know about Ruby but Python is moving really fast with PyPy.

We also have Cython. This is where I'd go when the extreme performance is needed. This way you can avoid compromising on other important factors (libraries, accumulated know-how, even syntax and development tools).

In case of NodeJS it's even more baffling.

> Performance is not always the most important factor.

But then why would anyone choose C++ for such a project, in 2015? (Aside from people who only use C++ and therefore wouldn't use Go either.)

(I can think of a number of other reasons, like exposing C interfaces or interoperating with GC'd languages, but I don't see how Go fits these things any better than most other GC'd languages.)

A lot of it is due to library support; C++ has libraries in physics and graphics haven't yet been written in other languages.

Another is the lightweight possibilities for C++ makes it possible to install and run good apps on tiny machines like Pis, where installing Java can be much more challenging.

C++ is also a great language for iOS and OSX development for those who are not satisfied with Objective-C or Swift.

If you use C++ instead of Objective-C or Swift for iOS/OS X development then it is just because you refuse to learn something new. The only use for C++ on iOS/OS X would be algorithm heavy code. C++ is a poor language for dealing with GUI or higher level concepts in an app.

Compare the elegance of stuff like Core Data, bindings, target-action, undo framework, predicate filter using Objective-C with how kludgy stuff like that ends up in C++.

I know because I have tried implementing similar stuff in C++. It is possible but it looks like shit.

One huge reason to use C++ on iOS is to avoid platform lock-in and for code sharing. How can you miss such a blindingly obvious reason?

And it is right on par with other languages when it comes to GUI building as Qt proves. However, something like QML in conjunction with C++ will be much more flexible and pleasant to use than any of C++, Objective-C or Swift.

CoreData is widely considered to be more trouble than it's worth it, as soon as you want to do some serious work. Predicate filtering... maybe I am missing something, but I'd pick <algorithm> + lambdas any day over that kind of magic. I have used Objective-C to write production code, and with few exceptions, I would consider it anything but elegant. It's a hodge podge of concepts thrown on top of eachother that's finally and deservedly being put to rest by Apple.

I certainly agree with you for using platform-specific languages for platform-specific features. But I much prefer to write the main logic of an app in C++ and use Swift as the glue to the UI rather than use Swift for everything. I'm not yet sold on Swift, and being unable to take the code to other platforms is also a strike against it, for now.

Reply on news.ycombinator.com