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

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

#161

Post by tptacek » Fri, Aug 31, 2012, 5:42 PM UTC

batista wrote: post #158

tptacek wrote: post #153

Earlier quoted context omitted.

If you read this whole subthread, what you basically get is a confirmation of what Rob Pike wrote in his post: a series of objections revolving around things Go doesn't have that C++ does have. Pike's point is that these objections were in hindsight inevitable, because the whole idea behind Go is to simplify the language --- Go is even simpler than ANSI C. The Go team's idea was, look at languages like C++ and replac…

> I personally see no place at all for C++ Application programming in the scale of Photoshop, Word, etc. Video games. All kinds of multimedia apps and video/music editing apps. C is too low level for those kinds of things, and Go too high level. Plus it's not just the language, that's a mistake: it's the whole ecosystem that matters. E.g you're gonna find more experienced C++ programmers to make you the next, say, Ca…

It's true: C++ is probably going to own AAA games for a long time, and, for desktop applications, you're going to tend to use the "golden path" dev environment for each platform (ie, ObjC for Mac apps, C++/Managed C++ for $50 Windows desktop apps. Right now, I'm not sure I know of a desktop app environment where Go fits on the golden path.

And, I'll restate: from the 1000-or-so lines of Go I've written so far, I'm pretty clear that I wouldn't want to use it for frontend web stuff (anything with serverside templates). But I'd probably use it before I would use Node.js for a backend web service, or maybe even for a single-page app.

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

#162

Post by mogrim » Fri, Aug 31, 2012, 5:49 PM UTC

luriel wrote: post #151

pcwalton wrote: post #143

Earlier quoted context omitted.

"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 right way to avoid GC pauses in a GC'd language is to avoid generating garbage; e.g. with free lists. And Go makes it much easier to avoid generating garbage than pretty much every other GC language around, already "by default" Go code tends to generate dramatically less garbage than for example Java, and when you care, you can further fine tune it to produce even less garbage.

Genuine question, from ignorance: How does Go create less garbage than Java? I can certainly appreciate that a lot of the common frameworks used in JEE development may be memory-hogs, but the language itself?

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

#163

Post by chc » Fri, Aug 31, 2012, 5:53 PM UTC

microtonal wrote: post #74

Evbn wrote: post #56

Earlier quoted context omitted.

It's not as sophisticated, but Go structs are smaller than similar Java objects, so that helps beat the tradeoff

I like Go, but this is total nonsense. It does help that you can embed values in a struct, rather than using pointers. But marking everything that looks like a pointer is not efficient. Not having generations does not help. Go is still very young, a better GC will come, just give it time. In the meanwhile, let's not pretend that the current sub-par generator is as performant as that of modern JVMs.

AFAIK, Go does not "mark everything that looks like a pointer." My understanding is that in some specific situations, the Go GC is not precise enough to distinguish between a pointer and an integer that happens to have the same value as that pointer, but I don't think it's right to say it does that all the time. Do you have evidence that it does?

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

#164

Post by dkroy » Fri, Aug 31, 2012, 5:54 PM UTC

pilif wrote: post #78

dkroy wrote: post #72

Earlier quoted context omitted.

Cookies are stored on the client just like DOM Storage, so nothing is free when it comes to requests and communicating with the server. I understand that both still have their place. Though I generally prefer to use DOM Storage for most things now depending on the use case. I also complete agree about keeping server-side session data.

with "free" I meant without additional effort for the developer. When you set a cookie with a Set-Cookie header, the client will automatically send the cookie with all further requests. When you put the session-ID somewhere in DOM storage, you have to manually amend all requests with that session-ID - either by appending it as a get parameter or, when you do nothing but AJAX, as an additional request header - but wha…

Alright, thanks for the clarification on "free", I realized that is what you might have meant after posting.

That last bit about your logs is surprising, thanks for that bit of info. I may need to go do the same. Either way I use a storage wrapper so I am accommodating both types of users.

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

#165

Post by jonathansizz » Fri, Aug 31, 2012, 6:30 PM UTC

raphinou wrote: post #76

jonathansizz wrote: post #28

Earlier quoted context omitted.

I think that Mozilla's Rust is aiming squarely at C++ developers, whereas Go is more of a Java replacement. And it's interesting to see Python and Ruby being squeezed lately, from various directions; Clojure, Go, other languages. Since Python went mainstream and started being picked up for serious projects, it naturally came under the spotlight a lot more than it had previously, and I think many people have started t…

I'm very interested to know more about your use of racket in production. Could you share your experience?

Well, 'production' may be too grand a term. My programs are usually on the order of a few hundred lines or less.

I'm a geneticist whose (work) code is centered around data processing. I previously used Perl for just about everything (although I've used Python & Ruby also), but started to broaden my programming horizons recently, and after a grand tour of what was on offer I settled on Racket as my language of choice for the more complex end of the scripts I was writing. I'm finding it easier to maintain (and especially refactor) complex scripts in Racket than I did in Perl (or Python or Ruby), and the increase in performance is substantial when processing huge data-sets. One current weakness of Racket here is the relative lack of specific libraries for bioinformatics, but most of my code doesn't need any anyway and when it does I revert to Perl.

