Rewriting a large production system in Go • Hacker News Board

Re: Rewriting a large production system in Go

#191

Post by zaphar » Wed, Aug 21, 2013, 2:55 AM UTC

DanWaterworth wrote: post #76

zaphar wrote: post #49

Earlier quoted context omitted.

(full disclosure: I work at google and also like erlang) Erlang has fantastic facilities for robustness and concurrency. What it does not have is type safety and it's terrible at handling text in a performant fashion. So if you don't care about either of those things and only care about robustness and concurrency then Erlang is great. There were internal discussions about Erlang here but the upshot was. We had alread…

Go gives you Erlangs concurency model There are a number of significant differences between Erlang's and Go's concurrency models: Asynchronous vs synchronous communication, per-thread vs per-process heaps, send to process vs send to channel.

Go has asynchronous communication and synchronous communication.

And the other things you mention are in practice not significant differences. The model both use is based on Hoares CSP and the same general ways of using apply. Some of the specifics must accomodate differences but those are differences of implementation not the general model.

Re: Rewriting a large production system in Go

#192

Post by zaphar » Wed, Aug 21, 2013, 3:00 AM UTC

derefr wrote: post #66

zaphar wrote: post #53

Earlier quoted context omitted.

You're assuming IO-bound highly-concurrent C++ server don't have other requirements besides those two. Maybe it's IO-bound highly concurrent text processing. Erlang will suck at this despite the two pieces it's excellent at. Go is pretty fast at processing text and google does a lot of text processing.

What exactly does "text processing" mean, by the way? Erlang is very good at processing streams of bytes --you can pattern match on binaries to get new sub-binaries (which are basically equivalent to Go's array slices) to pass around, etc. It just gets awkward when you have to convert those streams into codepoints to do case-insensitive comparisons and such. But to reply more directly, "IO-bound" means something spec…

You answered your own question when you acknowledged the areas Erlang get awkward in. Google supports more than 50 different languages. Doing that requires performant analysis of more than just bytes but of unicode codepoints.

Re: Rewriting a large production system in Go

#193

Post by gatestone » Wed, Aug 21, 2013, 4:48 AM UTC

zzzeek wrote: post #157

gatestone wrote: post #142

Earlier quoted context omitted.

Exceptions are just glorified gotos. The longest single time in my life chasing a bug was because an exception was firing somehere down udner and nobody noticed, because it was kind of part of the logic but a fringe case.

this is a thoroughly debunked argument that Joel tried to make. Unlike goto, exceptions have stack traces, so when used correctly, their source and propagation are immediately obvious and traceable. An unreported exception in your buggy program is certainly no worse than an ignored error code.

The exception was catches somewhere It formed an unexpected, rare execution path that nobody could think of. It was not detectable by reading the local code. A missing error return would have been.

Re: Rewriting a large production system in Go

#194

Post by DanWaterworth » Wed, Aug 21, 2013, 6:50 AM UTC

zaphar wrote: post #191

DanWaterworth wrote: post #76

Earlier quoted context omitted.

Go gives you Erlangs concurency model There are a number of significant differences between Erlang's and Go's concurrency models: Asynchronous vs synchronous communication, per-thread vs per-process heaps, send to process vs send to channel.

Go has asynchronous communication and synchronous communication. And the other things you mention are in practice not significant differences. The model both use is based on Hoares CSP and the same general ways of using apply. Some of the specifics must accomodate differences but those are differences of implementation not the general model.

No, they are different models [1]. Go does not have asynchronous communication. Bounded channels are still synchronous, because there is still synchronization happening; the consumer can't get too far behind the producer.

[l] https://en.wikipedia.org/wiki/Communicating_sequential_proce....

Re: Rewriting a large production system in Go

#195

Post by zzzeek » Wed, Aug 21, 2013, 8:13 PM UTC

gatestone wrote: post #193

zzzeek wrote: post #157

Earlier quoted context omitted.

this is a thoroughly debunked argument that Joel tried to make. Unlike goto, exceptions have stack traces, so when used correctly, their source and propagation are immediately obvious and traceable. An unreported exception in your buggy program is certainly no worse than an ignored error code.

The exception was catches somewhere It formed an unexpected, rare execution path that nobody could think of. It was not detectable by reading the local code. A missing error return would have been.

inappropriately catching and ignoring an exception is the same as ignoring an error return code, deeper down the call stack and not in the code you're looking at. the difference is, catching and ignoring the exception requires that it be actively done, whereas ignoring an error code is the default if no action is taken.

Re: Rewriting a large production system in Go

#196

Post by gatestone » Sat, Aug 31, 2013, 4:42 PM UTC

zzzeek wrote: post #195

gatestone wrote: post #193

Earlier quoted context omitted.

The exception was catches somewhere It formed an unexpected, rare execution path that nobody could think of. It was not detectable by reading the local code. A missing error return would have been.

inappropriately catching and ignoring an exception is the same as ignoring an error return code, deeper down the call stack and not in the code you're looking at. the difference is, catching and ignoring the exception requires that it be actively done, whereas ignoring an error code is the default if no action is taken.

You have a point. I'll think about it ;-)