Why I Program in Go • Hacker News Board

Re: Why I Program in Go

#161

Post by Evbn » Mon, Jan 07, 2013, 4:38 AM UTC

pretoriusB wrote: post #120

ericbb wrote: post #55

Earlier quoted context omitted.

You claim (as I understand): (Java + Clojure) > Go && (Java + Scala) > Go That stance seems to require a low weight on the cost of conceptual and tool-chain overhead. I haven't measured, but I'd guess that the language spec of Go is shorter than the specs of each of those other languages. Edit: Fix spelling of "Clojure".

> I haven't measured, but I'd guess that the language spec of Go is shorter than the specs of each of those other languages. Doesn't matter, since you'll find huge large holes in libraries, tooling, ecosystem and maturity in Go which can be easily filled in Java+Scala/Clojure, and which nullify any "smaller spec" advantage. For example there is not one mature and complete web framework in Go. Several for all of Java/…

Naturally, Go users do not believe that complete web frameworks or RDBMS support is a desirable feature.

Re: Why I Program in Go

#162

Post by Evbn » Mon, Jan 07, 2013, 4:41 AM UTC

pkulak wrote: post #63

zaphar wrote: post #18

Earlier quoted context omitted.

My day job involves working with Java and C++ on 10+ year old systems. All of my hobby or side projects are in Go these days with occasional diversions into haskell, ML or various Lisps. So I'll try to impart some understanding of why I would switch to Go from Java or C++. First lets get some things out of the way. Go is fast enough and getting faster very quickly and it definitely has a smaller memory footprint. So…

I have a hard time believing anything can beat or even match the garbage collection performance of the JVM. Not that there is something special about the JVM, just that there have been _so_ many smart people working on the problem for so long now. And for good performance doing server tasks (ie, not computational tasks) exceptional GC is a must. Can a GO program handle a workload that creates tens/hundreds of thousan…

Go has optional stack allocation, which means the GC doesn't need to handle short lived objects.

Re: Why I Program in Go

#163

Post by Evbn » Mon, Jan 07, 2013, 4:45 AM UTC

laureny wrote: post #138

estavaro wrote: post #54

Earlier quoted context omitted.

You need to be commended for defending Go. I don't think the Go developers hide the fact that they mean go as a Systems level programming language. It has higher level features, but the developers don't really mind the fact that Go isn't going to be delivering a whole lot of high level features. Maybe if they come in the form of libraries... Funny thing about Go is that as a compiled language, folks often need to sen…

> Go error handling is not to be taken lightly The fact that Go relies on return codes instead of exceptions to express errors is what will fundamentally limit the language's adoption, in my opinion. Anyone who was writing code in the 80's and 90's remembers how fragile and buggy software written this way is (Windows' HRESULT, anyone?). Exceptions have considerably increased the robustness and reliability of millions…

Go doesn't rely on return codes. Go has multiple return, and has error objects.

Microsoft and Google eschew exceptions, because they cause huge invisible problems in large systems.

Re: Why I Program in Go

#164

Post by Evbn » Mon, Jan 07, 2013, 4:49 AM UTC

Peaker wrote: post #117

zaphar wrote: post #18

Earlier quoted context omitted.

My day job involves working with Java and C++ on 10+ year old systems. All of my hobby or side projects are in Go these days with occasional diversions into haskell, ML or various Lisps. So I'll try to impart some understanding of why I would switch to Go from Java or C++. First lets get some things out of the way. Go is fast enough and getting faster very quickly and it definitely has a smaller memory footprint. So…

> Go makes concurrency easy to get right. I haven't seen any other language get this so right since Erlang. I don't understand this: You claim you've used Haskell? Haskell beats Go's concurrency out of the water. Not to mention conciseness...

And space leakiness...

Re: Why I Program in Go

#165

Post by stock_toaster » Mon, Jan 07, 2013, 5:42 AM UTC

Evbn wrote: post #161

pretoriusB wrote: post #120

Earlier quoted context omitted.

> I haven't measured, but I'd guess that the language spec of Go is shorter than the specs of each of those other languages. Doesn't matter, since you'll find huge large holes in libraries, tooling, ecosystem and maturity in Go which can be easily filled in Java+Scala/Clojure, and which nullify any "smaller spec" advantage. For example there is not one mature and complete web framework in Go. Several for all of Java/…

Naturally, Go users do not believe that complete web frameworks or RDBMS support is a desirable feature.

That is a bit disingenuous. There is an SQL interface driver in the stdlib here[1]. There are several[2] implementations available which build apon it.

There are several[3] (scroll down to the relevant section) web frameworks too.

