A little Golang way • Hacker News Board

Re: A little Golang way

#21

Post by microtonal » Wed, Aug 05, 2015, 6:01 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.

Until you have enough microservices and each microservice carries its own Go runtime. Then having one JVM suddenly isn't so bad. The problem (as someone else said) is that using Docker may not be the right solution here.

There are enough solutions (e.g. servlet containers) where you can run multiple services in one VM, with isolation, and security hardening (using security manager).

With regards to memory footprint - the difference here is that Java uses a minimum and maximum heap size that can be tuned with parameters. This has downsides (typically more memory use) and upsides (upper bound on the maximum memory use of a process).

Re: A little Golang way

#22

Post by Zikes » Wed, Aug 05, 2015, 6:02 PM UTC

jgalt212 wrote: post #11

aikah wrote: post #6

I'll bite. While it is absolutely true Go servers use less memory that classic servlet deployments, The question is what were you using at first place? where you using a big framework? with this or that big IoC container ? with a bloated ORM ? ... or where you using barebone jdbc and writing servlets without any framework? because essentially that's what you're doing with Go, Go has 0 big framework(and no Beego or Re…

> the Go code culture is basically about writing correct code without thinking about re-usability at all, because often you just can't. So I'm curious. That's a very strong statement. Do you have evidence to support this? I don't code in Go right now, but have been keeping an eye on it as it continues to gather momentum.

The parent comment is incorrect. Orthogonality is a really big deal in Go, and is highly stressed in the culture. Libraries are strongly encouraged to present methods that work with interfaces that are defined by the standard library to ensure the libraries are composable.

If your library works with streams of bytes, its methods had better use io.Reader and io.Writer. If you're writing an ORM, it had better be built on database/sql.

Re: A little Golang way

#23

Post by [deleted] » Wed, Aug 05, 2015, 6:03 PM UTC

dcsommer wrote: post #16

jgalt212 wrote: post #11

Earlier quoted context omitted.

> the Go code culture is basically about writing correct code without thinking about re-usability at all, because often you just can't. So I'm curious. That's a very strong statement. Do you have evidence to support this? I don't code in Go right now, but have been keeping an eye on it as it continues to gather momentum.

Lack of generics can make it harder to write cleanly reusable modules in Go. I've noticed gophers are often less allergic to copy pasting code with tweaks (as long as it isn't too many lines) and don't mind rewriting similar code if it is obviously correct. It was a bit of a culture shock for me at least.

[deleted]

Re: A little Golang way

#24

Post by mkozlows » Wed, Aug 05, 2015, 6:04 PM UTC

xienze wrote: post #17

mkozlows wrote: post #8

Earlier quoted context omitted.

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.

> The relevance is that even a 175 LOC project in Java takes up enormous memory and disk footprint _This particular_ 175 LOC Java project takes up an enormous amount of memory. For all you know it was just coded poorly and the Go one is a bit more reasonable. > the JVM is this super-heavyweight thing that's really just inherently inappropriate for a lot of applications. The JVM introduces overhead but not so much tha…

34MB for Hello World, according to this SO post: http://stackoverflow.com/questions/13692206/high-java-memory...

I'm not going to install the JDK just to verify, but feel free to report back if you get different results.

Re: A little Golang way

#25

Post by travjones » Wed, Aug 05, 2015, 6:09 PM UTC

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 compiled, which is a huge reason why it is so performant. So rather than compare Go to other languages, I encourage you all to give it a try. If you already program, working on a small Go side project will get you up to speed quickly and you'll learn about some of the awesome packages individuals from the Go community have put together for us.

Disclaimer: I do not work for Google. I write Go code and enjoy it. I think others will too.

Re: A little Golang way

#26

Post by vonsnowman » Wed, Aug 05, 2015, 6:12 PM UTC

xienze wrote: post #17

mkozlows wrote: post #8

Earlier quoted context omitted.

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.

> The relevance is that even a 175 LOC project in Java takes up enormous memory and disk footprint _This particular_ 175 LOC Java project takes up an enormous amount of memory. For all you know it was just coded poorly and the Go one is a bit more reasonable. > the JVM is this super-heavyweight thing that's really just inherently inappropriate for a lot of applications. The JVM introduces overhead but not so much tha…

The footprint of this particular service could have been optimized in Java but:

  1. the JVM itself imposes a high floor (hotspot, many shared libs loaded, ...)

  2. the Java language is full of overhead at every level (boxed types are a pet peeve of mine)

  3. the Java ecosystem has a tendency to regard memory as an inexhaustible resource, which lead a lot of waste in many 3rd party libraries

