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

Go is amazing, period.

poincare101.blogspot.com

Post reply on HN
Print view View original

111–120 of 241 posts

Re: Go is amazing, period.

#111

Post by enneff »

ootachi wrote: post #110
enneff wrote: post #103

Earlier quoted context omitted.

It doesn't matter what "most people use". Both compilers are equally accessible with the new go command ( http://weekly.golang.org/cmd/go/ ). People who find their programs faster with gccgo will use gccgo, and vice versa. Not competitive with "modern C and C++ compilers"? There are few real world programs that are improved by code generation micro-optimizations, and even for those that are Go is still competitive. h…

"There are few real world programs that are improved by code generation micro-optimizations" I don't know how to convince you of the fact that this statement just isn't true. Consider the rasterization software you're using right now in your web browser. Micro-optimizations hugely matter for blitting and tessellation. Consider video decoding (or encoding!). Using SSE instructions instead of going word-by-word or byte…

Your examples are good, but they are still minority examples.

> Systems programmers need a compiler that knows about these micro-optimizations.

And they have gccgo! Yay! :-)

Re: Go is amazing, period.

#112

Post by enneff »

stock_toaster wrote: post #106
enneff wrote: post #72

Earlier quoted context omitted.

It's really nice. You can build your Go program, deploy it as a single binary and it just runs. No need to hide it behind nginx or some other dedicated web server. The Go http package is DoS hardened and very fast. It's refreshing how little mechanism there is.

How are the database libraries (postgres/mysql) these days? Last time I poked around (been a while) it seemed like most of them were pretty beta yet.

There's the new database/sql library (http://weekly.golang.org/database/sql), which is a general SQL interface backed by various driver implementations (http://code.google.com/p/go-wiki/wiki/SQLDrivers).

Re: Go is amazing, period.

#113

Post by karterk »

amattn wrote: post #85
FreakLegion wrote: post #81

Earlier quoted context omitted.

void func() { } vs. void func() { } Does Go really enforce the latter? That would be incredibly silly.

Nothing in go is silly. There are multiple reasons why it's required. The answer usually given is faster compile times and the removal of semicolons from the language. I don't know the details, but someone new complains about it on the mailing list fairly frequently. Also having a tool enforced brace style is just plain practical. Less silly arguments/bikeshedding. I was also a brace on its own line kinda guy, but be…

What about using two characters for assignment?

a := 1 vs a = 1

Re: Go is amazing, period.

#114

Post by canop_fr »

enneff wrote: post #70
tedunangst wrote: post #65

Earlier quoted context omitted.

Thanks. If I was somehow supposed to know about the weekly site, I failed.

Nope, there's no way you could have known. We've been working on Go 1 for about six months now, but have resisted pushing people toward the weekly (unstable) snapshots until the most recent one, as the documentation story was incomplete and we didn't want to leave newbies out in the cold. We're nearly ready on all fronts now, and hope to pull the pin on Go 1 before the end of the month.

As a coder who use mainly weekly (and now use godoc locally each time I need the package documentation), I still find it strange not to have links between release, weekly and tip on top of the documentation pages. Coders have to keep in mind the three links. I see a lot of questions on sites like stackoverflow that would probably not have been asked if the different documentations (and their existence) had been more visible.

And I suppose this small problem won't stop with Go1 as I hope we'll see new progress in weekly as we're used to.

Re: Go is amazing, period.

#115

Post by tpsreport »

jvm wrote: post #73
tpsreport wrote: post #50

Earlier quoted context omitted.

I simply summarized your article. There is nothing wrong with not being up to handling C++'s error messages. I don't feel up to that task myself most of the time. But your arguments for Go rang hollow. I'd urge you to go through the "pro-Go" arguments point by point and describe why, say, they apply to Go but not to Python 3.0. And I'm not a Python zealot by any means; I mention it as a comparison point mostly becaus…

"why, say, they apply to Go but not to Python 3.0" That's sort of a terrible example since python is ill-suited to many (might I dare say a clear majority of?) production environments. The field of general-purpose production languages is actually pretty narrow. I somewhat agree with your point that the reasons were on the superficial side. Nevertheless, people are dissatisfied with the C/C++/JAVA trio and efforts to…

