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

181–190 of 241 posts

Re: Go is amazing, period.

#181

Post by scott_w »

nakkiel wrote: post #131
FreakLegion wrote: post #90

Earlier quoted context omitted.

Thanks for answering! I have no idea why someone downvoted your reply. People: downvoting is for mean and/or stupid comments, not things you disagree with. Anyway, in that case I imagine we'll see a Go preprocessor that takes all the line-initial braces and moves them up a break before sending code to the compiler. People get pretty worked up about this stuff.

I work in a place where people don't use spaces and don't use empty lines to separate logical groups of lines. It's a real pain for me who is a code format junkie as our code ends up being an ugly pack of unrelated crap that's really hard to read. It's Python code and I find it uglier than some fairly large C++ project I used to work on. Anyway, I wish there was a gofmt in Python because at least, I'd drop all hopes…

One time we worked on some code, and one of the developers had the same habit: "It works, so why do I need to format it?"

We decided to make our build system run PEP over the code, resulting in a failure if PEP didn't pass.

It annoyed the hell out of him, but we quickly got the formatting up to a better standard.

Re: Go is amazing, period.

#182

Post by 4ad »

CamperBob wrote: post #177
jbarham wrote: post #87

Earlier quoted context omitted.

It's a FAQ: http://weekly.golang.org/doc/go_faq.html#semicolons

From that page: "At the moment, all implementations use 32-bit ints, an essentially arbitrary decision. However, we expect that int will be increased to 64 bits on 64-bit architectures in a future release of Go." So, in other words, it's Amateur Hour. All righty, then. /backs toward door, reaches for doorknob, still smiling and nodding

Fantastically dumb comment. FWIW int in C is also 32 bit on all mainstream 64 bit operating systems, and Go has int64.

Re: Go is amazing, period.

#183

Post by ootachi »

dsymonds wrote: post #178
ootachi wrote: post #117

Earlier quoted context omitted.

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

We don't bet, we experiment, measure and analyse. So far, I have found memory allocation in Go to be extremely predictable and controllable, and the GC behaviour likewise predictable. I don't know why you claim that "having all the data on the stack doesn't help you". That makes no sense. If data is on the stack, any references starting there disappear as soon as that stack frame is popped, so there's no lingering wo…

"If data is on the stack, any references starting there disappear as soon as that stack frame is popped, so there's no lingering work for the GC to do"

You're only considering the sweep phase. Sweep is the easy part of tracing GC - you can always chuck sweep into a background thread. The mark phase is the problem. Marking always has to trace roots, including stack roots - that's how GC works. Tracing GC never traces dead objects.

You can reduce allocation pressure by using the stack, which will make the GC run less often, but my point is that when it does run you're no better off than Java, and quite a bit worse since Java's GC can run in parallel with the mutator and Go's can't.

"Your comments strongly imply that you have no practical experience with Go's GC. I suggest you stop claiming that it has certain performance characteristics or behaviours when you have not experienced it yourself."

I have experience with GC generally. There's nothing particularly special about Go's GC: it's a standard stop-the-world mark-and-sweep collector for a language that supports a limited form of stack allocation but generally uses heap allocation. The performance characteristics that this form of GC must have are well-known.

If you want data, look at the binary-trees benchmark: http://shootout.alioth.debian.org/u32/benchmark.php?test=all...

It's mostly a test of GC. Java's GC runs more often (thus the memory use is lower) and yet it's still 4x faster. This is because Java has a generational, concurrent-incremental collector.

Re: Go is amazing, period.

#184

Post by Aqueous »

"And, the worst problem I faced was of sockets. Non-blocking, multi-plexed and cross-platform socket support with C is basically non-existent (unless I wanted to use libev or libevent,"

What are you talking about? Most every single evented io library out there just boils down to a single system call in the underlying language - C: epoll(or select, poll, or kqueue) on socket/file descriptors. You do know that socket() returns a socket, which is actually just a file descriptor, right? You don't need libev and libevent because you can just write your own in two seconds with epoll! And if you're really attached to having the library handle the work for you you can always use one of the many cross-platform event libraries, like Glib which, last I checked, works on Win32, Mac, and Linux.

Re: Go is amazing, period.

#185

Post by [deleted] »

Aqueous wrote: post #184

