Bandwidth needs halved by new compression written in Go

Re:Bandwidth needs halved by new compression written in Go by pivo on Tuesday February 26, 2013 @03:39PM (#5288425)

I'm curious, if you can get things done more quickly in Go, why do you feel C++ is generally a better choice? Performance?

[ Parent | on HN ]

Re:Bandwidth needs halved by new compression written in Go by jlarocco on Tuesday February 26, 2013 @06:17PM (#5289353)

For me, I just don't see enough benefits of Go over C++. I already know how to use C++ in a way that avoids or mitigates the problems Go solves. With C++11 support starting to take off Go's advantages are even smaller.

On the other hand, if I didn't know C++ and I was looking for a native compiled language to learn, I'd probably choose Go over C++.

[ Parent | on HN ]

Re:Bandwidth needs halved by new compression written in Go by abraininavat on Tuesday February 26, 2013 @09:13PM (#5290080)

Depending on what you're doing, the libraries make a giant difference. Look over Go's standard library packages and then imagine what a pain in the ass it would be to find and manage all the separate C/C++ libs it would take to replicate all that functionality (or to write it yourself).

[ Parent | on HN ]

Re:Bandwidth needs halved by new compression written in Go by shanelja on Tuesday February 26, 2013 @04:12PM (#5288668)

Performance, I also feel more in control, it's hard to describe the feeling, it's just as though Go is providing an abstracted interface to the hardware, where as C++ provides raw, unfiltered but potentially dangerous access.

Perhaps it's just my personal experience though.

[ Parent | on HN ]

Re:Bandwidth needs halved by new compression written in Go by vanderZwan on Tuesday February 26, 2013 @04:28PM (#5288774)

That kind of fits Rob Pike's explanation for why Go isn't more popular with C++ programmers (although he gave it a negative spin).

In a neutral way, it's like: if you spent all that effort mastering this language to get such fine-grained control, why would you give that up again? And really, I understand: why would you give that up? Especially if you know how to use C++ in a fairly painless way.

[ Parent | on HN ]

Re:Bandwidth needs halved by new compression written in Go by shanelja on Tuesday February 26, 2013 @04:35PM (#5288806)

Do you have a link to that? I would be interested to read it.

I also couldn't agree more, but normally, people retort with the Hammer and Screwdriver argument.

[ Parent | on HN ]

Re:Bandwidth needs halved by new compression written in Go by mseepgood on Tuesday February 26, 2013 @05:48PM (#5289219)

http://commandcenter.blogspot.de/2012/06/less-is-exponential...

[ Parent | on HN ]

Re:Bandwidth needs halved by new compression written in Go by pjmlp on Wednesday February 27, 2013 @02:30AM (#5291145)

> Performance, I also feel more in control, it's hard to describe the feeling, it's just as though Go is providing an abstracted interface to the hardware, where as C++ provides raw, unfiltered but potentially dangerous access.

Funny I though C++ did exactly the same thing. Where are the L1, L2 and L3 caches references, multiple opcode execution pipelines, processor instructions ?

[ Parent | on HN ]

Re:Bandwidth needs halved by new compression written in Go by eru on Tuesday February 26, 2013 @09:56PM (#5290233)

> where as C++ provides raw, unfiltered but potentially dangerous access.

Wouldn't that be assembly? Last time I heard Stroustrup, he was all raving about abstractions, not raw unfiltered access.

[ Parent | on HN ]

Re:Bandwidth needs halved by new compression written in Go by pjmlp on Wednesday February 27, 2013 @02:33AM (#5291158)

Generic code?

[ Parent | on HN ]