Hacker News Reader

Comment by songgao | Hacker News Reader

Well, I liked C++11 a lot. But now I think I'll replace it with Go whenever possible. I don't really mind so much the verbose syntax. What matters is how difficult it is to write efficient code.

I recently rewrote one of my C++ projects(which uses C++11 features and Boost.asio) in Go. It took me half the time, less than 2/3 lines of code compared to the C++ version. This is expected. But most surprisingly, despite that I tried my best thinking about how to make it as efficient as possible in every detail when writing C++ version, and that I'm quite new to Go, the Go version still achieves nearly 100% higher throughput than C++ version.

Maybe my C++ skill sucks. But I guess I'll just let it suck.

View on HN

Go is certainly a fine language. One common instance where I would prefer C++, though, is when you are writing libraries for others to use. A language that runs on a VM can not easily be used as a library inside a language that uses another VM. You cannot easily write a library for Python in Go or vice versa. If you use a VM-less language like C or C++, your work can be used (through various wrappers, like SWIG or that Apache thing) by everyone.

Doesn't Go compile to machine code as well without a VM in between?

Go has garbage collection, which I think some people confuse with using a VM.

It has a runtime statically linked. All linking is static and std call interfaces are not exposed so you cannot expose libraries to other language bindings.

If you want libraries for others to use, just use plain C. C libraries are trivial to use in almost all languages (from Ada to Yorick).

I have worked on a large C++ program that uses Python for UI and some scripting components. I don't see why it would be harder for Go to use Python. Also, Lua is used everywhere.

Hey, hey my story is like yours. My go-to project (ha) is one that I've written in Boost.asio though it was back when C++11 was still C++-0x, but I also switched to Go for the project and saw gains in how easy it was to write efficient code. To be fair, threading is much easier now, but then again, it's still threading...

It's not essentially threads since multiple goroutines are mapped onto one thread (or more if set). It feels like threading but you could just use it as much as you need since it doesn't bring as much overhead as a thread :-)

Check this out: http://en.munknex.net/2011/12/golang-goroutines-performance....

Sorry, that was my point. The new concurrency stuff in C++11 still isn't the same as go's goroutines. Certainly my application would not work very well if a goroutine mapped to a thread. :o

Aha, I got you now :-)

Reply on news.ycombinator.com