top | item 9670413

(no title)

waps | 10 years ago

2 things play in favor of Go on memory usage though:

1) Go is in honeymoon phase. There aren't any 10 million plus lines of code Go codebases. So "Go is not complex".

That said in java-land there is often not a very good reason for complexity. I just examined a GWT job scheduling tool and for displaying fields in the UI they had 5 interworking classes - just to avoid manually coding the dialog. In java-land people constantly do that - why ? They had recordbuilders and ui-from-record-builder and ...

That said, these days you see people using Go's introspection to create dialogs in javascript - that was a lot more complex still.

So while the length of backtraces in Go's crashes has been steadily going up, it seems to be at around 6-8 levels deep these days. I have to say though, I much prefer panics and exceptions over Go's error handling (or as you will come to see it after seeing what "average" programmers do with the errors - Go's error ignoring)

This honeymoon also means the amount of idiot-written code in Go is much smaller than in Java. Also, a lot of code in java was written to the previous sets of programmer fancies. Half the libraries you use in a particular project are XML configured, because that was the best practice in 2000-2005 (even still visible in things like android apps), another set is using dependency-injection patterns, another set requires POJOs and uses introspection, and the last set has it's own custom configuration language (I hate gradle, and yes this is because just doing things with cli tools is apparently not done in java-land, I don't care).

2) Go has a better memory model than Java. Because you can nil out every java object, every java object has to be a pointer. So initializing an object that contains 5 other objects requires 6 heap allocations and constructor invocations - minimum. After construction the GC has a new tree of 6 objects to walk on every invocation.

This is not the case in Go (uninitialized non-pointer objects aren't nil, you only use pointers where you actually need them), and results in much more compact memory. I see it as a flaw in java these days.

discuss

order

No comments yet.