I'm also excited about investigating other areas of the language, especially Typed Racket, as static typing is something I haven't really utilized so far.

In general, the more I learn about Racket the more I admire the quality of design that has gone into it; everything seems to be extremely well thought out, not just from a theoretical perspective, but from a practical one too.

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

#166

Post by numeromancer » Fri, Aug 31, 2012, 6:35 PM UTC

jessemc wrote: post #83

brianobush wrote: post #67

Earlier quoted context omitted.

>> C, seriously? C??!? For those, like myself, that like C and do systems programming. Really never understood why people dislike or fear C so much. It is the foundation for so many systems and libraries.

The main problem people have with C syntax is that it's 'old' and 'old' things are bad because new things are better. We're an industry built on fashions. Largely the outcome of the massive success programmers can have without any formal education and so just get by knowing the "best" way to do things instead of understanding why.

There are two kinds of fools: the first kind says “it is old, and therefore it is good”; the second kind says “it is new, and therefore it is better.”

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

#167

Post by vetinari » Fri, Aug 31, 2012, 6:58 PM UTC

mogrim wrote: post #162

luriel wrote: post #151

Earlier quoted context omitted.

> The right way to avoid GC pauses in a GC'd language is to avoid generating garbage; e.g. with free lists. And Go makes it much easier to avoid generating garbage than pretty much every other GC language around, already "by default" Go code tends to generate dramatically less garbage than for example Java, and when you care, you can further fine tune it to produce even less garbage.

Genuine question, from ignorance: How does Go create less garbage than Java? I can certainly appreciate that a lot of the common frameworks used in JEE development may be memory-hogs, but the language itself?

just iterating:

  for (Object o: collection) {
  }

causes memory allocation.

If you are interested, android team at had several talks at Google I/O (not just 2012) about optimizing memory usage.

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

#168

Post by heretohelp » Fri, Aug 31, 2012, 7:01 PM UTC

kibwen wrote: post #126

heretohelp wrote: post #70

Earlier quoted context omitted.

As someone who's tried (and failed) to learn Rust in the past: I'm going to elide any commentary about the syntax for now, as I know why it is the way it is (the type system/annotations). I'm basically just going to expound on one thing for the sake of emphasis. For the love of god make Rust more accessible . I don't mean dumbing down the type system or abandoning regions (I really hope that works out). I mean the fr…

(Disclaimer: occasional Rust contributor) I agree, Rust's documentation is really awful at the moment. I mean, there's a reason for it: the syntax and semantics are evolving so fast that any tutorial written right now will be hopelessly out of date in two weeks (note that the official tutorial has been updated regularly, but you can't even tell!), and much of the current stdlib is comprised of quick hacks based on ob…

I would be happy to maintain a newbie's guide, syntax changes and all (I've read the meeting notes, I know what you're talking about) if somebody can help me learn enough Rust to know what I'm talking about.

Edit: Fuck it, I'll make a website.

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

#169

Post by vardump » Fri, Aug 31, 2012, 7:11 PM UTC

jussij wrote: post #138

qznc wrote: post #73

Earlier quoted context omitted.

C++ is better for abstraction, as Go does not have generics yet, and C++ is better for performance. Go is faster to compile. Maybe Go is better for concurrent programming, but this is hard to measure.

> Go does not have generics yet, From all accounts it will never ever get generics. > and C++ is better for performance. As Go is a GC based language I would expect it will always be slower than non GC languages like c/c++. But the big question is, is it really that much slower? And the fact that it is a GC language means it is a much simpler language than C++.

> As Go is a GC based language I would expect it will always be slower than non GC languages like c/c++.

Actually C malloc, free, C++ new, etc. are really slow functions. Garbage collected languages can typically 'allocate' memory with little more than top of heap pointer increment.

You can implement similar memory pools with C/C++, but it's hard to get right when large allocations are made, compacting is very hard, etc. It does work for limited applications, for example ones that have a lot of short-lived small objects.

Multi-threaded garbage collected languages also don't need locking for freeing objects. With manual memory management you might need to lock the parent object before freeing the child to prevent some other thread from loading a pointer to the free'd child object. Locks are slow, even atomic primitives require slow inter-CPU communication. Garbage collection can avoid that completely. Performance win for gc can be hundreds of percents with 16+ CPUs.

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

#170

Post by heretohelp » Fri, Aug 31, 2012, 8:17 PM UTC

jussij wrote: post #138

qznc wrote: post #73

Earlier quoted context omitted.

C++ is better for abstraction, as Go does not have generics yet, and C++ is better for performance. Go is faster to compile. Maybe Go is better for concurrent programming, but this is hard to measure.

> Go does not have generics yet, From all accounts it will never ever get generics. > and C++ is better for performance. As Go is a GC based language I would expect it will always be slower than non GC languages like c/c++. But the big question is, is it really that much slower? And the fact that it is a GC language means it is a much simpler language than C++.

>But the big question is, is it really that much slower?

So, there's a pretty good shibboleth/knowledge smell you can use to detect whether somebody's done systems programming and knows what they're talking about or not.

Whether they think relying completely on the heap is a "small" cost or not.

Try writing some code in a real-time constrained environment where non-determinism is unacceptable. See how far malloc and Boehm gets you.