"And, the worst problem I faced was of sockets. Non-blocking, multi-plexed and cross-platform socket support with C is basically non-existent (unless I wanted to use libev or libevent," What are you talking about? Most every single evented io library out there just boils down to a single system call in the underlying language - C: epoll(or select, poll, or kqueue) on socket/file descriptors. You do know that socket()…

[deleted]

Re: Go is amazing, period.

#186

Post by 4ad »

enneff wrote: post #11
firefoxman1 wrote: post #2

Is there currently a good web framework for Go? Edit: web.go looks pretty sweet: http://www.getwebgo.com/ Edit2: As does app.go: https://github.com/georgenava/appgo ...There's a large list of Go projects here: http://godashboard.appspot.com/project

> Is there currently a good web framework for Go? The standard library gives you almost everything you need. The http package provides a web server and client: http://weekly.golang.org/net/http/ The template package provides text templates: http://weekly.golang.org/text/template/ and automatically-escaped HTML templates: http://weekly.golang.org/html/template/ For other bits and pieces, see the rest of the standard l…

Yup, the standard library was all I ever needed. People from other languages are familiar with frameworks and seek them in Go, but I'd say they are seldom required. The rich standard library and the language makes everything easy.

Re: Go is amazing, period.

#187

Post by jkn »

pjmlp wrote: post #176
jkn wrote: post #152

Earlier quoted context omitted.

Threads are different from goroutines. A Go program can create 100'000 goroutines, if it makes sense for the algorithm. Try doing this with threads... Super-cheap threads open many possibilities, it's a significant change in how you think and design programs. Among your examples, those that are comparable to goroutines are all for functional languages. There's nothing wrong with functional languages, but it's far fro…

Yes there are, they are known as user space threads or fibers.

User space threads don't run in parallel, i.e. they don't take advantage of multi-core CPUs and can be blocking.

Fibers are for cooperative multitasking so no parallelism either.

Goroutines are multiplexed as needed onto system threads. http://golang.org/doc/GoCourseDay3.pdf

So they are a bit different, in the spirit of Go: they make for a simple and general solution to both parallelism and concurrency. They combine naturally with channels to give the functionality of OS threads, user threads and fibers.

Re: Go is amazing, period.

#188

Post by CamperBob »

4ad wrote: post #182
CamperBob wrote: post #177

Earlier quoted context omitted.

From that page: "At the moment, all implementations use 32-bit ints, an essentially arbitrary decision. However, we expect that int will be increased to 64 bits on 64-bit architectures in a future release of Go." So, in other words, it's Amateur Hour. All righty, then. /backs toward door, reaches for doorknob, still smiling and nodding

Fantastically dumb comment. FWIW int in C is also 32 bit on all mainstream 64 bit operating systems, and Go has int64.

Fantastically dumb comment. FWIW int in C is also 32 bit on all mainstream 64 bit operating systems, and Go has int64.

ROFL. I challenge you to find documentation for the C language or any other language commonly used in production where they speculate that they might wake up one day and change sizeof(int) on an existing platform.

"Fantastically dumb," indeed.

Re: Go is amazing, period.

#189

Post by 4ad »

CamperBob wrote: post #188
4ad wrote: post #182

Earlier quoted context omitted.

Fantastically dumb comment. FWIW int in C is also 32 bit on all mainstream 64 bit operating systems, and Go has int64.

Fantastically dumb comment. FWIW int in C is also 32 bit on all mainstream 64 bit operating systems, and Go has int64. ROFL. I challenge you to find documentation for the C language or any other language commonly used in production where they speculate that they might wake up one day and change sizeof(int) on an existing platform. "Fantastically dumb," indeed.

C is that language, among so many others, sizeof(int) is implementation specific, and indeed it does vary, though (S)?ILP64 is rare. On the other hand sizeof(long) varies all the time.

You seem very ignorant, please learn and stop the FUD.

Re: Go is amazing, period.

#190

Post by Symmetry »

4ad wrote: post #182
CamperBob wrote: post #177

Earlier quoted context omitted.

From that page: "At the moment, all implementations use 32-bit ints, an essentially arbitrary decision. However, we expect that int will be increased to 64 bits on 64-bit architectures in a future release of Go." So, in other words, it's Amateur Hour. All righty, then. /backs toward door, reaches for doorknob, still smiling and nodding

Fantastically dumb comment. FWIW int in C is also 32 bit on all mainstream 64 bit operating systems, and Go has int64.

Why on Earth would you want 64 bit ints by default, though? I'm not sure why they are thinking about changing it.
Post reply on HN