Why I Program in Go • Hacker News Board

Re: Why I Program in Go

#41

Post by zaphar » Sun, Jan 06, 2013, 3:18 AM UTC

Locke1689 wrote: post #26

enneff wrote: post #25

Earlier quoted context omitted.

Go programs don't just use less memory, the language makes it possible to control memory allocations. With the JVM-based languages I'm familiar with, it is difficult to control the memory allocation characteristics of you program, and typically the further the language deviates from the JVM's model (eg, Clojure and Scala) the more garbage must be generated (usually in doing= things like runtime type reflection). All…

I don't see anything special in Go for commanding the GC, can you point me to these APIs?

Go's memory model has similarities to C. For instance you can use the heap or the stack. Go figures out which one an allocation should live in by doing escape analysis. If it never leaves the function it goes on the stack. If it does it goes on the heap. GC ensures anything on the heap gets cleaned up. It's not an API.

Re: Why I Program in Go

#42

Post by pron » Sun, Jan 06, 2013, 3:20 AM UTC

martinced wrote: post #36

pron wrote: post #28

Earlier quoted context omitted.

The only reason you hear less "crazy" Go GC stories is because Go has never been tested as much as the JVM under different application requirements. And if high-profile companies have servers that spend 80% of the time in GC -- well, they must have really neglected their code. That's a result of poor software maintenance, and I doubt any language could help them.

