Live data from Hacker News

Why I Program in Go

tech.t9i.in

81–90 of 171 posts

Re: Why I Program in Go

#81
post #74

Earlier quoted context omitted.

OK, can you be specific how this is done? What is the technical reason here?

For instance, in Go everything is passed by value. If you want to pass a reference, you must pass a reference type (like a pointer). This means that you can pass around structs without having to put them on the heap. In JVM-land, nearly everything is passed by reference, and the data must go on the heap. Relatedly, in Go if you allocate an array of n values of type T, the size of that array in memory is n * sizeof(T)…

The JVM does not support this, but the CLR does.

Re: Why I Program in Go

#82
post #79

Go nails code readability and documentation better than any other language I'm aware of. For example, look at the package documentation for Go's list data structure at http://golang.org/pkg/container/list/ . 5 seconds of reading this you immediately get what the package does and how to use it. Now let's say you want to know how the list is implemented. No problemo. Click the package files link list.go, http://golang.…

> Go nails code [cut] documentation better than any other language I'm aware of. That's because you haven't seen PHP's documentation. Look at your Go's list example. It doesn't even show how to create a list and fill it with items. It doesn't have users' comments. It doesn't explain much about the data structure. Can it be a circular doubly link list, for instance? Is there a method to empty the list, or quickly inse…

That's a bit harsh. Library docs are for users of the language. I grant that the list package could use more docs (I personally find it a bad example) but for someone who knows Go, all the important stuff is there.

Juba surprised that you rate the PHP docs so highly, particularly the user comments. Typically those comments contain terrible advice!

Re: Why I Program in Go

#83

Those are many of the same reasons I program in Go. To add another: * Go's build tools and the language's overall approach to building projects are fantastic. For the vast majority of projects you don't need an external build manager like make. One of my least favorite bits of programming in C and C++, even when I was doing that on a daily basis years ago, was the huge morass of make/autoconf hell that would grow up…

With Go open source projects (on git, svn, mercurial) much of the time you can just

And have absolutely no version management or any way to indicate API changes (except for making a new repository for every API-breaking change).

Re: Why I Program in Go

#84

Go nails code readability and documentation better than any other language I'm aware of. For example, look at the package documentation for Go's list data structure at http://golang.org/pkg/container/list/ . 5 seconds of reading this you immediately get what the package does and how to use it. Now let's say you want to know how the list is implemented. No problemo. Click the package files link list.go, http://golang.…

>Nice. I wonder how they implemented this. And I'll keep wondering because I can't find a link to the source code. Maybe there is a link to it, maybe not. We're talking about Oracle so without knowing better, I'll assume there is not ...

If you were using Java the way people do in the real world, from your IDE, you'd already be looking at the source code.

>What the fuh is a "sealed abstract class List[+A] extends AbstractSeq[A] with LinearSeq[A] with Product with GenericTraversableTemplate[A, List] with LinearSeqOptimized[A, List[A]]"

It's an abstract class (generic, and covariant in that generic parameter) that implements some interfaces. It's not hard.

>Reading further, I see section in the documentation called "Shadowed Implict Value Members". Wow, I have no idea what that is.

Take it one word at a time, it's pretty easy. Value - a value. Member - a member of the class. Shadowed - perhaps a scala-specific term, but it means it's in some parent class but hidden because it's also defined in this class. Implicit may be a new and scary concept, but it's pretty core to scala; if you use the language you get familiar with it pretty quickly.

Re: Why I Program in Go

#85
I am C and lisp fan and think OOP as non-sense. I used python a bit but hate its performance. Can I still get something from Go that can not be provided by C and lisp? Does go provide great flexibility by C and lisp? BTW, I think emacs is the best IDE so I do not care any tools/IDEs at all.

Re: Why I Program in Go

#86
post #12

Earlier quoted context omitted.

They sure do. Slower than Scala and requiring more code and lacking the awesome power of the JVM. Great choice, indeed.

