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

41–50 of 194 posts

Re: A little Golang way

#41

Post by tracker1 »

mkozlows wrote: post #24
xienze wrote: post #17

Earlier quoted context omitted.

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

For comparison... I did a similar Hello World test around the timeframe of .Net 2.0, and it was around 11mb to load IIRC. The latest iojs on windows seems to be just under 9mb.

Not sure what the golang overhead is, by comparison.

Re: A little Golang way

#42

Post by akhilcacharya »

melling wrote: post #13

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 sna…

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

That is exactly why I picked my Go for my latest side project.

I just hope the framework I'm using isn't the bottleneck, because I really hate writing pure Go servers.

Re: A little Golang way

#43

Post by lobster_johnson »

jaytaylor wrote: post #40

Can anyone shed some light on how/why running the same Java apps in a docker container significantly increased the memory footprint? Is JVM overhead shared when multiple Java apps are being run on the same machine?

Assuming this is referrring to the fact that separate containers will link in separate copies of all the binaries (executable + shared libraries), instead of sharing the pages across all instances of he JVM. There's no way for the kernel to know that they're all the same files. So a lot of code is duplicated.

Re: A little Golang way

#44

Post by _JamesA_ »

Java's main feature is compile once - run (almost) anywhere. From embedded to mainframe as long as a JVM is available.

How does Go stack up for cross-platform development? Does every application and library have to be (re)compiled for the target platform?

What about support for alternative architectures (ARM, PowerPC, etc)?

Re: A little Golang way

#45

Post by tracker1 »

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

Also, the more complex a system is, the less the runtime overhead is by comparison. Hello world examples in .Net, node.js etc are 35-20% the memory overhead compared to Java.

It's not like golang doesn't have some overhead of its' own... There's also Rust, and D to consider.

Re: A little Golang way

#46

Post by [deleted] »

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

[deleted]

Re: A little Golang way

#47

Post by stock_toaster »

Conlectus wrote: post #36
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…

> Go also discourages program extensibility through components Can you elaborate on this? Because in my experience with Go, I found that I had to make _far_ more components (assuming this means libraries?) than other languages. > Statically linking your SSL library makes you an asshole when it inevitably fails and now an application has to be regression-tested so that new features and new bugs don't hose you just bec…

I think the parent was saying that new releases would bring new features the end user may not want, in addition to something like a security fix for an included library.

With shared libs, you can keep using an old version if it works for you, while still updating ssl to a fixed version (assuming api compat).

Re: A little Golang way

#48

Post by haldean »

jaytaylor wrote: post #40

Can anyone shed some light on how/why running the same Java apps in a docker container significantly increased the memory footprint? Is JVM overhead shared when multiple Java apps are being run on the same machine?

A lot of it is, yes. The JVM loads a large number of largeish class files when it starts; these contain implementations of the standard library and whatever else is on your classpath that you've imported. These have the nice property that they're read-only, though, so multiple JVM processes can safely share them. When you move to sandboxing each JVM off by itself, you lose the ability for them to share memory (which is, in a sense, a _feature_ of sandboxing), so now each of them has to take the 50-100MB hit of those formerly-shared memory regions.

(Note that the huge size of the classes is also the big reason why JVM startup time is so crap; another reason that multitenant JVM systems are great is that every process after the first starts much faster)

Re: A little Golang way

#49

Post by [deleted] »

omginternets wrote: post #38
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 think Go invites comparison to dynamically typed languages because it's compiler is so damn fast. Yes, Go is technically compiled, but the development cycle is closer to that of dynamic languages. In a similar vein, I have a lot of trouble taking criticism of Go's type system seriously. Is it as robust as Rust's? Probably not (I've never used Rust), but that's way beside the point. Go's type system gives you a grea…

[deleted]

Re: A little Golang way

#50

Post by aikah »

_JamesA_ wrote: post #44

Java's main feature is compile once - run (almost) anywhere. From embedded to mainframe as long as a JVM is available. How does Go stack up for cross-platform development? Does every application and library have to be (re)compiled for the target platform? What about support for alternative architectures (ARM, PowerPC, etc)?

AFAIK Go support cross-compilation for multiple targets... as long as one isn't linking C libraries.
Post reply on HN