Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Looks to me as facebook's answer to golang ?

Building simple, standalone http services with good performances seems to me what those two projects (proxygen and golang) are really about.

Now the question is, how much faster using C++ is, and how much safer and faster writing golang is...



I think Facebook is a lot into D, sounds a more appropriate, for lack of a better word, "replacement" for golang.


There are some D advocates, users, and enthusiasts (I fall into the last category) at Facebook, and a slowly increasing amount of D code, but the vast majority of infrastructure projects are done in C++, and most people are still choosing it for new projects.


I thought so as well, but then why release a c++ lib that's supposedly core to your infra ?


Go is a nice language, but so is C++14, specially if you like the expressiveness it provides.

Plus, there are still lots of scenarios where Go tooling still doesn't provide support for. They will eventually, but not if you are starting a project today.


I'm guessing that at facebook scale a GC would be expensive.


Compared to google scale which can handle it just fine ? :)))


nope, golang can't handle google either, it would be to expensive for them too.



Google's a huge company and its products have a wide variety of requirements. For context, dl.google.com is basically a download server: its goal is to get static files from Google's servers to your client as quickly as possible, with some minimal business logic. Something like this is basically ideal for Go, because it is relatively stateless and focuses on shuffling bytes from one IO interface to another. Another ideal use-case was the project that Matt Welch blogged about moving to Go.

When most laypeople think about "Google", they probably mean the search engine. I cannot imagine the serving system of Google - the part that actually retrieves the results and ranks them - ever being written in anything but C++. The scale of data that it operates on is just too large, the complexity of the code too high, and the CPU budget per request too small.

Now, there are other binaries in the search serving stack that I think should ideally be written in Go. I said as much when I was at Google, though I doubt it'd ever happen simply because of inertia. But that's probably not what people are thinking of when they say "Google-scale".

Source: I worked in search for 5+ years.


By "the part that actually retrieves the results and ranks them" you mean the nodes of a cluster, that run the RPCs?

I guess the "hotspot" would be the code that has to merge the top results from the different nodes and actually deliver top rated 10 items to the user?


That some google services were rewritten in golang doesn't really say much, in a video Rob Pike himself said that lots of services in google can't and shouldn't be rewritten in Go because of the GC, the video: http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Pan... - At 31:20 Andrei starts talking about the problem of the GC with the scale of Facebook, you can start watching there.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: