[deleted]
How We Went from 30 Servers to 2: Go
301–310 of 511 posts
Re: How We Went from 30 Servers to 2: Go
#302Earlier quoted context omitted.
Not Invented Here syndrome goes away with general experience. It doesn't come back every time you switch to a new language. Just because I've never written Erlang doesn't mean that I will automatically try to write a random-number generator (say) the first time I need one in Erlang. I have enough experience to look for a library function first. Empirically, NIH tends to be more common in single-language developers, n…
I wasn't talking about NIH syndrome, I was talking about "I don't know that a common library exists for this standard use-case so I'm going to write my own one-off because I have a job to do". I mean, you can google for libraries but sometimes you just don't find them and then find out a few weeks later what you should have used.
This is unlikely with go as it has a good standard library and a central place for documentation of all the packages.
Third party libraries are also listed here:
http://go-lang.cat-v.org/pure-go-libs
And the ecosystem is not so broad or mature that you would miss significant libraries because there are too many options and you just didn't find them.
Re: How We Went from 30 Servers to 2: Go
#303“the entire process started up with only a few hundred KB's of memory (on startup)” There is no way this could be true: last time I checked, a bare minimal Go HTTP server requires at least 2.8MB of memory on 64-bit machine. Are you using the default net/http library?
Yeah, my HTTP server made in Go usually starts up at around 6MB or so.
Re: How We Went from 30 Servers to 2: Go
#304Another day, another Go PR post on HN.
What is new about porting code running in one of the slowest interpreters around to a compiled implementation of another language?
I was already porting Perl/TCL code to C++ back in 2002 with similar performance results.
Don't kids nowadays learn anything about performance in their CS degrees?
Re: How We Went from 30 Servers to 2: Go
#305Earlier quoted context omitted.
Just curious, what were the tradeoffs for profiling the Python code and rewriting slow parts in C vs total rewrite in Go? For high level languages, the usual argument has been to rewrite just the slow parts in C or some other low level language.
One thing you don't get in the C/Python combo is total static typing. The other big win of Go is elimination of a lot of runtime errors. So it comes down to which will be more of a win for you and your product. Go has a big advantage here IMO though because of static typing AND performance increase.
Like any other language with static typing and available compiler implementations.
Re: How We Went from 30 Servers to 2: Go
#306Earlier quoted context omitted.
> C++ and Python pretty much run everything, everywhere. I don't think so. Last I heard, there was still a lot of COBOL out there.
COBOL gets all the hate but if they have a Big iron mainframe then they'll most likely be running RPG.
Only if it is AS/400 based systems.
Re: How We Went from 30 Servers to 2: Go
#307Ok, this bit has left me confused. They were Java devs that liked ruby, they wrote applications in Ruby on Rails and the ruby apps were hitting limits so they immediately started looking at other languages. But they don't mention the most obviously (to my mind) simple option. JRuby It is ruby (They like ruby). Most ruby apps can be run on JRuby with very very little changes (No need for a big rewrite) and it runs on…
They also did not mention why they didn't try any other of the more performant implementations of Ruby.
Re: How We Went from 30 Servers to 2: Go
#308What changed in the architecture? It is rather interesting that by just having a language change you could remove 28 servers from the system.
I chuckled at "just a language change". What could be more expensive than rewriting all you code? For many Rails web apps the cost of additional servers is far below the cost to rewrite things in Go.
Thus the improvements where not a result of using Go (which is is a fine language). The improvements came from replacing a bloated system with a leaner one. You can do that with many other languages. There is no magic in that.
Re: How We Went from 30 Servers to 2: Go
#309> "We also weren't sure if we would be able hire top talent if we chose Go, but we soon found out that we could get top talent because we chose Go." I feel[1] that a smart/talented C/C++/anything developer can go from someone who has never seen or heard of golang to a proficient and productive Go developer in a matter of a few weeks, maybe even _days_, if not less. That's how long it takes to go through the following…
It's quite strange to me that people would identify as or look for a "[language] programmer". Sure, I happen to write more C++, Python, and C than anything else, but I've dabbled in just about everything and could reach comfortable proficiency in a matter of weeks. Most of programming and all of computer science is universal. Any serious programmer should be a polyglot by default.
> Any serious programmer should be a polyglot by default.
Fully agree.
At the end of my CS degree, I was able to code in:
- Pascal
- C
- C++
- Prolog
- Smalltalk
- Camllight
- Java
- Assembly (x86 and MIPS)
- PL/SQL
Re: How We Went from 30 Servers to 2: Go
#310Earlier quoted context omitted.
Testing: http://golang.org/doc/code.html#Testing Iterating: http://vimeo.com/53221560
from a testing point of view this looks pretty week. I would not bet my business on something that has not a testing culture.
What makes you say it doesn't have a testing culture? I think you're just trying to justify not using Go and sticking to your choice.
I haven't came across any Go libraries without tests.