Hacker News Reader

> Golang competes more with gc languages/runtimes like Python/Ruby/Nodejs.

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

To me, coming from Python and Node (and a bit Ruby) development it seems as a completely opposite direction -- similar to going back to C++ or Java (where I started myself).

If not for the quirky syntax and lack of generics I would personally pose it as a replacement for the C++ itself.

Rust on the other hand seems to me to be the most promising out of these three as a systems language.

>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.

    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...

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.

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.

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.

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.

I've actually considered Go for a personal project over my usual Python - the deployment simplicity of Go (a single executable) being a big attraction.

Where I am puzzled is people viewing Go as something comparable to C/C++ - it seems on a completely different level to me.

Plus, as Andrei says himself, D has a GC and it's impractical to work around that in D. So, from that point of view, only Rust can compete with C/C++.

Right. I clarified that I meant D's usage explicitly avoiding the historical GC. I'm not a D expert but it looks like the GC obstacle is mostly in the libraries and not impeding the language syntax.

It's a whole-ecosystem issue. There are plenty of built-in features that happen to depend on GC, and while the ways to eliminate GC use are only increasing with time, the "idiomatic D style" is left in doubt when it's so dependent on allocation strategy. Precision choices for performance are characteristic of D - you have a lot of options to type or annotate your code towards a certain envelope of performance, or ignore almost everything and leave it to the GC. So this is not an unfamiliar problem, but it's a point of friction in the same way that borrow-checking poses friction for Rust - the friction may be centered on what you want for your problem domain.

If nothing else, you can write C in D, in a roughly similar way to how you can write C in C++ - the features are there, and so are the libraries.

There is movement to allow to not use the GC. Changes on the standard lib and on the language itself. Even there is movement to include support for ref counting.

We have to thank Microsoft and Oracle for C++'s comeback to the news.

Microsoft for their work supporting the standards work, C++ conferences, push to improve language's safety. Also the change to back to native since the Longhorn failure that has switched focus to C++ and driven .NET to improve its AOT story, starting with Windows Phone 8.

Oracle by dropping the ball on Java support (JIT and AOT) for the mobile OSes, making C++ the only option to write portable code across all mobile OSes.

As for Go suitability for real systems programming, as a language geek and former Oberon fan, I think the day someone shows a Go bare metal runtime on top of something like Raspberry PI, the opinions will change. Thesis idea. :)

> making C++ the only option to write portable code across all mobile OSes.

Objective-C is also an option. Last I checked there were at least two options for ObjC on Windows and Android. More on Android, IIRC.

For many of us it is not an option, if it isn't in the official SDK.

Since many years I only work with platform languages.

So Google doesn't offer it on the NDK, it isn't an option on Android, even if third party do make it available.

Microsoft still isn't fully done with their clang integration, so still not an option as of today.

That is a valid choice. However, I think there is a difference between "that's not an option for me because of my preferences" and "that's not an option, period".

> "that's not an option, period".

That is the answer we get from customers. Dev machines are managed by their IT.

My preferences are the customer preferences.

(AAA games, commercial software like AutoCAD and MS Office), [C++] became even more entrenched.

If you're building Windows desktop "productivity" software, your options are basically which version of the Microsoft C+ API you want to work with. Microsoft are trying to migrate people to C#, and there are a few Java desktop apps (mostly java IDEs like Netbeans and Eclipse).

Similarly for (Windows) games: C++ is the only realistic option, although smart developers will embed a scripting language for the game logic (eg Lua for WoW). If you don't embed a language, the configuration system ends up being a badly specified Turing complete mess anyway.

So I wasn't really involved in tech in 1995, but it seems like at that point C/++ was the only mainstream option for writing code.

Hell, PayPal wrote their web app in C and still maintains it.

I would say that besides the niche that C/++ is in now, Java (and GC languages in general) did win.

"Win", "die" and other such terms are nonsensical when referring to programming languages. What happens in reality is that the new language carves itself a niche, taking more or less from the market of the old language.

And Java has carved itself a really nice piece of the pie, but it's unlikely that it will expand any more, because it's already dominating in its target niches and doesn't have much to offer where it is not dominating.