I personally tend to prefer using the gorilla toolkit[4], in combination with the stdlib http and templating stuff. It should be noted that my current usages for Go include an API service, command line tools, and a proxy. Certainly not much html generation going on there by any means.

[1]: http://golang.org/pkg/database/sql/ [2]: http://code.google.com/p/go-wiki/wiki/SQLDrivers [3]: http://go-lang.cat-v.org/pure-go-libs [4]: http://www.gorillatoolkit.org/

Re: Why I Program in Go

#166

Post by aleksi » Mon, Jan 07, 2013, 4:17 PM UTC

codygman wrote: post #105

microtonal wrote: post #83

Earlier quoted context omitted.

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

The ecosystem makes it more difficult to write bad software. Handle all of your errors, you can't put in things you don't use, it makes testing VERY easy, logging really easy, and if you have testing you have performance testing for free with it. Not having version management is a real concern, but I solve that problem by forking the projects and updating manually as needed. Ubuntu and debian are soon going to be all…

It's not practical to fork all projects if you have a lot of them. And Debian failed in packaging Python and Ruby libraries (IMHO). That's why I created http://gonuts.io

Re: Why I Program in Go

#167

Post by pjmlp » Mon, Jan 07, 2013, 5:14 PM UTC

fusiongyro wrote: post #77

pkulak wrote: post #63

Earlier quoted context omitted.

I have a hard time believing anything can beat or even match the garbage collection performance of the JVM. Not that there is something special about the JVM, just that there have been _so_ many smart people working on the problem for so long now. And for good performance doing server tasks (ie, not computational tasks) exceptional GC is a must. Can a GO program handle a workload that creates tens/hundreds of thousan…

I have to raise the eyebrow to that. I have had more GC problems with Java than any other language. Geniuses fuck up too, and when they do it's pronounced "OutOfMemoryError: PermGen space."

That error is specific for Sun/Oracle's JVM.

Re: Why I Program in Go

#168

Post by pjmlp » Mon, Jan 07, 2013, 5:15 PM UTC

patrickg wrote: post #119

zaphar wrote: post #18

Earlier quoted context omitted.

My day job involves working with Java and C++ on 10+ year old systems. All of my hobby or side projects are in Go these days with occasional diversions into haskell, ML or various Lisps. So I'll try to impart some understanding of why I would switch to Go from Java or C++. First lets get some things out of the way. Go is fast enough and getting faster very quickly and it definitely has a smaller memory footprint. So…

+1. For me a killer feature is that I easily create executables for lin/mac/win on my machine and don't have any dependencies at all (JVM for example).

There are native compilers for Java as well, although not for free.

Re: Why I Program in Go

#169

Post by asdf3 » Mon, Jan 07, 2013, 9:48 PM UTC

agentS wrote: post #121

introspectif wrote: post #106

As an ex-Ruby cum Node.js lover recently converted to Go... Programming in Go, once it clicks, really does feel relaxing and productive. If you're a decent Node.js programmer, it's like stepping up to "Node Pro", in the sense that you work close to the metal with your web server so everything feels clean and easy to wrap your mind around. But Go code is cleaner and tighter. The code formatting conventions contribute…

> I do wish the documentation convention included not only a brief description each function, etc., but also a brief example. It is getting there. If you run godoc locally with tip, you will find many more examples than there were previously. See http://golang.org/pkg/path/ for a current example. And the source for those examples can be found here: http://golang.org/src/pkg/path/example_test.go . Note that this techn…

The golang website supports other versions; to see the docs for tip go to http://tip.golang.org/

Re: Why I Program in Go

#170

Post by lmm » Wed, Jan 09, 2013, 4:42 PM UTC

danenania wrote: post #88

lmm wrote: post #84

Earlier quoted context omitted.

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

I don't think we're not talking a couple of years, more like weeks or days.

How many actually new concepts are there? "sealed" (very simple, but ok it doesn't exist in other languages), "+A" for covariance (genuinely new, but you can ignore it until you want to use it). "with" for multiple inheritance I guess is new, but it works the same as "extends" inheritance (you might have questions about how it handles diamonds, but there aren't any here). Values and members should be familiar, as should the concept of shadowing if not the name (but there's not really a standard term for it).

Implicits are genuinely new, and genuinely complicate the code; I think of them the same way I think of lisp macros (they're too powerful, they're too easy to make the code incomprehensible with - but they enable things that we can't live without, and that we haven't found a safe way of allowing yet). But even then, the concept is very simple and easy to understand.

A big block of text with lots of unfamiliar words in is intimidating, but I don't think it's truly confusing or unreadable if you just take your time and actually try and read it.