Another Go PR story.
Same thing could be easily achieved using futures or any of the asynchronous libraries available to C++, Ada, JVM and .NET languages.
Bandwidth needs halved by new compression written in Go
111–120 of 121 posts
Re: Bandwidth needs halved by new compression written in Go
#112Earlier quoted context omitted.
I agree. The benefit of using Go is that it's fast to write and has good concurrency features. To give you an idea of the size, there are 7,329 lines of Go code in Railgun (including comments) and a 6,602 line test suite. In the process we've committed various things back to Go itself and at some point I'll write a blog on the whole experience, but one thing that made a big difference was to write a memory recycler s…
Go does look awesome. I've spent some time with Erlang, Clojure and Scala (roughly in the order that I liked them most), but Go passed the "get started writing useful code quickly" test better than any of them. Haven't gone beyond the basics yet, but I think it might occupy a sweet spot of ease of use combined with "power", loosely defined.
And when you need generics...
Re: Bandwidth needs halved by new compression written in Go
#113Earlier quoted context omitted.
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.
I'm curious, if you can get things done more quickly in Go, why do you feel C++ is generally a better choice? Performance?
Generic code?
Re: Bandwidth needs halved by new compression written in Go
#114Earlier quoted context omitted.
"write a memory recycler" sigh This is by far go's biggest wart IMO, and one that frequently sends me back to a pauseless (hah! at least less pausy:) systems language. I sure do like it in almost every other meaningful regard. But I wish latency wasn't something the designers punted on.
> I wish latency wasn't something the designers punted on. The simplistic GC isn't part of the language design, it's a stopgap in the first version.
Do they have a standard ABI or FFI for interaction with C? If so, they probably designed the assumption of a conservative GC into it. You can always make an incompatible change, but it's a pain.
Re: Bandwidth needs halved by new compression written in Go
#115Earlier quoted context omitted.
http://www.jobscore.com/jobs/cloudflare/technical-customer-s... Not going to lie - I'm heavily considering taking this as an entry level position to get my foot in the door.
How about just emailing them? I feel like I've seen these kinds of 'wow I where do I apply for a job' posts on cloudflare news articles before. Smells like astroturfing.
I have emailed them.
Re: Bandwidth needs halved by new compression written in Go
#116The title suggests that there's something unique about Go, either the language or its standard library, that enables bandwidth savings. In fact, Cloudflare have written some software which they claim enables them to reduce their bandwidth, and this software happens to be written in Go. This might be an excellent choice (and I suspect it probably is), but it's not Go per se that is reducing the bandwidth usage.
The title only suggests something unique about Go to those who didn't read the article. There's a good chunk of that article dedicated to discussing the language choice and how other languages could have been used instead but -in this specific instance- wasn't chosen. The language choice is as much a part of the topic as the compression routines themselves. So it makes a lot of sense to include the term 'Go' in the t…
>The title only suggests something unique about Go to those who didn't read the article.
The thing is, many people use the title to determine whether the article is worth reading. As is, the title suggests that there is something unique about Go that reduces the bandwidth needed by the program, implying that this is something that other common languages fail to achieve. This is obviously impossible (any widely used language is capable of serializing an output byte stream in any way the programmer desires). As a result, the title sets off the alarm for "Language fanboyism", and "mathematically impossible claims", and goes swiftly into the "don't bother" pile together with "universal lossless compression algorithm invented!"[1], "perpetual motion machine" and "My favourite X language is faster that C/C++/Assembler!1!1"
Re: Bandwidth needs halved by new compression written in Go
#117Earlier quoted context omitted.
Because that’s one approach to getting the most out of all of those multiple core CPU servers. For Go that came for free because its Communicating Sequential Processes design does that for you.
Came for free? Go takes advantage of multiple cores by using threads. CSP doesn't magically multiplex your code onto your cores.
> CSP doesn't magically multiplex your code onto your cores
Take a look at this Rob Pike video: http://blog.golang.org/2013/01/concurrency-is-not-parallelis...
Now that video might well be crap, I'll be the first to admit I'm not skill enough to know one way or the other.
But based on that video, it does appear to me that Go does offer some form of multi-core magic and it does appear to come at a minimal cost.
Re: Bandwidth needs halved by new compression written in Go
#118Earlier quoted context omitted.
The title only suggests something unique about Go to those who didn't read the article. There's a good chunk of that article dedicated to discussing the language choice and how other languages could have been used instead but -in this specific instance- wasn't chosen. The language choice is as much a part of the topic as the compression routines themselves. So it makes a lot of sense to include the term 'Go' in the t…
>The title only suggests something unique about Go to those who didn't read the article. The thing is, many people use the title to determine whether the article is worth reading . As is, the title suggests that there is something unique about Go that reduces the bandwidth needed by the program, implying that this is something that other common languages fail to achieve. This is obviously impossible (any widely used…
> The thing is, many people use the title to determine whether the article is worth reading.
That same argument could be used for having the language in the title as people who are not interested in programming are going to be less interested in a thread about programming.
And language fanboyism is going to happen with or without this title (given the content of the article). What's happening here is more a case of lazy members wanting to commentate on articles they've not even read. It's basically the lowest form of blogging.
Re: Bandwidth needs halved by new compression written in Go
#119Earlier quoted context omitted.
rsync is going to perform checksums on blocks to see if the blocks are the same. It transmits these checksums, and where the checksums differ, it deltas the blocks. Note that insertion/deletion in a file can push block boundaries off between two files, causing a problem known as "stream alignment", which can cause your binary delta to be much larger because it doesn't realize the block really shifted 16384 bytes over…
I always thought rsync detected block moves and that's what made it a worthy PhD thesis.
Yes, I simplified and I shouldn't have.
It does detect them, but it does have a minimum size of block move it can detect due to the signature matching method.
Re: Bandwidth needs halved by new compression written in Go
#120Earlier quoted context omitted.
Came for free? Go takes advantage of multiple cores by using threads. CSP doesn't magically multiplex your code onto your cores.
> CSP doesn't magically multiplex your code onto your cores Take a look at this Rob Pike video: http://blog.golang.org/2013/01/concurrency-is-not-parallelis... Now that video might well be crap, I'll be the first to admit I'm not skill enough to know one way or the other. But based on that video, it does appear to me that Go does offer some form of multi-core magic and it does appear to come at a minimal cost.
It's not magic. It's threads. Go multiplexes your goroutines onto N OS threads. There are also abstractions in C/C++ (though of course as libs, not part of the language, like in Go) which hide the usage of threads. But there is no magic. If your code is running in parallel, your code is using OS threads.