A little Golang way • Hacker News Board

Re: A little Golang way

#51

Post by jacquesm » Wed, Aug 05, 2015, 7:03 PM UTC

lpsz wrote: post #31

Anecdotes like this makes me wonder how much funding money and electricity could be saved if people migrated en masse from Ruby/Python/Something else to Go. (Edit: not meant to be a political statement, more of a practical observation. I only recently started using Go.)

That may be one of the bigger chances for go: mobile. After all being more efficient on mobile translates into longer battery life and go potentially has a huge advantage over the current java (ok, not java) based environment on Android. For google this would be a triple win, get out of the Oracle mess entirely, give their mobile developers a super fast toolchain and give the end users better battery life.

Re: A little Golang way

#52

Post by staunch » Wed, Aug 05, 2015, 7:03 PM UTC

eropple wrote: post #33

travjones wrote: post #25

There have been several blog posts and conference presentations with a similar theme -- "Go is efficient, especially compared to X." I know it seems like hype, but I encourage others to try Golang out, maybe even slap a web app together with it. What you'll find is that your Go app will be extremely efficient and performant. It's kind of unfair to compare Go to many of the other languages of the web because it is com…

> What you'll find is that your Go app will be extremely efficient and performant. This is true, for sure. But my experience--and I've written plenty of Go, though I find it unpleasant to write and think about for all the usual reasons that Go partisans roll their eyes and so would rather deal with it as artifacts rather than actually writing it--has led to watching lots of developers make mudball codebases in the pr…

> Statically linking your SSL library makes you an asshole...Heartbleed 2.0.

Go has its own SSL library, crypto/tls, which is not linked to any C libraries and wasn't affected by Heartbleed 1.0. You haven't written much Go if you don't know that.

The argument is specious anyway, there's nothing difficult about building a binary from an old version of your code or just upgrading in most cases. Deploying a new Go binary is always trivial as compared with upgrading, testing, and deploying Python, Ruby, or Java applications with their associated libraries and interpreters.

Re: A little Golang way

#53

Post by pcwalton » Wed, Aug 05, 2015, 7:05 PM UTC

chimeracoder wrote: post #37

eropple wrote: post #33

Earlier quoted context omitted.

> What you'll find is that your Go app will be extremely efficient and performant. This is true, for sure. But my experience--and I've written plenty of Go, though I find it unpleasant to write and think about for all the usual reasons that Go partisans roll their eyes and so would rather deal with it as artifacts rather than actually writing it--has led to watching lots of developers make mudball codebases in the pr…

> design patterns--and we should be reminded that design patterns exist to address defects in tooling This is a really important point, and I think it's why a number of best-practices in Go are actually not best practices in other languages, and vice versa. One of the explicit, top-level design goals of Go was to focus on creating top-notch tooling as part of the language. While it is not the only language that has t…

> Because the tooling was a first-class design goal, a number of the problems that traditional design patterns were created to address are less problematic in Go code[1].

> [1] Again: gofmt…

What does gofmt have to do with design patterns?

gofmt is about code formatting. Design patterns are about abstraction and expressiveness. A code formatting tool does nothing to address abstraction and expressiveness of the language.

Re: A little Golang way

#54

Post by sz4kerto » Wed, Aug 05, 2015, 7:06 PM UTC

mkozlows wrote: post #8

sz4kerto wrote: post #4

"Code size was reduced by almost half, from 175 lines down to 96." Hm, I how can we take a 175 LOC project as something relevant in any way?

The relevance is that even a 175 LOC project in Java takes up enormous memory and disk footprint -- that the JVM is this super-heavyweight thing that's really just inherently inappropriate for a lot of applications.

Yes, it's larger than a C or Go process. Does it usually matter? No.

The whole Netflix is based on the JVM and Java. They are enormously big, they have high CPU and I/O requirements in many cases, and yet, they manage well on Java.

I'm not a big fan of Java as language (to say the least), but the JVM as a runtime is very-very sophisticated.

Re: A little Golang way

#55

Post by eternalban » Wed, Aug 05, 2015, 7:11 PM UTC

travjones wrote: post #25

There have been several blog posts and conference presentations with a similar theme -- "Go is efficient, especially compared to X." I know it seems like hype, but I encourage others to try Golang out, maybe even slap a web app together with it. What you'll find is that your Go app will be extremely efficient and performant. It's kind of unfair to compare Go to many of the other languages of the web because it is com…

I prototyped a cache in Go and the ref. impl. in C. I'm a long time Go coder but did not expect the Go prototype to run so damn close to the C (and for certain ops actually faster than C).

The runtime is shaping up quite nicely. Given dynamic linking and this language can pretty much pull its weight in the backend for almost anything.

Re: A little Golang way

#56

Post by melling » Wed, Aug 05, 2015, 7:11 PM UTC

lpsz wrote: post #31

Anecdotes like this makes me wonder how much funding money and electricity could be saved if people migrated en masse from Ruby/Python/Something else to Go. (Edit: not meant to be a political statement, more of a practical observation. I only recently started using Go.)

