Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rewriting a large production system in Go

matt-welsh.blogspot.com

Post reply on HN
Print view View original

91–100 of 196 posts

Re: Rewriting a large production system in Go

#91

Post by f2f »

dbaupp wrote: post #58
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 doesn't have strong type safety either; I remember a recent story about a Go stdlib function "accidentally" calling an interface it shouldn't.

it wasn't accidental -- it was written on purpose by a programmer (a conversion from Writer to WriteCloser). it was immediately acknowledged as an error and eventually may be caught by the standard code examining tool "vet".

Re: Rewriting a large production system in Go

#92

Post by microtonal »

mdwelsh wrote: post #57
lbarrow wrote: post #47

Earlier quoted context omitted.

I'm glad to hear it. Was there anything about the language that you found particularly forced clarity and modularity? I'm giving a talk comparing Go and Ruby next month and I'm curious as to what people with experience with larger Go programs find to be most helpful.

The Go module system for sure. Also I really like Go's interface model (as opposed to Java or C++ classes) as it is more flexible and in some ways more precise. Note that I don't know Ruby so I can't compare Go to that...

Thanks for the article, it was a very interesting read! Since this always comes up in Go discussions: did you miss generics in this project or was the lack of generics a non-issue?

Re: Rewriting a large production system in Go

#93

Post by pjmlp »

sytelus wrote: post #86

The number of strongly typed garbage collected compiled languages is surely shrinking. I can understand someone's disgust towards Java considering dwindling velocity in adding next-gen features and now sleeping in same bed as lawyer run Oracle. That pretty much had left C# in the arena until Go came on the scene. I was honestly hoping Go would give us head-to-head battle with C# but from initial looks Go pretty much…

Yep, Go would be hardly mentioned here if it wasn't being developed at Google.

Having said this, Go can be a nice replacement for many use cases one would use C for.

Re: Rewriting a large production system in Go

#94

Post by pjmlp »

jff wrote: post #79
npalli wrote: post #43

Earlier quoted context omitted.

I have no doubt it must have been easier programming in go. My question was on resource efficiency. I doubt anyone programs in C++ for fun anymore :-). The issue with toy problems you can write a vanilla python or perl program that processes text faster than C++ (without extensive fiddling) however the memory and CPU utilization can be 5-10 times higher. This doesn't matter on a single box for toy problems, but matte…

Everybody talks about using C++ for efficiency, but the way most people end up writing C++? Not very efficient.

Because many try to write C in C++, instead of learning how to do it properly.

Re: Rewriting a large production system in Go

#95

Post by pjmlp »

marshray wrote: post #71
seiji wrote: post #55

Earlier quoted context omitted.

Well, they wrote their own infringing java VM for mobile, tried to fix Python (but it didn't work out), essentially run Google Linux internally with various levels of contribution back upstream, and their C++ is (I'm just guessing here) nigh unreadable by non-übernerds.

Wrote an "infringing Java VM" now did they? Did you actually read the court's ruling on that?

I did, and to be honest it is not much different than Microsoft with Visual J++.

Without the "Google is cool glasses" on, I came to the conclusion that Google just took enough care to avoid all the legal traps that could make them loose a suit like it happened to Microsoft.

Re: Rewriting a large production system in Go

#96

Post by pjmlp »

Dn_Ab wrote: post #73
derefr wrote: post #6

You know, every time I see some Googler shocked at the effectiveness and various advantages of coding in Go, I wonder why Google never adopted Erlang. They could have been getting all these same advantages (and then some) a decade ago :)

More than Erlang I think what Google really wanted was Ada. Since speed (ada can be very fast with low memory usage) and programming at scale were as much concerns as concurrency (they both take inspiration from CSP). Ada trades verbosity for clarity and rarely matched safety (design by contract, modules and extensive runtime checks). While I've never written a line of it before, proponents of Ada always have interes…

While touted a complex and big language when it appeared in the early 80's, it is actually smaller than C++.

The main problems related to its adoption had to do with the price of the compiler systems back in the day and its verbosity for the curly-bracket fans.

Nowadays there is GNAT, but the language ecosystem is very different.

Re: Rewriting a large production system in Go

#97

Post by pcwalton »

f2f wrote: post #91
dbaupp wrote: post #58

Earlier quoted context omitted.

Go doesn't have strong type safety either; I remember a recent story about a Go stdlib function "accidentally" calling an interface it shouldn't.

it wasn't accidental -- it was written on purpose by a programmer (a conversion from Writer to WriteCloser). it was immediately acknowledged as an error and eventually may be caught by the standard code examining tool "vet".

What would the static analysis that "vet" is performing enforce to stop this? No interface-to-interface downcasts?

Re: Rewriting a large production system in Go

#98

Post by pjmlp »

zzzeek wrote: post #2

> If I could get out of the 1970s and use an editor other than vi, maybe I would get some help from an IDE in this regard, but I staunchly refuse to edit code with any tool that requires using a mouse. So you've shown that Go is appealing to rigid curmudgeons. Personally I'm still hung up on the "every function (edit: that does anything which might itself return an error code, which in large scale code is quite a lot…

That is exactly because of those type of developers in the industry that the latest Bret Victor's talk is so interesting

http://vimeo.com/71278954

Basically he goes on to show how many people still code like the 70's instead of adopting languages and paradigms that were already possible in late 60's systems.

Re: Rewriting a large production system in Go

#99

Post by bad_user »

sytelus wrote: post #86

The number of strongly typed garbage collected compiled languages is surely shrinking. I can understand someone's disgust towards Java considering dwindling velocity in adding next-gen features and now sleeping in same bed as lawyer run Oracle. That pretty much had left C# in the arena until Go came on the scene. I was honestly hoping Go would give us head-to-head battle with C# but from initial looks Go pretty much…

The JVM is the best mainstream VM. We use it with Scala. Try it out.

Re: Rewriting a large production system in Go

#100

Post by pjmlp »

MetaCosm wrote: post #70
zzzeek wrote: post #19

Earlier quoted context omitted.

yes I've read that and their reason is "it results in convoluted code" - which is not at all my experience, programming in Java and Python for many years, it's worse in Java for sure due to the heavy emphasis on checked exceptions, but in Python they are a dream. "It also tends to encourage programmers to label too many ordinary errors, such as failing to open a file, as exceptional." also not true in my experience.…

I think a lot of people HAVE made the case convincingly, at least well enough for me. I have worked in major C++ shops that ban the use of exceptions (and enforce it). Just to add another person who regrets exceptions to the big pile, http://250bpm.com/blog:4 (The ZMQ Author) "Thus, the error handling was of utmost importance. It had to be very explicit and unforgiving. C++ exceptions just didn't fill the bill. They…

That is a problem with the way exceptions work in C++, not with the exceptions as concept.

C++ exception's design suffer from being added to the language in the last years of the language's design and having to support the possibility of being turned off if desired.

This, coupled with the manual resource management of the language is with lead to some of the issues with exceptions in C++.

Not all languages with exception's support suffer from the same problems.

Post reply on HN