These slides are practically unreadable in an iPhone. They are split in half and it's impossible to get a full page on the screen (I can only see the right half of the previous slide and the left half of the next slide).
Anybody has an alternative to read these slides? The content itself seems quite interesting
"The table below shows the section numbers of the manual followed by the types of pages they contain.
1 Executable programs or shell commands
2 System calls (functions provided by the kernel)
3 Library calls (functions within program libraries)
4 Special files (usually found in /dev)
5 File formats and conventions eg /etc/passwd
6 Games
7 Miscellaneous (including macro packages and
conventions), e.g. man(7), groff(7)
8 System administration commands (usually only for root)
9 Kernel routines [Non standard]"
So section 3 is a little wider than that, eg:
$ apropos apache::xmlrpc
Apache::XMLRPC::Lite (3pm) - mod_perl-based
XML-RPC server with minimum configuration
Second this. One of my favorite things is getting a slice, however small, of how truly great programmers get their work done, why they chose what they did, and what the results were.
Browsing the go goog client source is 30% of it. Go and others could use screencasts of how they fixed production problems, regardless of what lawyers, job security worriers or "hide the dust" folks would say. Mindset is best communicated by solving something real.
I have no affiliation with either Google or Mozilla but I pretty much always upvote articles concerning Go and Rust simply because I'm interested in those languages and want to encourage more articles about them to be posted.
At some point there were quite many Go articles without much substance. These articles were also very predictable. The positive articles contain pretty much the same enumeration of Go features (goroutines, channels, imports, etc.) or how they rewrote a five year old, now well-understood, failing Python subsystem in Go and have massive improvements (surprise). The negative articles pretty much all complained about how not using an import results in a compilation error (surprisingly, the lack of generics are only mentioned in comments ;)).
But these slides were genuinely interesting to pretty much the whole HN audience: it covers architecture decisions, the effect of code rot, the breadth of the Go standard library, a new object caching system, and a real-world example of Go usage.
tl;dr even to someone who is a bit critical towards Go (ie. me), it was a very interesting read.
Totally. We should spend more time speculating about every move of Snowden and examining every new piece of fluff in the media about the NSA; linking to actually interesting programming-related content is so 2012.
What this actually means: groupcache is awesome. You just act as if the cache is full, and if it isn't, it will be. Where did the data come from? That's pluggable. And no concern of the part that just serves it up. Very subtle, very nice.
What this actually means (2): Go standard library has reasonable performance.
This won't work so beautifully when whoever implemented all the magic bits under your business logic didn't do so to deliver reasonable performance for your use case.
Or if the underlying code is in fact wrong. This turns into the kind of code you can see from Line 242:
We optimise the standard library for the majority cases, and putting the download server into production helped us improve Go's HTTP stack for everyone. Similarly, when other users report issues with our standard library, we fix them.
The file you linked to contains some code to accommodate a bug that existed in Go 1.0 and was fixed in 1.1. Not sure what the relevance is here though.
The new software relies heavily on the Go net/http implementation of a HTTP server. That is arguably a very very big chunk of the complexity in a HTTP download server.
So it leaves a bad taste when the presentation mocks the original C++ implementation while the Go solution only works because there is a fully functional high performance HTTP server already in the standard library.
There is not a single slide that tells us it may not be a good idea to rely on the standard library for such high-level functionality. Thats why I linked to the bug. A normal user has very little options when it turns out theres a bug in the standard library, other than to report it and wait for you to fix it. The problem is exacerbated since standard library and language versions are tightly coupled.
Lol, anyone who says 'it's trivial to maintain a fork' about anything has obviously never done so - especially when suggesting in the same sentence that the licence of all things is one of the harder issues when maintaining a fork.
For most things go is used for right now, you'd normally not run into issues with distribution as defined by LGPL and GPL? (If you use it to deploy something as a service).
Anyway how would the GPL make a difference to your forking of the std lib? Either you link to the standard lib and all your code (that is linked into that binary and distributed as such) falls under the GPL, or you don't -- whether you distribute a patch (set) doesn't seem to change anything?
I'd much prefer to rely on a well tested HTTP library than roll my own. If I discovered bugs that the upstream maintainers refused to fix (for whatever reason) I would just fork the library and fix the bugs myself. You'd have to fix many more bugs if you rolled your own.
I don't understand your point. A normal user has very few options when it turns out there's a bug in their off-the-shelf standalone webserver, too. They can fix it themselves, work around it, or report a bug and wait for someone else to fix it. Exactly as in Go.
Are you saying everyone should write their own HTTP server from scratch?
Packages in the Go standard library are no different from user packages – they're just included in the Go distribution. If you find the need to modify anything in net/http (to fix a bug, add low-level hooks, etc), just copy it into a subfolder in your project, like so:
> cp -R $GOROOT/src/pkg/net/http ./net/http
Then simply change all "net/http" imports to "./net/http". Now you're free to carry out any changes you'd like.
P.S: Just because you can do this doesn't mean you should.
What I'm about to say is a little trollish, but if you use words like, "Business logic," whatever you're writing probably doesn't need to be faster than Go. And anyway, if performance sensitive bits are your thing, cgo is probably the best FFI outside of C# that I've ever used.
Also, it's a sign of a defective language that the library guards against old environments? Really?
I don't understand the need for the payload server from the slides. That makes me wonder - why not just use a HTTP server to serve the static files (e.g. nginx)? I'm sure I'm missing the obvious, but I'm probably not the only person wondering it.
I wondered the same thing. Why not handling the connexion and serving the files through a regular event-based server like nginx, and handle the specific business logic in java or any other popular language inside Google.
I guess that some details on the slides would answer those questions, but if anybody here know the answer (some slides were pretty obscure if you're not already familiar with file serving and/or google architecture).
From the looks of it, they wanted support for putting files in place before a release date and easy per-file header/caching/access control. Add in a few other miscellaneous features and make it available to everyone and you're at a point where an HTTP server probably won't cut it.
Files also apparently come from some central repository and need to be synced.
I think the biggest reason would be that almost any off-the-shelf server software would struggle in a Google server environment. They have solved scale at the machine level, and he alludes to this on one slide:
... why aren't you using the cluster file systems like everybody else?
... cluster file systems own disk time on your machine, not you.
Slide 62 mentions the proprietary bits: ACL policies and RPC storage access. Does an off-the-shelf httpd support ACLs? How easy would it be to make them support google storage instead of a file system?
(I wrote a rough equivalent of "payload_server" in Go at my current employer to solve authentication, access control, and some other business logic issues.)
> Does an off-the-shelf httpd support ACLs?
Not really. You inevitably end up writing custom code to conform to your particular requirements and/or existing systems. If you want high-performance, you end up writing it in C as a module for Apache/nginx/whatever.
> How easy would it be to make them support google storage instead of a file system?
Unless said storage system is presented to userspace through ordinary file interfaces, same as above. There's no general turn-key solution built into webservers. The problem space is too wide.
Using Go in this way gets you good performance, simple architecture, maintainability, and easy deployment with total flexibility to do whatever you need in order to solve your version of the problem. There are no straightjackets, you don't have to conform to (or find ways around) anyone else's conception of the problem space.
It appears from slides 14, 21, and 24, that copying all of the static files that needed be served onto a single machine could take over 12 hours. Another way to say that is that the totality of content that is served from that single host is too large to put on a single machine. The "groupcache" abstraction lets the http-serving machines dynamically serve the hot subsets of the larger file set (represented by "storage svc" on slide 55).
But nginx can work as cache, acting as reverse proxy on misses. Minor amount of Lua scripting or C (or, better, whatever fancies one's taste if that could be called from C) hacking can teach it any reasonably complex semantics (fancy ACLs, not-before dates etc.). Many modules (dynamic archive generation, GeoIP, various cache backends) are already there, well tested in production environments.
Surely, one would probably need a separate external tool that would pre-fill (nginx wouldn't know that some file's pending before it's requested) and clean up caches (provided that rules are complex than trivial LRU removal on some threshold), as one probably wouldn't like webserver doing this unsuitable job, but that should be another story.
It appears to be a caching proxy that has some very specialized features like dynamic zip files and what appears to be origin server notifications which you don't normally see in off the shelf caching proxies like say, Squid.
Then again, I'm not sure why the caching wasn't better handled in the CDN that lives in front of it (cache hierarchies work well) leaving this server to simply serve only the very first request.
I don't know if its that old, but there was definitely a talk on this presented some time back. From what I remember, there was a lot of HN discussion around "well that's great but its just a download server" and some other people saying "yeah but its a complicated download server".
It could be least a year old, title from a slide: "Summary of 5-year old code in 2012", but then again perhaps that's when they started the re-write in Go.
The Go rewrite of dl.google.com happened last year [1]. Today, Brad Fitz gave a presentation about the rewrite and open-sourced a component of the rewrite, groupcache[2].
I don't remember where I saw this, but somewhere, someone from Google said that all of their code changes every 5 to 6 months (or some reasonably short amount of time). That clearly sounded... optimistic at best. It's nice to see that even companies like Google have 5 year old old that is legacy and causing problems.
Edit: Scanned the source, looks a like a best-effort distributed lock, rather than any sort of consensus protocol. This works for a cache setting, where e.g. having a split-brain scenario and duplicating the work is no big deal.
I was thinking about that too, but since it is not possible to change existing items and the computation of those items must be re-entrant (groupcache just tries to avoid duplicate computations but does not guarantee it), there seems to be no reason for any distributed consensus. In fact, the groupcache design is astonishing simple.
So what I take from this is that the previous implementation sustained a huge amount of code rot and new code got layered over it with a staple instead of proper re factoring.
So he put the whole mess in a bin and re-done it cleanly with Go. Now it's much nicer. Some of Go's attributes helped along the way.
Yes. In my opinion the biggest win comes from goroutines and Go's runtime, which essentially allow you to write asynchronous non-blocking multi-threaded(!)code that looks like synchronous code and is as easy to read and reason about.
This leads to a huge reduction in complexity compared to the callback spaghetti you often get in other async frameworks. Basically putting concurrency first in the language and not relying on libraries seems to really pay off.
You don't have to build goroutines into the language to have lightweight multithreaded tasks. TBB does this for C++, for example. (Edit: I was mistaken about Java here -- apparently it does use OS threads.)
If you want to show that the JVM can do that, a better link is probably Akka: http://akka.io/ Your link appears to be a guy's personal project, which is great, but akka is from what I gather an industrial-strength implementation.
Though as the Node people occasionally point out, it is advantageous to have this sort of thing baked into the language, so that everything done in the language supports the concepts, rather than having a relatively small corner support it. Plus you get Go, instead of Java, which I for one would find an improvement.
Actually if one wants to use Akka, one should be using Scala. Akka using Java is a total pain in comparison. Atleast with Scala, one seldom gets the feeling that the library is far from the language semantics.
I guess, what you miss is that the author was the author of LiveJournal, memcached, now also of groupcache in Go. So the guy who rewrote the program was much, much more capable that any "typical" programmer.
Your comment implies that even Google, which has a reputation of hiring only the best of the best software developers, has "typical" programmers. My faith in the world has just been restored, <3.
Best of the best that apply to Google. Or in other words, their hiring process is "Hire the best people that apply here", or, you know, the hiring policy of every company in the world. You could argue they uniquely attract smart people with some kind of high IQ gravity centered at the Googleplex, but that seems unlikely. Makes for good marketing copy though.
Right, because there's never been a Googler who has ever made a mistake. All of them are perfect and none of them are stupid, never a bad hire made or even a momentary lapse of judgment.
What relevance does that add to this presentation? It's interesting by itself.
What do the presentation (or our discussion) gain from the fact that Brad is a super smart guy "much more capable than the 'typical' programmer"? Why are we even bringing up that point? :)
It adds some validity to the opinions and points he makes? I will certainly pay more attention to a presentation if I know that the presenter has credibility..
A bunch of "typical" programmers wrote a program in C++, and it turned out crappy. A "super smart guy" rewrote it in Go, and it turned out nice. How much of the delta between crappy and nice was due to the language, and how much to the programmer? (And how much is due to the new programmer learning from the old programmer's mistakes?)
As with all anecdotal language advocacy, you have to take it with a grain of salt, and in this case maybe more than usual.
Brad even acknowledges that the original program was nice in it's day. C++ complicated things but it sounded like the bigger problem was developers leaving the team and new features being hackishly implemented.
And don't underestimate "changing environment". As Brad said, "in 2007, using local disk wasn't restricted ... in 2012, containers get tiny % of local disk spindle time ... cluster file systems own disk time on your machine, not you."
Within Google today, if you're directly using local disk instead of the Google storage stack, you're going to have a bad time. Even more so if you're calling read() from a single-threaded event loop.
It gives the fuller perspective. The Go libraries are something very new. People who developed the libraries know them inside out. Outside of that group of people, there's certainly much less knowledge about them. A lot of the claims in the article about the full coverage of some standard in some Go library versus the incomplete one by the given C++ program obviously come from somebody who invested enough time to study the standards and (at least) study the implementation inside of the said libraries. That is, something like that either you know or you can just say authors claim that they adhere to the standards -- which ones, how much; you can't know, much less you are able to compare.
So, for me, that is somebody who didn't follow the state of Go libraries, it was much bigger new information in the presentation the author's certitude that some library covers everything of the standard (good to know how much care was invested there!) than the fact that when somebody has already made some very good tools he can more easily use them then probably anybody else who'd start without such a deep knowledge.
My own takeaway was "now that I know that at least some libraries are very well thought-out that's a good argument to consider when deciding about the use of Go in some future project." Still it's to weight against the learning curve and the quality and ease of use of the available libraries in other more common languages. In that light it's still good to know that the author of the presentation is really very competent.
Not directly related to your question, I also applaud the author's honesty in describing the problem he solved: first, the underlying assumptions changed: I can imagine that the main reason for fetching the data to the local disk in 2007 was that then fetching the data directly from the remote storage was much slower than it is now, making his current approach impossible then. Second, it's not that the original design was as inefficient as the later suboptimal modifications made it. Third, it was a project in which for a while nobody wanted to invest the time to. That's the convenient point to jump in and demonstrate what you can do with the new tools and your knowledge and time. Once you change the equation, a product once almost without the future can become a basis for future much more successful projects.
> The Go libraries are something very new. People who
> developed the libraries know them inside out. Outside of
> that group of people, there's certainly much less
> knowledge about them.
I guess it's a tautology that the people who developed something know it best, but you're being really disingenuous here by implying that only those people would be capable of doing a project like this. Go's stdlib HTTP server takes great pains to be accessible and powerful.
I think the implication was that the developers know the actual capabilities, and so know if there were any dark corners of the standards that were just papered over with stuff that might break in some subtle way, in non obvious use-cases.
So it's a word of confidence that, yes not only is the interface nice, but the implementation is also good (enough) -- and you probably won't regret leaning on it in a future project.
The key point for me is C++ stdlib doesn't include an HTTP stack, while Go's does.
Fair enough, but it was a bit of a foregone conclusion that he wouldn't want to develop/reuse a C++ HTTP stack as he went into the project with the intention of using Go...
The original codebase suffered from reinventing the wheel - badly. By composing together well tested high level abstractions, most of the tricky, broken parts could be removed from the responsibility of the application codebase, leaving only appication specific concerns. It could have been done without Go, but Go provides a good set of tools for the task. In C++ land, on the other hand, there isn't such a clear Right Way to do such things (though there are plenty of options).
Yep, I feel that the main point of the story is "we had crappy code, and rewrote it and now it's great".
Could have been very similar if they'd rewritten it using C++11 features (the main difference being that you'd have to use a HTTP library instead of HTTP being in the standard library, but that doesn't make much difference)...
Actually, an awful lot of the "we rewrote X in language Y" stories on the internet have this as the true story, even if they don't admit it. (The LinkedIn mobile rewrite from Ruby to Node was like this. The official line was all "here's how to kick it in Node", the truth was the original implementation was single threaded across all users.)
That said, I'll happily read this story over and over again, because it tends to provide insight in what works and what doesn't.
Pretty disingenuous on slide 58 to attempt to make the Go code look shorter than it actually is. Note how he left out all the verbose error checking code.
Sorry, wasn't my intention. But it's only 4 more lines. In my defense, I only showed three pages of C++, and not all of it, which would've been longer than the whole presentation. So I cut less from the Go snippets than the C++ snippets.
Your intention was to show the good Go code vs the bad C++ code. The different syntax highlighting colors and the missing error handling code really leave me feeling amiss.
My main gripe and reason for not jumping on the Go bandwagon is the error handling strategy, it was exactly what I wanted to see in the Go version.
Additionally, I think that this comparison would only be valid after the Go version experiences an equivalent amount of developer turnover, features added in a rush by developers inexperienced with the software, external infrastructure changes, and the other pressures that the C++ implementation was apparently subjected to over the years.
The Go code may look good in 2012 and 2013, while it's still fresh. But I'd be very curious to see how it looks in 2017 or 2018, assuming it's still even being used then.
Google's approach to development at least in this part looks very unprofessional.
The have had a bunch of crap code nobody cared about, and then some guy has rewritten it arbitrarily choosing development tools just because of his own preference.
What next, another guy will show up who likes JavaScript and considers the previous work unsatisfactory, and will rewrite everything in JavaScript?
As someone who wrote a lot of Python code ans who is learning Go while implementing a somewhat important application, i can tell you Go is a good replacement for Python if it fits the problem better (mine was concurrence).
Go is pleasant, but there are Go problems an Python problems (and C problems, Lisp problems, and so on)
Maybe I'm showing my allegiance to my platform of choice, but the subtle dig on nodejs wasn't warranted on slide 25 (http://talks.golang.org/2013/oscon-dl.slide#25). As everyone's pal `substack` will tell you, use streams! Instead of explicit buffering, handling backpressure, etc., it's as simple as:
readable.pipe(writable);
Additionally the link to `http-proxy` on slide 30 is misleading; 60% of that file is comments, and about 50% of what's left is websocket support, with the rest being header parsing & redirect parsing. The actual proxying bit is very simple and straightforward, and if you don't need every feature `http-proxy` offers you can do it yourself with streams in < 10 lines.
It wasn't a dig on nodejs. It was a dig at event-based programming, on which I've wasted years of my life in many languages. Node.js isn't unique in that regard.
As I mentioned in my talk, that code looks like fine Node.js code.
But it's still event-based, and the flow isn't readable. In the actual presentation I went through the code to show how control flow jumps around. I picked a Javascript project (and the top hit I got from a search) because people know Javascript.
Websocket support doesn't matter. In Go, you can also just io.Copy(websocket, src).
Have you by any chance seen the async keyword in C# 5.0? It allows one to write event-based code without callbacks obscuring the control flow. From what I've heard Python is in the process of copying this feature. Iced Coffescrip does something similar also.
It's good for C#, but still a language wart that could be built-in. I like that Go only has one set of APIs for everything, not the sync way and the async way.
It's sad that C#, which started out as a fixed-up Java, is now growing its own warts.
I haven't yet tried Go, but I don't see how it could match the performance of C# API with a single function. C#'s async methods offload any IO to the process IO completion port threads, thus freeing the current thread to do more work.
> I haven't yet tried Go, but I don't see how it could match the performance of C# API with a single function. C#'s async methods offload any IO to the process IO completion port threads, thus freeing the current thread to do more work.
Go generally uses synchronous functions, but a function in Go can be the subject of a "go" statement (sharing the name of the language should give an importance of how central this feature is), which causes the function to be executed as a goroutine (that is, asynchronously using an M:N threading model.)
Node-fibers allows a similar thing with a pretty raw syntax. At least one clever programmer has painted over it and introduced await/defer in Node without any JS pre-processing [1].
If you enjoy CoffeeScript, Iced CoffeeScript does a great job of this too.
I still don't understand why google does not give option to download via torrent ? Downloading android studio from dl.google.com last week over a slow connection was a horrible experience. I had to retry three times before I managed to get a successful download.
While I won't dispute that Go has some cute primitives, I thought the examples were terrible. On slide 25, it talks about why a simple operation is painful (http://talks.golang.org/2013/oscon-dl.slide#25), and then goes on to evangelize io.Copy() on slide 31. Okay, so the standard library saves me from open-coding it:
func Copy(dst Writer, src Reader) (written int64, err error) {
// If the reader has a WriteTo method, use it to do the copy.
// Avoids an allocation and a copy.
if wt, ok := src.(WriterTo); ok {
return wt.WriteTo(dst)
}
// Similarly, if the writer has a ReadFrom method, use it to do the copy.
if rt, ok := dst.(ReaderFrom); ok {
return rt.ReadFrom(src)
}
buf := make([]byte, 32*1024)
for {
nr, er := src.Read(buf)
if nr > 0 {
nw, ew := dst.Write(buf[0:nr])
if nw > 0 {
written += int64(nw)
}
if ew != nil {
err = ew
break
}
if nr != nw {
err = ErrShortWrite
break
}
}
if er == EOF {
break
}
if er != nil {
err = er
break
}
}
return written, err
}
Uh, big deal?
The chunk of what's important isn't explained at all:
- runtime/ takes care of memory management quite efficiently with a decent tracing gc in runtime/mgc0.c. I haven't benchmarked it against other stop-the-world collectors, but it should be no match for truly concurrent gc.
- runtime/proc.c schedules various blocking and non-blocking (called netpoll, which resolves to epoll on systems where it is available) calls. It seems to account for number of cores and use native threads, but I'm not sure how it interacts with the Linux scheduler.
- runtime/malloc.goc is the core memory allocator/deallocator. Seems to be a relatively straighforward arena allocator using a bitmap.
I didn't have time to go through groupcache, but the presentation certainly didn't tell me much about it.
126 comments
[ 3.3 ms ] story [ 180 ms ] threadAnybody has an alternative to read these slides? The content itself seems quite interesting
We actually need more of this on HN, not less.
http://code.google.com/p/google-api-go-client/source/checkou...
But these slides were genuinely interesting to pretty much the whole HN audience: it covers architecture decisions, the effect of code rot, the breadth of the Go standard library, a new object caching system, and a real-world example of Go usage.
tl;dr even to someone who is a bit critical towards Go (ie. me), it was a very interesting read.
This won't work so beautifully when whoever implemented all the magic bits under your business logic didn't do so to deliver reasonable performance for your use case.
Or if the underlying code is in fact wrong. This turns into the kind of code you can see from Line 242:
https://code.google.com/p/google-api-go-client/source/browse...
We optimise the standard library for the majority cases, and putting the download server into production helped us improve Go's HTTP stack for everyone. Similarly, when other users report issues with our standard library, we fix them.
The file you linked to contains some code to accommodate a bug that existed in Go 1.0 and was fixed in 1.1. Not sure what the relevance is here though.
So it leaves a bad taste when the presentation mocks the original C++ implementation while the Go solution only works because there is a fully functional high performance HTTP server already in the standard library.
There is not a single slide that tells us it may not be a good idea to rely on the standard library for such high-level functionality. Thats why I linked to the bug. A normal user has very little options when it turns out theres a bug in the standard library, other than to report it and wait for you to fix it. The problem is exacerbated since standard library and language versions are tightly coupled.
Go team is very welcome patches from the external contributors: http://golang.org/doc/contribute.html
No need to wait, you can fix it and have your patch accepted (after a code review).
After that, there's not such a difference between an HTTP server in the standard vs a third-party library
As for the license, it does matter since with the GPL you'd be stuck and it turns out that there's some debate with the LGPL as well (IANAL).
Anyway how would the GPL make a difference to your forking of the std lib? Either you link to the standard lib and all your code (that is linked into that binary and distributed as such) falls under the GPL, or you don't -- whether you distribute a patch (set) doesn't seem to change anything?
edit: And, if you don't give someone your patch, you don't have to give someone your patch?
Are you saying everyone should write their own HTTP server from scratch?
> cp -R $GOROOT/src/pkg/net/http ./net/http
Then simply change all "net/http" imports to "./net/http". Now you're free to carry out any changes you'd like.
P.S: Just because you can do this doesn't mean you should.
Also, it's a sign of a defective language that the library guards against old environments? Really?
I guess that some details on the slides would answer those questions, but if anybody here know the answer (some slides were pretty obscure if you're not already familiar with file serving and/or google architecture).
I think the biggest reason would be that almost any off-the-shelf server software would struggle in a Google server environment. They have solved scale at the machine level, and he alludes to this on one slide:
... why aren't you using the cluster file systems like everybody else?
... cluster file systems own disk time on your machine, not you.
> Does an off-the-shelf httpd support ACLs?
Not really. You inevitably end up writing custom code to conform to your particular requirements and/or existing systems. If you want high-performance, you end up writing it in C as a module for Apache/nginx/whatever.
> How easy would it be to make them support google storage instead of a file system?
Unless said storage system is presented to userspace through ordinary file interfaces, same as above. There's no general turn-key solution built into webservers. The problem space is too wide.
Using Go in this way gets you good performance, simple architecture, maintainability, and easy deployment with total flexibility to do whatever you need in order to solve your version of the problem. There are no straightjackets, you don't have to conform to (or find ways around) anyone else's conception of the problem space.
Surely, one would probably need a separate external tool that would pre-fill (nginx wouldn't know that some file's pending before it's requested) and clean up caches (provided that rules are complex than trivial LRU removal on some threshold), as one probably wouldn't like webserver doing this unsuitable job, but that should be another story.
Then again, I'm not sure why the caching wasn't better handled in the CDN that lives in front of it (cache hierarchies work well) leaving this server to simply serve only the very first request.
[1]: https://groups.google.com/forum/#!searchin/golang-nuts/dl.go...
[2]: https://github.com/golang/groupcache
Edit: Scanned the source, looks a like a best-effort distributed lock, rather than any sort of consensus protocol. This works for a cache setting, where e.g. having a split-brain scenario and duplicating the work is no big deal.
So he put the whole mess in a bin and re-done it cleanly with Go. Now it's much nicer. Some of Go's attributes helped along the way.
Did I miss something?
Though as the Node people occasionally point out, it is advantageous to have this sort of thing baked into the language, so that everything done in the language supports the concepts, rather than having a relatively small corner support it. Plus you get Go, instead of Java, which I for one would find an improvement.
The Java language specification does not require the use of OS threads for Java threads.
It all depends which JVM you refer to.
The JVMs that make use of green threads follow a similar threading model to Go.
Don't mix languages with implementations.
http://msdn.microsoft.com/en-us/library/vstudio/hh191443.asp...
TPL(Task parallel library) does use additional threads, and that's a different programming model.
The async/await model in C# is essentially from F#'s async workflows:
http://msdn.microsoft.com/en-us/library/dd233250.aspx
http://googleresearch.blogspot.com/2006/03/hiring-lake-wobeg...
What do the presentation (or our discussion) gain from the fact that Brad is a super smart guy "much more capable than the 'typical' programmer"? Why are we even bringing up that point? :)
As with all anecdotal language advocacy, you have to take it with a grain of salt, and in this case maybe more than usual.
Within Google today, if you're directly using local disk instead of the Google storage stack, you're going to have a bad time. Even more so if you're calling read() from a single-threaded event loop.
So, for me, that is somebody who didn't follow the state of Go libraries, it was much bigger new information in the presentation the author's certitude that some library covers everything of the standard (good to know how much care was invested there!) than the fact that when somebody has already made some very good tools he can more easily use them then probably anybody else who'd start without such a deep knowledge.
My own takeaway was "now that I know that at least some libraries are very well thought-out that's a good argument to consider when deciding about the use of Go in some future project." Still it's to weight against the learning curve and the quality and ease of use of the available libraries in other more common languages. In that light it's still good to know that the author of the presentation is really very competent.
Not directly related to your question, I also applaud the author's honesty in describing the problem he solved: first, the underlying assumptions changed: I can imagine that the main reason for fetching the data to the local disk in 2007 was that then fetching the data directly from the remote storage was much slower than it is now, making his current approach impossible then. Second, it's not that the original design was as inefficient as the later suboptimal modifications made it. Third, it was a project in which for a while nobody wanted to invest the time to. That's the convenient point to jump in and demonstrate what you can do with the new tools and your knowledge and time. Once you change the equation, a product once almost without the future can become a basis for future much more successful projects.
So it's a word of confidence that, yes not only is the interface nice, but the implementation is also good (enough) -- and you probably won't regret leaning on it in a future project.
They know how to keep things simple
Fair enough, but it was a bit of a foregone conclusion that he wouldn't want to develop/reuse a C++ HTTP stack as he went into the project with the intention of using Go...
- Gofmt; code formatting
- Smaller number of language keywords compared to C++
- Garbage collection
- Built in concurrency
- Simpler error handling (no C++ style exceptions)
Could have been very similar if they'd rewritten it using C++11 features (the main difference being that you'd have to use a HTTP library instead of HTTP being in the standard library, but that doesn't make much difference)...
That said, I'll happily read this story over and over again, because it tends to provide insight in what works and what doesn't.
Some of the logic is ported from C++ to Go almost line-for-line.
Some of the architectural parts are completely redone.
But it has the same binary name and flags and RPC interface
http://godoc.org/code.google.com/p/go.talks/pkg/present
My main gripe and reason for not jumping on the Go bandwagon is the error handling strategy, it was exactly what I wanted to see in the Go version.
But thanks for the info anyhow.
The Go code may look good in 2012 and 2013, while it's still fresh. But I'd be very curious to see how it looks in 2017 or 2018, assuming it's still even being used then.
The have had a bunch of crap code nobody cared about, and then some guy has rewritten it arbitrarily choosing development tools just because of his own preference.
What next, another guy will show up who likes JavaScript and considers the previous work unsatisfactory, and will rewrite everything in JavaScript?
Who works like that?
Go is pleasant, but there are Go problems an Python problems (and C problems, Lisp problems, and so on)
readable.pipe(writable);
Additionally the link to `http-proxy` on slide 30 is misleading; 60% of that file is comments, and about 50% of what's left is websocket support, with the rest being header parsing & redirect parsing. The actual proxying bit is very simple and straightforward, and if you don't need every feature `http-proxy` offers you can do it yourself with streams in < 10 lines.
As I mentioned in my talk, that code looks like fine Node.js code.
But it's still event-based, and the flow isn't readable. In the actual presentation I went through the code to show how control flow jumps around. I picked a Javascript project (and the top hit I got from a search) because people know Javascript.
Websocket support doesn't matter. In Go, you can also just io.Copy(websocket, src).
I agree Stream makes Node.js code better.
http://stackoverflow.com/questions/7479276/what-is-the-main-...
It's good for C#, but still a language wart that could be built-in. I like that Go only has one set of APIs for everything, not the sync way and the async way.
It's sad that C#, which started out as a fixed-up Java, is now growing its own warts.
Of course, Go's not perfect either.
I haven't yet tried Go, but I don't see how it could match the performance of C# API with a single function. C#'s async methods offload any IO to the process IO completion port threads, thus freeing the current thread to do more work.
Go generally uses synchronous functions, but a function in Go can be the subject of a "go" statement (sharing the name of the language should give an importance of how central this feature is), which causes the function to be executed as a goroutine (that is, asynchronously using an M:N threading model.)
If you enjoy CoffeeScript, Iced CoffeeScript does a great job of this too.
[1] http://alexeypetrushin.github.io/synchronize/docs/index.html
The chunk of what's important isn't explained at all:
- runtime/ takes care of memory management quite efficiently with a decent tracing gc in runtime/mgc0.c. I haven't benchmarked it against other stop-the-world collectors, but it should be no match for truly concurrent gc.
- runtime/proc.c schedules various blocking and non-blocking (called netpoll, which resolves to epoll on systems where it is available) calls. It seems to account for number of cores and use native threads, but I'm not sure how it interacts with the Linux scheduler.
- runtime/malloc.goc is the core memory allocator/deallocator. Seems to be a relatively straighforward arena allocator using a bitmap.
I didn't have time to go through groupcache, but the presentation certainly didn't tell me much about it.