If you're unhappy with Python as a baseline comparison, pick anything else you're happy with that other people understand and compare to that.

It's not like we're setting an impossibly high bar here. Just put forward a reasonable argument for why Go is cool. "Closures like salt shakers" will not win anyone over.

Re: Go is amazing, period.

#116

Post by canop_fr »

alok-g wrote: post #102
FreakLegion wrote: post #81

Earlier quoted context omitted.

void func() { } vs. void func() { } Does Go really enforce the latter? That would be incredibly silly.

I see the line of reasoning behind this as explained by various comments here. But why can't this just be an user/editor preference while the file saved may use whatever convention?

You don't read only your code, but also code from other people. Go make it really easy, in my opinion, to fast decipher foreign code, due to shortness, clarity, and conventions. Convention help you recognize in that case the structure of the function without having to make your mind around the habit of the other coder.

Re: Go is amazing, period.

#117

Post by ootachi »

enneff wrote: post #109
ootachi wrote: post #95

Earlier quoted context omitted.

Why is it so different? I'd be curious to know. In my experience, a stop-the-world collector that must be threadsafe ends up being a disaster. You hit a brick wall in terms of real-time performance quickly (look at iOS versus Android for an easy example, and Dalvik's GC is much more sophisticated than that of Go these days). I predict that Go is going to have to put a lot of effort into making the GC fast in order to…

Java requires a powerful, sophisticated garbage collector because it is extremely difficult (and in many cases impossible) to write Java programs that don't generate a lot of garbage. Even many of the core APIs are allocation heavy. It's a pain. Go data structures tend to be much smaller than the Java equivalents, and it is much easier to track down and eliminate unnecessary allocations in Go code. When you have bett…

Go gives you slightly better control over allocation than Java (in that you have a choice to allocate on the stack and inside other data structures -- but keep in mind that escape analysis can give you this too, see the optimizations in the Jikes RVM). However, in Go, you still have no choice but to allocate on the heap in many instances (for example, when returning a data structure from a function, or when using maps, etc.) You're taking a big bet that programs will be able to use the stack and manually use free lists or whatever (which you can still do in Java!), and that the slow performance of the GC won't be a problem. I wouldn't take that bet.

Besides, once you have a stop-the-world multithreaded GC, it has to trace all the roots in the program for correctness. There's no way around that. At that point having all the data on the stack doesn't help you (except for cache locality, but Java's GC already does that via the nursery and copying during major collections). You must still trace every pointer in the object graph, while keeping all threads suspended. You can run the GC less often, but that's not much of a help when interactive performance is at stake. iOS feels so great because the UI is always running at 60 frames per second. Stop-the-world GC can't do that.

Re: Go is amazing, period.

#119

Post by alok-g »

canop_fr wrote: post #116
alok-g wrote: post #102

Earlier quoted context omitted.

I see the line of reasoning behind this as explained by various comments here. But why can't this just be an user/editor preference while the file saved may use whatever convention?

You don't read only your code, but also code from other people. Go make it really easy, in my opinion, to fast decipher foreign code, due to shortness, clarity, and conventions. Convention help you recognize in that case the structure of the function without having to make your mind around the habit of the other coder.

I do not care who wrote the code -- It should be shown to me using my formatting preferences, just as I can use my own visual theme in the editor. Those themes do not affect the code as it is saved into the file, and those formatting preferences should not either.

Re: Go is amazing, period.

#120

Post by enneff »

canop_fr wrote: post #114
enneff wrote: post #70

Earlier quoted context omitted.

Nope, there's no way you could have known. We've been working on Go 1 for about six months now, but have resisted pushing people toward the weekly (unstable) snapshots until the most recent one, as the documentation story was incomplete and we didn't want to leave newbies out in the cold. We're nearly ready on all fronts now, and hope to pull the pin on Go 1 before the end of the month.

As a coder who use mainly weekly (and now use godoc locally each time I need the package documentation), I still find it strange not to have links between release, weekly and tip on top of the documentation pages. Coders have to keep in mind the three links. I see a lot of questions on sites like stackoverflow that would probably not have been asked if the different documentations (and their existence) had been more…

You won't see progress with weekly as you're use to that's the point of Go 1. We are hoping to spend some time actually using Go, rather than building it.
Post reply on HN