No... It's because Java totally sucks when objects go from Eden to Survivor and then needs to be GC'ed or from Eden to Survivor to Tenured and then needs to be GC'ed. That's the very reason why some trading companies who still insist on using Java do use methods where as few objects as possible are ever created and went on to invent things like the LMAX disruptor "pattern" (more like an anti-pattern, where the goal i…

I'm not dismissing Go, and I'm not praising Java, and I've even admitted on this very thread that Go is better than Java, so there's really no need in trying to convince me of anything. All I'm saying is that Go isn't good enough -- if I really want fast development and expressivity, there are languages more expressive than Go (more so than Go is to Java), and if I really need top-notch performance, then Java is OK and comes with some absolutely useful advantages that Go doesn't offer. I see excellent use cases for Python, for Ruby, for Clojure, for Java and for C/C++. I just don't see compelling use cases for Go. I'm not dismissing it. It's really nice. I just think it's underwhelming.

And, BTW, if you think Go has some magic GC secrets that will make all (or even some) of the JVM GC problems go away -- I believe you're mistaken.

Re: Why I Program in Go

#43

Post by tikhonj » Sun, Jan 06, 2013, 3:20 AM UTC

martinced wrote: post #31

His second point is, to me, the most important for would-be language designers: Standardized formatting: A standard tool to enforce formatting rules that is not subject to change based on the team members' or leader's opinions is a welcome feature for lowering the "not my code" mental barrier. This is a godsend. The best thing to have happened to our industry since a very long time. But his first point is oversimplif…

In a certain sense, languages like Agda do solve the halting program, but we're not all using them...

Seeing more total languages used in industry would be pretty cool.

Re: Why I Program in Go

#44

Post by pcwalton » Sun, Jan 06, 2013, 3:20 AM UTC

zaphar wrote: post #41

Locke1689 wrote: post #26

Earlier quoted context omitted.

I don't see anything special in Go for commanding the GC, can you point me to these APIs?

Go's memory model has similarities to C. For instance you can use the heap or the stack. Go figures out which one an allocation should live in by doing escape analysis. If it never leaves the function it goes on the stack. If it does it goes on the heap. GC ensures anything on the heap gets cleaned up. It's not an API.

To be fair, Java does escape analysis for this too. This isn't a difference between Java and Go.

Re: Why I Program in Go

#45

Post by chimeracoder » Sun, Jan 06, 2013, 3:23 AM UTC

martinced wrote: post #31

His second point is, to me, the most important for would-be language designers: Standardized formatting: A standard tool to enforce formatting rules that is not subject to change based on the team members' or leader's opinions is a welcome feature for lowering the "not my code" mental barrier. This is a godsend. The best thing to have happened to our industry since a very long time. But his first point is oversimplif…

Slight correction

> The compiler not only checks for code that can theoretically result in a [logically correct], runnable program...

Some examples of this:

- If you try to assign to a variable that will never be read, this is a compile-time error.

- If you try to import a module that will never be used, this is a compile-time error.

- If your dependencies don't form a DAG, this is a compile-time error.

Incidentally, not only does this make runtime errors (or logical errors) much less common, it also makes Go code more readable and vastly contributes to its impressive compilation speed.

Re: Why I Program in Go

#46

Post by Locke1689 » Sun, Jan 06, 2013, 3:23 AM UTC

enneff wrote: post #38

Locke1689 wrote: post #26

Earlier quoted context omitted.

I don't see anything special in Go for commanding the GC, can you point me to these APIs?

It's not about commanding the GC. It's about avoiding unnecessary allocations.

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

Re: Why I Program in Go

#47

Post by chimeracoder » Sun, Jan 06, 2013, 3:26 AM UTC

zaphar wrote: post #24

pron wrote: post #17

Earlier quoted context omitted.

Even if that's the case, Go just brings too little to the table. And if you think gofmt is cool, take a look at Project Jackpot [1], or its use in the NetBeans IDE [2]. [1] https://bitbucket.org/jlahoda/jackpot30/wiki/Home [2] http://netbeans.org/kb/docs/java/editor-inspect-transform.ht...

Those aren't in the stdlib. gofmt is. So is gofix, go vet, godoc and a host of other things. Batteries included means a lot.

> Those aren't in the stdlib. gofmt is.

Which also means that you can count on any Go code you find online to be formatted the same way too.

It's like PEP 8, except better, because it's a lot more widely enforced.

Re: Why I Program in Go

#48

Post by Locke1689 » Sun, Jan 06, 2013, 3:27 AM UTC

zaphar wrote: post #41

Locke1689 wrote: post #26

Earlier quoted context omitted.

I don't see anything special in Go for commanding the GC, can you point me to these APIs?

Go's memory model has similarities to C. For instance you can use the heap or the stack. Go figures out which one an allocation should live in by doing escape analysis. If it never leaves the function it goes on the stack. If it does it goes on the heap. GC ensures anything on the heap gets cleaned up. It's not an API.

Both the JVM and the CLR do this. This is not a Go technology.

In fact, in certain cases the JVM can detect type information and remove the allocation entirely by hoisting integer fields and the like into registers.

Re: Why I Program in Go

#49

Post by Locke1689 » Sun, Jan 06, 2013, 3:32 AM UTC

martinced wrote: post #36

pron wrote: post #28

Earlier quoted context omitted.

The only reason you hear less "crazy" Go GC stories is because Go has never been tested as much as the JVM under different application requirements. And if high-profile companies have servers that spend 80% of the time in GC -- well, they must have really neglected their code. That's a result of poor software maintenance, and I doubt any language could help them.

No... It's because Java totally sucks when objects go from Eden to Survivor and then needs to be GC'ed or from Eden to Survivor to Tenured and then needs to be GC'ed. That's the very reason why some trading companies who still insist on using Java do use methods where as few objects as possible are ever created and went on to invent things like the LMAX disruptor "pattern" (more like an anti-pattern, where the goal i…

I'm not sure what "impressive tasks" you mean, but I don't think that's true. I heard of people using Go, true, but the perf-heavy backends are all in C++.

Re: Why I Program in Go

#50

Post by pron » Sun, Jan 06, 2013, 3:35 AM UTC

zaphar wrote: post #40

pron wrote: post #27

Earlier quoted context omitted.

Oh, I don't doubt many things can be done much better in other languages than Java, only why stop at Go? Clojure pretty much hits every single one of your requirements, it's more modern and expressive than Go, gets concurrency better, and it's about as slower than Go as Go is slower than Java -- and getting faster. Also, you don't have to give up the monitoring and instrumentation the JVM gives you, as well as the va…

> I'm not so sure about that. If I'm not mistaken, most Go objects are mutable and can still be passed as messages. This is actually a complex subject. Go has mutable objects yes. But it also doesn't treat everything like an reference type. You have to send a pointer as the message if you want the receiver to be able to modify the object you sent. (slices and maps are the exception to this) I actually don't think imm…

Alright, I'm sure some people find Go's particular combination of features appealing. For me, a language has got to be so unbelievably awesome to consider leaving the JVM, and seeing that some of the most awesome languages target the JVM, that language better do something that would truly impress a veteran like me. There's only one non-JVM language that I'll use for some very specific applications, that I think is all that: Erlang.