The core point is that optimizing this particular Java program (and the others that followed) would have been more time-consuming than a Golang rewrite and would have probably increased the complexity whereas a Golang rewrite reduced it.

Optimization was the original goal, increased maintainability was a pleasant result.

Re: A little Golang way

#27

Post by _ak » Wed, Aug 05, 2015, 6:13 PM UTC

dcsommer wrote: post #16

jgalt212 wrote: post #11

Earlier quoted context omitted.

> the Go code culture is basically about writing correct code without thinking about re-usability at all, because often you just can't. So I'm curious. That's a very strong statement. Do you have evidence to support this? I don't code in Go right now, but have been keeping an eye on it as it continues to gather momentum.

Lack of generics can make it harder to write cleanly reusable modules in Go. I've noticed gophers are often less allergic to copy pasting code with tweaks (as long as it isn't too many lines) and don't mind rewriting similar code if it is obviously correct. It was a bit of a culture shock for me at least.

You confuse parametric polymorphism with reusability. The former is merely one of several ways to achieve the latter. The Go way for reusability usually consists of interfaces.

Re: A little Golang way

#28

Post by shocks » Wed, Aug 05, 2015, 6:14 PM UTC

stesch wrote: post #18

How tied is Go into Google? What if Google drops Go?

Go is a programming language born out of Google for sure, but that does not mean it depends on Google. It's a community project after all.

Re: A little Golang way

#29

Post by dcsommer » Wed, Aug 05, 2015, 6:19 PM UTC

_ak wrote: post #27

dcsommer wrote: post #16

Earlier quoted context omitted.

Lack of generics can make it harder to write cleanly reusable modules in Go. I've noticed gophers are often less allergic to copy pasting code with tweaks (as long as it isn't too many lines) and don't mind rewriting similar code if it is obviously correct. It was a bit of a culture shock for me at least.

You confuse parametric polymorphism with reusability. The former is merely one of several ways to achieve the latter. The Go way for reusability usually consists of interfaces.

Code reuse is totally possible in Go. I never said otherwise. However, there may be unnecessary ergonomic and safety issues due to lack of generics. In particular, you may end up casting / type asserting when you really shouldn't have to.

Re: A little Golang way

#30

Post by zer00eyz » Wed, Aug 05, 2015, 6:21 PM UTC

jgalt212 wrote: post #11

aikah wrote: post #6

I'll bite. While it is absolutely true Go servers use less memory that classic servlet deployments, The question is what were you using at first place? where you using a big framework? with this or that big IoC container ? with a bloated ORM ? ... or where you using barebone jdbc and writing servlets without any framework? because essentially that's what you're doing with Go, Go has 0 big framework(and no Beego or Re…

> the Go code culture is basically about writing correct code without thinking about re-usability at all, because often you just can't. So I'm curious. That's a very strong statement. Do you have evidence to support this? I don't code in Go right now, but have been keeping an eye on it as it continues to gather momentum.

I'll jump on this, but I'm going to change it up a bit.

> the Go code culture is basically about writing correct code without thinking about USABILITY at all

The reality is go is YOUNG and it shows. Lets take two good examples that are part of what is going on in golang today.

Vendoring: The core teams approach, and what the community are doing have diverged pretty rapidly. Recently there have been some efforts bring vendoring into alignment, but what is being used isn't the best approach/solution, its good but on the whole could be better.

http: The core library is great if you want something small, and its fairly easy to put together a tool chain that will remain "idiomatic". However if your going to go out and build something "large" then you have an interesting issue, because OOTB core http lacks any concept of context. There are some interesting tools and frameworks out there to make up for this (gorilla/context, codegangsta/negroni) but if you adopt them your no longer "idiomatic"... your libraries are now less reusable because they are tightly coupled. It looks like a new method signature is going to be required in the http package, one that uses golang.org/x/net/context and returns errors so we can have a sane http stack OOTB in go....

Log vs syslog: Logging in go is fairly messy right now... there are a bunch of packages that try to make up for this, but really better logging has to be built into the core. Syslog has levels/features, log is just dry and basic (maybe too much so). The core not only needs a unified solution, but one that is going to be context aware.

Will these get fixed? Probably! The core team isn't deaf. However if they don't start moving on a path to 2.0 soon and address some of the real issues, I fear that go will end up in the same boat that python did in 2.x vs 3.x.

P.S. in spite of all this I have been writing a LOT of go lately and enjoying it, but it really does need to grow and soon!