"100% of our production system is now running Go" • Hacker News Board

Re: "100% of our production system is now running Go"

#141

Post by ori_b » Fri, Aug 31, 2012, 2:02 PM UTC

shin_lao wrote: post #110

davidw wrote: post #90

Earlier quoted context omitted.

> And you can't use go outside of the "PC" (that is, embedded systems). Why not? It runs on Arm.

You need a deterministic memory management.

For what? Android does fine without it, if you still consider that embedded. Java is used in a wide variety of embedded systems without trouble.

Sure, there are some places that can't use Go. But there are also places that cant use dynamically allocated memory or recursion. Not all embedded systems are safety critical or need to be absolutely deterministic.

Re: "100% of our production system is now running Go"

#142

Post by exch » Fri, Aug 31, 2012, 2:04 PM UTC

tocomment wrote: post #136

eckyptang wrote: post #133

Earlier quoted context omitted.

The compiled output will contain your network server. you run the process and it listens on a socket. It is pretty straightforward. Using HTTP as an example, each request will run in a goroutine which is somewhere between a thread and a coroutine. It is extremely fast. The main risk is process failure which is very rare but can be mitigated via putting a front end balancer such as nginx or apache mod_proxy. Process r…

I was always taught never to write my own web server since something like Apache has been tested on millions of sites, and you have security experts designing it. Does writing your own server in Go kind of violate this idea? Are you opening yourself up to re-inventing a web server and repeating decades of mistakes something like Apache has already figured out and fixed?

Writing a (web)server in Go is not so much about reinventing the wheel, as it is about slapping together the existing building blocks into a server specifically tailored to your application.

These building blocks are very complete and are all available in the standard library. This means they are tested, debugged, tested again and have become pretty damn robust.

The point about Apache/NGinx being well established and battle hardened still stands, but Go's library is quickly following suit.

What Go offers over the others in this respect, is that you do not have to settle for a monolithic one-size-fits-all package. The code you write in Go does one thing (serve your application) and does it well without any compromises.

Re: "100% of our production system is now running Go"

#143

Post by pcwalton » Fri, Aug 31, 2012, 2:13 PM UTC

eckyptang wrote: post #135

tjoff wrote: post #131

Earlier quoted context omitted.

Go fits an important niche: stuff that doesn't have to play with the hardware directly, which is pretty much everything but the OS. The anything-but-the-OS-niche? I thought we had plenty of languages for that. It's better to centralise the memory management and optimisation either into a VM or compiler. It's easier and safer to verify a compiler (mathematically or otherwise) than every memory access that you do. You…

The anything-but-the-OS-niche? I thought we had plenty of languages for that. We have plenty of languages, but most of them are low performance interpreted languages, have major compromises or are not architecturally sound. Go addresses a lot of those issues - more than any other language so far. You seem to ignore performance altogether, if you programmed in C/C++ for twenty years but don't care for performance and…

"I think your complaints could be addressed with a simple extension to pause the collector therefore introducing determinism"

I don't think that scales to multiple threads. Remember, the GC is global. With a lot of goroutines, you're going to end up delaying GC far too long if any of them can block the GC.

These sorts of things are the reason why it's considered a bad idea to muck around with the GC settings in e.g. the JVM unless you really know what you're doing. The right way to avoid GC pauses in a GC'd language is to avoid generating garbage; e.g. with free lists.

Re: "100% of our production system is now running Go"

#144

Post by jussij » Fri, Aug 31, 2012, 2:15 PM UTC

bad_user wrote: post #79

I want to try out Go, but the problems exposed by the garbage collector on 32bit systems scared me away. Is that still the case with the latest version 1.0.2 ? Also, is there any chance for a precise generational garbage collector to get implemented for Go? As far as I know, pointers make the implementation of precise garbage collectors difficult.

> I want to try out Go, but the problems exposed by the garbage collector on 32bit systems scared me away.

If you run a 64 bit server then these problems just goes away.

And from all accounts these issues will also be fixed for 32 bit systems in then next Go release or two.

Re: "100% of our production system is now running Go"

#145

Post by lttlrck » Fri, Aug 31, 2012, 2:25 PM UTC

Evbn wrote: post #57

f2f wrote: post #38

Earlier quoted context omitted.

the C code is also being run under Go's control via Cgo.

My production system is written in 100% bash and some other code run under Bash's control. :-)

Mine is running under 100% control of grub

Re: "100% of our production system is now running Go"

#146

Post by afc » Fri, Aug 31, 2012, 2:33 PM UTC

