Live data from Hacker News

Why I Program in Go

tech.t9i.in

31–40 of 171 posts

Re: Why I Program in Go

#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 oversimplified:

The compiler not only checks for code that can theoretically result in a runnable program...

It's not exactly as if Go did solve the halting problem or we'd ALL be using Go. So I think a bit more in-depth explanation would have been welcome.

Re: Why I Program in Go

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

How did you write a go script faster than a python script? That sounds intriguing.

The time it takes to 'go run' a go program is about the same as the time it takes to run a python program. If you are able to write Go code faster than Python code (that is the important "if". I can, some cannot. It's a personal thing.), then Go will be faster than python.

Re: Why I Program in Go

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

"Java IDEs really get the job done"

That is utterly misleading. Java IDEs really get the Java job done. And, sadly, Java is a language of such an incredible verboseness and containing so many idiosynchrasies that it takes a lot of code to do things. And IDEs do certainly excel at this.

But you have to realize that a lot of the IDEs' functionalities when it comes to Java are really just work around Java's failures.

So, yes, I can fire IDEA and it shall allow me "easily" work around a 100 000 LOC codebase.

But if I can write the same program in 30 000 LOC of Go or 10 000 LOC of a Lisp dialect I think that there's still a jury out there trying to determine if Java IDEs are really that great.

So I don't doubt that IDEA / Eclipse is helping you in your Java + ORM + XML hell but there are other ways to develop applications. Mind you: it's a huge world out there and despite your beloved IDEs being so great there are still people not programming in Java.

Also the IDEs tend to suck quite a lot when we're talking about "non-Java JVM languages".

Btw I'm using IntelliJ since so long I don't remember if it was version 3 or 4 and I just bought version 12.

-- "Patterns means I have run out of language"

Re: Why I Program in Go

#34
post #27
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…

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…

> most Go objects are mutable and can still be passed as messages.

Go makes it easy to get right. It doesn't make you get it right.

Re: Why I Program in Go

#35
post #17

Earlier quoted context omitted.

>Here, too, the author says that he didn't like Java's IDEs (really? does Go have better tooling? You should really write a GO code to understand what the author means. Writing GO code has no frills. And I have seen nothing cooler than: http://gofmt.com/ .

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

You may as well argue that Brainfuck is just as good as scheme, since they are both Turing complete.

It is all about friction; either language/toolset will get the job done, but which will I find more enjoyable?

Re: Why I Program in Go

#36
post #28
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…

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 is to be as close to the metal as possible, by allocating gigantic primitive arrays... Quite the contrary of your beloved GC dogma, where you think that creating objects as no impact and that slow GCs are necessarily the programmer's fault).

I realize from your various post that you did really drink the Java cool-aid and that no matter what's going to be said you'll always come touting Java as the best language out there.

I know Java well enough to criticize it.

I also have the impression that Go is used inside Google on some impressive tasks so I wouldn't be to quick to dismiss it.

Re: Why I Program in Go

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

Not to mention the frankly idiotic JVM startup time that becomes a nightmare if you are just trying to make a commandline tool.

And no, don't bother mentioning nailgun or the like. Those cures are worse than the illness.

Re: Why I Program in Go

#38
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?

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

Re: Why I Program in Go

#39
post #28
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…

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.

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

It is definitely true that the JVM had been thoroughly road tested compared to Go, but your conclusion is unsound. Go was designed to specifically avoid this pitfall.

Re: Why I Program in Go

#40
post #27
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…

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 immutability is as key to concurrency as it gets hyped to be. Clojure which I've used and enjoyed does tend to get in your way with the immutability by default.

This to me makes Clojure less relaxing. In fact Clojure is not relaxing it's challenging which can be enjoyable but I wouldn't say it's what I want to do everyday for my job. Go I could easily see myself doing it everyday.

As I said Go has a lot of good qualities all in one package. Clojure has some of those qualities but not all of them.

The pointer to the compiler api is interesting. I hadn't seen it before. I don't see any way to serialize a source tree in there but that might be just for lack of searching. I wonder why things like gofmt and company don't exist in the java toolchain already. I mean outside of third party IDE's.

Post reply on HN