Yeah- that is great as long as you don't care about using 30x times more memory.... The awesome bloat cough I mean power of the JVM in action. Go vs Scala: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... It will be interesting to re-visit this when Go 1.1 is out as well. Go being even younger than Scala has a lot of low hanging optimization fruit. :) P.S. If Go didn't exist I would still be using Java…

> Yeah- that is great as long as you don't care about using 30x times more memory.... > Go vs Scala: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t....

There is no such thing on that page. You see 30x times win for go only where program uses very small amount of memory. When memory consumption is big(regex-dna and binary trees), memory footprint is very similar for both scala and go(+-10%).

Re: Why I Program in Go

#87

I am C and lisp fan and think OOP as non-sense. I used python a bit but hate its performance. Can I still get something from Go that can not be provided by C and lisp? Does go provide great flexibility by C and lisp? BTW, I think emacs is the best IDE so I do not care any tools/IDEs at all.

If you're a C programmer then you will enjoy Go. Try it.

Re: Why I Program in Go

#88
post #84

Go nails code readability and documentation better than any other language I'm aware of. For example, look at the package documentation for Go's list data structure at http://golang.org/pkg/container/list/ . 5 seconds of reading this you immediately get what the package does and how to use it. Now let's say you want to know how the list is implemented. No problemo. Click the package files link list.go, http://golang.…

>Nice. I wonder how they implemented this. And I'll keep wondering because I can't find a link to the source code. Maybe there is a link to it, maybe not. We're talking about Oracle so without knowing better, I'll assume there is not ... If you were using Java the way people do in the real world, from your IDE, you'd already be looking at the source code. >What the fuh is a "sealed abstract class List[+A] extends Abs…

Right, you know exactly where everything is when it's your own messy room, but if an outsider wanders in, he can't tell the bed from the curtains.

I grant that there is sometimes a necessary tradeoff between power/abstraction and readability, but readability is still extremely important, and you can't just handwave away confusing language constructs and documentation with "it's obvious after you code in the language for a couple years". Simplicity and intuitiveness are powerful features in themselves.

Re: Why I Program in Go

#89
post #10

For the life of me I can't understand why anyone would give up the power (in terms of profiling, monitoring and ecosystem, and somewhat better performance, too) of the JVM, for a language marginally more convenient than Java, and arguably less expressive than other JVM languages. The only thing I could think of is a smaller RAM footprint, if you care about that sort of thing. Whenever Go is compared to Java, the argu…

Does Java do coroutines/green threads? No. At a deep architectural level, the segmented stack required to do green threads is what sets Go apart. And if it wasn't for this, Go could have just been another JVM language probably. I guess they felt this was important enough to justify building their own runtime.

Re: Why I Program in Go

#90
post #65
post #57

Earlier quoted context omitted.

My claim is that Go's advantages are far, far too small to outweigh not running on the JVM. (also, I think Clojure > Go -- no need for Java in the equation -- but that's not my main point)

You see the JVM as an asset. Many consider it a liability. And programmers in the New Jersey school (see Worse is Better) are unlikely to ever stomach Clojure. These differences are more in the realm of deep allegiances and HN comments will probably be limited to revealing allegiances--they have little chance to sway the reader one way or the other. Might as well say, "MIT type with love for the JVM? Choose Clojure.…

I realize I've started a pretty ridiculous language war; that was not my intent. But I still cannot understand why anyone would want to use a language that is mostly meant for non-constrained environments, does not provide some major productivity advantages over JVM languages while being slower than JVM languages. I would totally consider using use Go if it targeted the JVM.

You say some people consider the JVM a liability. Can you please explain why? As far as I can see, the JVM has two disadvantages: a high RAM footprint and a slow startup time. But on server-class hardware (and I believe that's probably the main environment for Go), it's hard to beat the JVM's performance, and nothing even comes close in providing similar monitoring. So -- and I'm asking this completely seriously -- why would anyone consider the JVM a liability in such an environment?

Post reply on HN