These guys went from 30 servers to 2 by switching to Go.

http://www.iron.io/blog/2013/03/how-we-went-from-30-servers-...

Re: A little Golang way

#57

Post by chimeracoder » Wed, Aug 05, 2015, 7:11 PM UTC

pcwalton wrote: post #53

chimeracoder wrote: post #37

Earlier quoted context omitted.

> design patterns--and we should be reminded that design patterns exist to address defects in tooling This is a really important point, and I think it's why a number of best-practices in Go are actually not best practices in other languages, and vice versa. One of the explicit, top-level design goals of Go was to focus on creating top-notch tooling as part of the language. While it is not the only language that has t…

> Because the tooling was a first-class design goal, a number of the problems that traditional design patterns were created to address are less problematic in Go code[1]. > [1] Again: gofmt… What does gofmt have to do with design patterns? gofmt is about code formatting. Design patterns are about abstraction and expressiveness. A code formatting tool does nothing to address abstraction and expressiveness of the langu…

> gofmt is about code formatting. Design patterns are about abstraction and expressiveness.

First, gofmt can do more than code formatting, such as applying simplifying code transformations that are semantically equivalent. Second, code formatting and design patterns are indeed related, because the way code is laid out in text is the way that design patterns are expressed. The layout of code affects how abstractions are presented, which affects which abstractions are easy to reason about and work with.

Finally, I picked gofmt because it's a pretty uncontroversial tool, and one that is so successful that even languages like Rust have adopted or are working something similar. I'm really not interested in starting another flamewar about why Go lacks $FEATURE and therefore $OTHER_LANG is better, because we have had enough of those on HN, don't you think?

Re: A little Golang way

#58

Post by pcwalton » Wed, Aug 05, 2015, 7:12 PM UTC

staunch wrote: post #52

eropple wrote: post #33

Earlier quoted context omitted.

> What you'll find is that your Go app will be extremely efficient and performant. This is true, for sure. But my experience--and I've written plenty of Go, though I find it unpleasant to write and think about for all the usual reasons that Go partisans roll their eyes and so would rather deal with it as artifacts rather than actually writing it--has led to watching lots of developers make mudball codebases in the pr…

> Statically linking your SSL library makes you an asshole...Heartbleed 2.0. Go has its own SSL library, crypto/tls, which is not linked to any C libraries and wasn't affected by Heartbleed 1.0. You haven't written much Go if you don't know that. The argument is specious anyway, there's nothing difficult about building a binary from an old version of your code or just upgrading in most cases. Deploying a new Go binar…

> Go has its own SSL library, crypto/tls, which is not linked to any C libraries and wasn't affected by Heartbleed 1.0. You haven't written much Go if you don't know that.

The parent poster obviously wasn't saying that crypto/tls was affected by Heartbleed specifically. It was a statement about the security implications of static linking.

Re: A little Golang way

#59

Post by kzhahou » Wed, Aug 05, 2015, 7:12 PM UTC

staunch wrote: post #52

eropple wrote: post #33

Earlier quoted context omitted.

> What you'll find is that your Go app will be extremely efficient and performant. This is true, for sure. But my experience--and I've written plenty of Go, though I find it unpleasant to write and think about for all the usual reasons that Go partisans roll their eyes and so would rather deal with it as artifacts rather than actually writing it--has led to watching lots of developers make mudball codebases in the pr…

> Statically linking your SSL library makes you an asshole...Heartbleed 2.0. Go has its own SSL library, crypto/tls, which is not linked to any C libraries and wasn't affected by Heartbleed 1.0. You haven't written much Go if you don't know that. The argument is specious anyway, there's nothing difficult about building a binary from an old version of your code or just upgrading in most cases. Deploying a new Go binar…

His point was not that golang was susceptible to heartbleed. It's about static vs dynamic linking.

Re: A little Golang way

#60

Post by nickbauman » Wed, Aug 05, 2015, 7:12 PM UTC

chimeracoder wrote: post #37

eropple wrote: post #33

Earlier quoted context omitted.

> What you'll find is that your Go app will be extremely efficient and performant. This is true, for sure. But my experience--and I've written plenty of Go, though I find it unpleasant to write and think about for all the usual reasons that Go partisans roll their eyes and so would rather deal with it as artifacts rather than actually writing it--has led to watching lots of developers make mudball codebases in the pr…

> design patterns--and we should be reminded that design patterns exist to address defects in tooling This is a really important point, and I think it's why a number of best-practices in Go are actually not best practices in other languages, and vice versa. One of the explicit, top-level design goals of Go was to focus on creating top-notch tooling as part of the language. While it is not the only language that has t…

Top notch tooling? The debugger is neigh unusable. `go get` is a community joke. The compiler is fast mostly because it doesn't check for things that better compilers do. Go race is a symptom that not all is well in the CSP house. Other static analysis tools are third party and limited if they exist at all. Go really does remind me of JDK 1.4.