News for hackers. Stuff that matters.
Re:Bandwidth needs halved by new compression written in Go by shanelja on Tuesday February 26, 2013 @12:11PM (#5286857)
I've never used go professionally and most of my spare time is split between C++ and Scheme at the moment, but when I did go spelunking with Go, I found it a breeze to write complicated functionality in it - it felt like C++, but easier and more initially powerful.

I still feel that C++ is generally a better choice, but if I only had a short time to write something in, I would definitely go for 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?
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++.

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

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.

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.

Re:Bandwidth needs halved by new compression written in Go by mseepgood on Tuesday February 26, 2013 @05:48PM (#5289219)
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 ?

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.

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