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

A little Golang way

aerofs.com

Post reply on HN
Print view View original

11–20 of 194 posts

Re: A little Golang way

#11

Post by jgalt212 »

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.

Re: A little Golang way

#12

Post by markrages »

ploxiln wrote: post #2

I'm all for replacing java bloat with a little bit of go, but it seems like the cause of the bloat becoming a real problem was hopping on the docker bandwagon, for a collection of services that always run together in an appliance and really benefited from being hosted in a shared JVM? Isn't the JVM + servlet container thing supposed to be able to isolate the different services? They get their own bunch of threads, an…

Most of our problems are self-inflicted.

Re: A little Golang way

#13

Post by melling »

I've got a little Swift Language "search engine" that I built with Go on App Engine. I haven't crawled any sites (yet). I simply created a Go data structure to do in memory searches because I didn't feel like using Google's data store.

Here's the site: http://www.h4labs.com/dev/ios/swift.html

Here's the data: https://github.com/melling/SwiftResources/blob/master/swift_...

I'm approaching 1400 URL's and it's still snappy. I was hoping Go's claimed "efficiency" would keep freely hosted a bit longer than Python.

Re: A little Golang way

#14

Post by xienze »

nine_k wrote: post #10
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 idea is that a server this small should probably not consume oodles of memory. They reduced RAM footprint by 100x. Apparently, their Java implementation of this toy service was wildly out of hand. I wish they provided the JVM startup info and stats to compare. Maybe JVM's resource usage could be shrunk, too.

> The idea is that a server this small should probably not consume oodles of memory.

The number of LOC has no bearing on how much memory something will consume. For all you know the service could just be poorly implemented.

Re: A little Golang way

#15

Post by vonsnowman »

jsnk wrote: post #5

More and more I hear about Go, I feel more convinced that it would be worth giving it a shot. Can you share what the microservices are doing? What are they for?

At this point we have 6 microservices written in go in the appliance:

  - team-server probe: already mentioned in the blog post.
    Determines if any installed Team Server is down.

  - ca: as mentioned in the blog post, as simple Certificate Authority

  - charlie: a checkin service. Desktop clients periodically post to it
    to signify they are up. This data is used in each user's device list
    to show if the device is up and which ip it was last seen from.

  - auditor: takes audit event in an HTTP endpoint and forwards
    them to a raw TCP connection as expected by splunk and co

  - valkyrie: a relay server used for data transfers when desktop
    clients cannot establish direct TCP connection (more about that
    in a future blog post)

  - lipwig: a messaging/pubsub server used for peer discovery
    and notifications (more about that in a future blog post)

Re: A little Golang way

#16

Post by dcsommer »

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.

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.

Re: A little Golang way

#17

Post by xienze »

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.

> 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 that you can make these sorts of extrapolations.

Re: A little Golang way

#20

Post by vonsnowman »

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?

As mentioned in the blog post, this was a hackathon project originally, hence the motivation to start with a very small server.

The other servers that went through a rewrite also ended up being significantly smaller in go but that's a story for another day.

Post reply on HN