Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I Program in Go

tech.t9i.in

Post reply on HN
Print view View original

51–60 of 171 posts

Re: Why I Program in Go

#51

Post by jlgreco »

chimeracoder wrote: post #47
zaphar wrote: post #24

Earlier quoted context omitted.

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.

Exactly. What you can reasonably expect from code in the wild makes a world of difference.

When I am working on personal projects that I have in C, I use `-Wall -Wextra -Werror -pedantic` (along with the strictest `-std=` that the particular project will allow), and it makes my development experience an order of magnitude more pleasant. However when I am working on C code that is primarily somebody else's, I rarely get the pleasure of expecting code neat enough to allow me to reasonably use those flags. This makes working in C a much less pleasant experience overall.

That Go goes further and is strict about style too is just brilliant.

Re: Why I Program in Go

#52

Post by ericbb »

> Now, you might want to ... acquaint yourself with [dataflow variables and declarative concurrency] because [they are] the centre-piece of Go's language features.

Not so. Go has native support for neither dataflow variables nor declarative concurrency. Go does have native support for message-passing concurrency--but that's different.

Re: Why I Program in Go

#53

Post by cgag »

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…

I'm not sure if it's just a mindset thing or the stuff I've used it for, but I've never felt the immutability got in the way, it's one of the things I miss most when using other language.

Re: Why I Program in Go

#54

Post by estavaro »

zaphar wrote: post #18
pron wrote: 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…

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…

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 send the source-code to the deployment servers to compile on them too. I seem to recall that deployment servers shouldn't need to have development tools which were themselves exposing the servers to bad intention by bad folks. It's just hard to keep the separation I guess.

Go error handling is not to be taken lightly just because you can ignore error codes or just print the error and be done with it. I seem to recall that the core developers of Go demanding that Go users try harder to handle errors. Something the compiler doesn't really "enforce".

I prefer Dart to Go because Dart starts from a higher level of abstraction already. Also Dart has been the result of two years of development even if many of the Dart developers also had plenty of experience with developing past languages and tools.

OOP already gives us a lot of bondage and discipline. No need for more incentive by the compiler. Sometimes a couple of extra tools can help our hands without it being forced by the compiler with every run. Say a tool that helps to tell us which methods or variables aren't being used. Go forces us to deal with that on every compiler run. (Even if it can be disabled, but the Go developers prefer to avoid proliferation of config options.)

It's good to have Go and Dart around. So it's not just legacy (Java) and Microsoft (C#) dictating the standards.

Re: Why I Program in Go

#55

Post by ericbb »

pron wrote: post #27
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…

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…

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

Re: Why I Program in Go

#56

Post by jmspring »

pron wrote: 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…

For me, Go aside, I just don't want to deal with the JVM. Sure, VMs are great -- erlang has a nice one, iterations of the JVM are still nicer than they were circa 1998, etc. But, I've dealt with services web services in C/C++, PHP, Python, Go, Java, etc. 5-10 years ago, Java and it's assorted frameworks had it's place, but the intersection of Jetty, JBoss/Tomcat, Glassfish, and plain old Java apps muddied the waters about managing Java apps. If you use a framework, you will need to tweak memory settings to make sure things behave well.

Re: Why I Program in Go

#57

Post by pron »

ericbb wrote: post #55
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…

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

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)

Re: Why I Program in Go

#58

Post by stock_toaster »

estavaro wrote: post #54
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…

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…

  > Funny thing about Go is that as a compiled language, folks often need
  > to send the source-code to the deployment servers to compile on them too.
They do? Why not build as part of a CI run? Or via cross compile?

It is generally much easier to deploy a versioned statically compiled binary, compared to rolling out code to production in some languages (ruby, python, etc).

Re: Why I Program in Go

#59

Post by c141charlie »

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.org/src/pkg/container/list/list.go, and you're presented with very readable source code.

Now compare this with Java. I just Google'd Java List. First link is this: http://docs.oracle.com/javase/6/docs/api/java/util/List.html

Documentation looks OK, but wait, this is the interface. I want to see docs for a concrete implementation. I'm tempted to click on the AbstractList link, but oh wait, that's just another non-concrete class that other List classes probably inherit from. Let's see, let's go to the ArrayList ... this looks good. http://docs.oracle.com/javase/6/docs/api/java/util/ArrayList...

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

Let's try Scala. Google "Scala List". Click on first link. http://www.scala-lang.org/api/current/index.html#scala.colle...

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]]"

Oh sweet, this thing has all kinds of methods, i.e. ++, ++:, +:, /:, :+, ::, :::, :\

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

Looking back to the Go documentation, I immediately "relax" as another commenter put it.

For some reason, I think Scala will end up being the next Java. It has so much momentum, runs on the JVM, has seamless interop with Java code. Has the Play Framework, AKKA, and thousands of other awesome libraries written for it. And if Scala powers Twitter, then I think this answers the scalability and concurrency question.

While I'm bullish on Scala, at the end of the day, I find Go's simplicity make it more beautiful than any other language.

Re: Why I Program in Go

#60

Post by green7ea »

pron wrote: 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…

I program to solve problems. I usually solve the problems in my head or on paper before doing any coding.There is usually a step afterwards during which I translate this solution into a given programming language. This step in Java is much harder than I would like.

The reason for this is that I feel I spend too much time doing taxonomy and managing complex relationships between different classes when programming in Java. This occurs in every programming language but I find Java is by far the most restrictive in this regard. I find go much more flexible, as much as python, and scheme even more so.

The end result is that I am more productive when programming in these languages and most importantly I feel that I am not doing as much busywork. This in turns makes programming more fun and rewarding.

Post reply on HN