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

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

groups.google.com

Post reply on HN
Print view View original

151–160 of 189 posts

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

#151

Post by luriel »

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.…

> 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.

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

#152

Post by tptacek »

qznc wrote: post #73
batista wrote: post #52

Earlier quoted context omitted.

> The issue, then, is that Go's success would contradict their world view. I call BS. The parent explanation is much better: for a lot of the kinds of jobs C++ is good for, Go is not that good, whereas for a lot of things Python is good for, Go is as good and has better performance.

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.

One look at the Go standard library contradicts this. Go is perfectly adequate for abstraction.

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

#153

Post by tptacek »

batista wrote: post #52
thebigshane wrote: post #19

Earlier quoted context omitted.

Straight from Rob Pike -- http://commandcenter.blogspot.com/2012/06/less-is-exponentia... Python and Ruby programmers come to Go because they don't have to surrender much expressiveness, but gain performance and get to play with concurrency. C++ programmers don't come to Go because they have fought hard to gain exquisite control of their programming domain, and don't want to surrender any of it. To them, software isn…

> The issue, then, is that Go's success would contradict their world view. I call BS. The parent explanation is much better: for a lot of the kinds of jobs C++ is good for, Go is not that good, whereas for a lot of things Python is good for, Go is as good and has better performance.

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 replace groups of individual features with orthogonal components that can be composed to similar effect.

Pike is a little dismissive of C++, as am I, but ultimately he acknowledges the truth of the matter: if you're dead set on writing programs using template generics and inheritance hierarchies, you're going to stick with C++. And that's OK. We don't need to argue about it.

I am very new to Go, have a background in C/C++, am Ruby today, and was Python from '02-'05. My take is that there are definitely still things I would write in C, and I would still write web frontend code in Ruby. But I see a place for Go (backend network code, network clients, things like that) and I personally see no place at all for C++ (but then, the C++ people might not see any place at all for C). Go doesn't have to be all things to all people.

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

#154

Post by tptacek »

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?

That's why you front-end app servers with reverse proxies like nginx and Varnish. In practical reality, most major sites run applications out of app servers that are less well tested than Apache. This is not a real objection.

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

#155

Post by slurgfest »

batista wrote: post #52
thebigshane wrote: post #19

Earlier quoted context omitted.

Straight from Rob Pike -- http://commandcenter.blogspot.com/2012/06/less-is-exponentia... Python and Ruby programmers come to Go because they don't have to surrender much expressiveness, but gain performance and get to play with concurrency. C++ programmers don't come to Go because they have fought hard to gain exquisite control of their programming domain, and don't want to surrender any of it. To them, software isn…

> The issue, then, is that Go's success would contradict their world view. I call BS. The parent explanation is much better: for a lot of the kinds of jobs C++ is good for, Go is not that good, whereas for a lot of things Python is good for, Go is as good and has better performance.

I disagree that the sweet spot of Go is in the same place as the sweet spot of Python. Go has put significantly less emphasis on transparently readable code. Viewed from C++, Go looks like Python, but viewed from Python Go looks like a less crazy Java.

Fast compilation (merely being-interpreted) is surely a very cool feature which makes Go more appealing, but that is not the only productivity feature of Python.

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

#156

Post by slurgfest »

tjoff wrote: post #93
thebigshane wrote: post #19

Earlier quoted context omitted.

Straight from Rob Pike -- http://commandcenter.blogspot.com/2012/06/less-is-exponentia... Python and Ruby programmers come to Go because they don't have to surrender much expressiveness, but gain performance and get to play with concurrency. C++ programmers don't come to Go because they have fought hard to gain exquisite control of their programming domain, and don't want to surrender any of it. To them, software isn…

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…

> 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.

Java believed the same thing. Many did switch. The difference today is that most of the people liable to switch already switched to Java.

If I could guess, I'd guess that Go is doing a better job at picking up Java programmers than C++ ones.

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

#157

Post by pcwalton »

ori_b wrote: post #141
shin_lao wrote: post #110

Earlier quoted context omitted.

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.

Actually, from conversations with the Android team, Android system and apps code goes to great effort to use manual free lists and object recycling to avoid allocations during animations. Manual memory management is necessary to compete with the manually-memory-managed iOS frameworks. And Dalvik has an incremental, generational GC...

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

#158

Post by batista »

tptacek wrote: post #153
batista wrote: post #52

Earlier quoted context omitted.

> The issue, then, is that Go's success would contradict their world view. I call BS. The parent explanation is much better: for a lot of the kinds of jobs C++ is good for, Go is not that good, whereas for a lot of things Python is good for, Go is as good and has better performance.

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, Call of Duty or Logic Pro 9, than you're gonna find Go programmers. And far more code and libs to leverage.

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

#159

Post by drbawb »

aaronblohowiak wrote: post #2

Creator of SASS and Haml now using Go for whole production system. When asked about surprising things about Go, its creators have said that they expected to recruit people from c++ communities, instead it seems to be more ruby/python people.

If that's the case, I hope that Haml [and Sass] get properly ported to Go!

I'm aware of gohaml; but last I checked it hasn't been updated to work with Go1 and friends. Namely it's using `gomake` and the packages aren't organized for use with `go build`; those issues alone have stopped me from considering it.

I went for a version of mustache.go instead, and then bolted Lambda support onto it.

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

#160

Post by stonemetal »

swah wrote: post #124
stonemetal wrote: post #119

Earlier quoted context omitted.

If you have invested the 15+ years it takes to become a decent C++ programmer I have been programming in C++ for the past 14 years. Other than fast compile times, and a little less work to wire up interfaces, what exactly I am I supposed to be drooling over Go for? Between RAII and other modern C++ practices I don't really feel the need for a garbage collector. I already have a library that gives me Channel like func…

Are you a similar username in reddit?

Yes, fairly similar but not the same.
Post reply on HN