Whoah, 500 servers to handle an average of ~300 queries per second? Even if you generously assume they have traffic patterns that sometimes go all the way up to sustained say 5K queries per second... 500 servers? Isn't that like ... terribly wasteful?

Re: "100% of our production system is now running Go"

#147

Post by jk4930 » Fri, Aug 31, 2012, 2:34 PM UTC

MatthewPhillips wrote: post #122

tjoff wrote: post #93

Earlier quoted context omitted.

I have such a hard time believing how anyone could have believed that C/C++ programmers would switch to a GC-only language just like that. I just can't see Go as an alternative to C or C++, and I'm quite surprised that anyone (especially someone such as Rob Pike) could. Sure there are situations where a program that typically would have been written in C/C++ could benefit from Go (so there is a place for it), but the…

You want Rust: http://www.rust-lang.org/

You should look at Ada 2005 (or Ada 2012). Ada is battle-proven and comes with plenty of reliability tools and inbuilt safety. It's also focused on embedded, distributed and real-time systems.

AdaCore provides high quality compilers and tools (GPLed) under http://libre.adacore.com/

Interested fellas might start with reading this article: http://www.adacore.com/adaanswers/gems/gem-30/

EDIT: oops, that should be an answer to eckyptang... anyway, check out Ada. :)

Re: "100% of our production system is now running Go"

#148

Post by ehutch79 » Fri, Aug 31, 2012, 2:36 PM UTC

tocomment wrote: post #136

eckyptang wrote: post #133

Earlier quoted context omitted.

The compiled output will contain your network server. you run the process and it listens on a socket. It is pretty straightforward. Using HTTP as an example, each request will run in a goroutine which is somewhere between a thread and a coroutine. It is extremely fast. The main risk is process failure which is very rare but can be mitigated via putting a front end balancer such as nginx or apache mod_proxy. Process r…

I was always taught never to write my own web server since something like Apache has been tested on millions of sites, and you have security experts designing it. Does writing your own server in Go kind of violate this idea? Are you opening yourself up to re-inventing a web server and repeating decades of mistakes something like Apache has already figured out and fixed?

It should also be noted, that you're not being encourage to serve static media with your go app. it's more like fastcgi or wsgi. you would have apache or nginx sitting in front of your app listening only on localhost serving dynamic pages only.

Re: "100% of our production system is now running Go"

#149

Post by luriel » Fri, Aug 31, 2012, 2:47 PM UTC

draven wrote: post #121

qznc wrote: post #114

Earlier quoted context omitted.

Slice still restricts you to an array data structure (a continuous block of memory). How would you implement a sorted set in Go? It should be generic and type safe and efficient, please. Compare with the C++ solution.

I think the problem with saying that Go can be used as a C++ replacement is that the statement is too vague. The problem space in which Go is a great tool and the one in which C++ is a great solution have a big overlap. But that does not mean that you will solve a given problem in this overlapping space the same way. Both languages have a different set of trade-offs. If you need a typesafe, generic sorted set with st…

> If you need a typesafe, generic sorted set with strict efficiency needs

When people ask for things like this, I can't help to think that what they want is not generic at all, they want something very specific to the problem they are solving, in those cases just writing custom data structures is the way to go in any language anyway.

It is the way it has been done in C for decades too.

Re: "100% of our production system is now running Go"

#150

Post by eckyptang » Fri, Aug 31, 2012, 2:49 PM UTC

pcwalton wrote: post #143

eckyptang wrote: post #135

Earlier quoted context omitted.

The anything-but-the-OS-niche? I thought we had plenty of languages for that. We have plenty of languages, but most of them are low performance interpreted languages, have major compromises or are not architecturally sound. Go addresses a lot of those issues - more than any other language so far. You seem to ignore performance altogether, if you programmed in C/C++ for twenty years but don't care for performance and…

"I think your complaints could be addressed with a simple extension to pause the collector therefore introducing determinism" I don't think that scales to multiple threads. Remember, the GC is global. With a lot of goroutines, you're going to end up delaying GC far too long if any of them can block the GC. These sorts of things are the reason why it's considered a bad idea to muck around with the GC settings in e.g.…

GC doesn't have to be global or blocking. If you look at the GC in CLR/.Net 4+ then it can run GC on low priority background threads.

I know Go's GC isn't there yet, but it's easier to centralize a performance improvement under this model i.e. GC improvements will lead to global improvements rather than case by case.

There's more than one way to skin a cat on this one.