[HN Gopher] Go Primitive in Java, or Go in a Box
___________________________________________________________________
Go Primitive in Java, or Go in a Box
Author : ingve
Score : 65 points
Date : 2025-10-25 20:46 UTC (8 days ago)
(HTM) web link (donraab.medium.com)
(TXT) w3m dump (donraab.medium.com)
| gethly wrote:
| FYI this has nothing to do with the Go language :)
| jonhohle wrote:
| Thr article doesn't mention GNU Trove, which has addressed this
| use case. Trove has been around so long it's homepage is still on
| Soureforge.
| rzzzt wrote:
| I have a few more primitive collection libraries in my bag if
| someone would like to shop around:
|
| - PCJ: https://pcj.sourceforge.net/
|
| - fastutil: https://github.com/vigna/fastutil
|
| - HPPC: https://labs.carrotsearch.com/hppc.html
|
| PCJ was last updated in 2003 and is now quite long in the tooth
| though.
| clanky wrote:
| Thanks, I've mostly used fastutil lately because it seems to
| be best maintained. I'll have to look at carrotsearch labs
| though, I like the approach of a clean break with
| java.util.collections.*.
|
| The Agrona Java library from the Aeron people has some
| primitive optimized collections too:
| https://github.com/aeron-io/agrona
| nchmy wrote:
| Am I wrong to have expected this to be about using Golang in
| Java, in some way?
| floodfx wrote:
| Had same expectation and read through half the article before
| realizing it was not Golang related.
| henvic wrote:
| Go, not Golang.
| wavelen wrote:
| Golang is called Go, though. "The Go Programming Language".
| So I see how in a programming-related blog post people can
| get confused by the word Go.
| c2xlZXB5Cg1 wrote:
| Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo
|
| https://en.wikipedia.org/wiki/Buffalo_buffalo_Buffalo_buffal...
| AtlasBarfed wrote:
| It's a stupid language name. You are correct.
|
| I look forward to my next programming language ,"the"
| itronitron wrote:
| I think you could get more attention to it by calling it
| "Al", short for "A language"
| p2detar wrote:
| I guess the title is confusing to non-native speakers,
| especially the part after the comma.
| itronitron wrote:
| It's especially confusing for native English speakers because
| 'go' should only be capitalized when it's the first word in
| the sentence or being used as the name of something (such as
| the Go programming language)
|
| And it's also confusing why people keep posting walled off
| articles on HN.
| nchmy wrote:
| I'm a highly literate native speaker...
| kristianp wrote:
| Yes, "Go in a box" isn't exactly idiomatic english usage, in
| addition to the capitalisation mentioned be a sibling.
| wjholden wrote:
| Year ago I wrote a very simple SAT solver in Java. I initially
| used List but later primitive arrays to represent my formulas and
| clauses. The change made a modest and measurable difference, but
| I agree with the author's suggestion that if you don't already
| care about the difference in boxed and primitive performance then
| you're likely fine using the standard Java collections.
| clanky wrote:
| Looking forward to when Valhalla and generics specialization
| obviates these concerns -- but, every time I watch a presentation
| by Remi Forax he makes a joke or remark about what a hard problem
| it is and how long it will take. (Hope this doesn't get him in
| trouble!) https://youtu.be/JI09cs2yUgY?si=WBiXRpnir9HhNNfK
| marginalia_nu wrote:
| > I could show you benchmarks and memory savings of using
| primitive collections instead of boxed collections. If you need
| to see these to be convinced of the benefits of primitive
| collection support in Java, then you probably don't need support
| for primitive collections in Java. No need to read any further.
| Please accept this complimentary set of eight boxes for your
| collection travels.
|
| This is intellectually lazy. The performance characteristics of
| boxed vs unboxed primitives isn't forbidden knowledge from the
| necronomicon that only the select few are ready to partake in.
| Even if you think it's obvious, if you can back up an argument,
| go back up that argument. It makes your case stronger, it shows
| you know what you are talking about.
|
| If not for other people, do it for yourself. Things that are too
| obvious to bother checking is generally where we're most likely
| to be wrong about things. This is true in life in general but
| it's especially true with the JVM and it's continuously evolving
| performance characteristics.
| vlovich123 wrote:
| I can believe it's less of an issue for primitive smaller than
| long/double where the boxing/unboxing can be hidden through
| tagged values. But long and double specifically will always end
| up larger and slower. But the JVM doesn't do this - instead it
| caches boxed representations of -128 to 128, true and false.
| This means any collection of not Boolean and not short/char
| will inherently at least use much more ram and have overhead
| accessing it.
| marginalia_nu wrote:
| That's a good start that explains some of the memory overhead
| (along with the sizable Java object header), but we also need
| to take into account memory locality to explain why this is
| so much slower.
|
| Main memory access is at worst case order of 100x slower than
| a cached read. With boxed primitives you very often looking
| and main memory access, whereas naked primitives can (when
| the planets align) amount to cached memory access.
| cyberax wrote:
| Tagged pointers don't buy as much performance as you'd expect
| in Java. That's because the JVM is highly multithreaded, and
| the Java memory model guarantees memory safety (unlike in Go,
| for example). So every pointer load from RAM will need a
| check for the tag bits. And you end up with your code full of
| branches.
|
| From practical experience, JVMs have had an option to use
| compressed pointers for inner fields for two decades (
| https://wiki.openjdk.org/display/HotSpot/CompressedOops ). It
| saves a bit of RAM, but often results in slower code.
|
| More recently, the new ZGC collector started using colored
| pointers, there's a good presentation about it:
| https://inside.java/2025/10/06/jvmls-zgc-colored-pointers/
| It's also been a mixed bag, performance-wise.
| jbellis wrote:
| This is extremely well trodden ground, and he's right. The
| world doesn't need him to spend time explaining that water is
| wet.
| msgilligan wrote:
| And I think he's also acknowledging that not everybody has an
| application that needs these performance optimizations.
| citizenpaul wrote:
| I have an unpopular opinion. I simply do not read anything on
| medium anymore. I in fact have a ublock rule that blocks the
| site so I do not accidentally go there or give them traffic
| anymore.
|
| I saw go in the title so I just checked the HN comments
| first.
| brabel wrote:
| > Maybe you can afford to wait for Project Valhalla to arrive and
| finally build the applications and libraries you really want to
| build
|
| Or just use one of many languages that support generics over
| primitive types right now?! I get it, I also write Java but if
| some application would benefit greatly from some feature another
| language has, I don't really think too much about it. Having a
| few languages under your belt is really good, and most companies
| these days know that and have at least a couple of "approved"
| languages. People normally can learn a new language fairly
| quickly. With AI now it's easier than ever.
| clanky wrote:
| It's not really possible to switch to another language without
| giving up one or more of:
|
| - Free, high quality concurrent GC
|
| - Advanced JIT with best-in-class runtime optimization of
| dynamic dispatch and virtual methods
|
| - Depth of the Java ecosystem and tooling
|
| I've written some fairly large applications where I dropped in
| these primitive-specialized collections when needed, it really
| presented no issues and was quite a bit simpler than a leap to
| an entirely new language and runtime. They can be composed
| fairly easily into AoS style data structures.
|
| To be honest the bigger headache from the current lack of value
| types comes from not being able to work with more involved
| temporary objects without the JIT giving up on escape analysis
| and putting them on the heap, which requires putting hacky
| approximations of out params in local fields. I'm optimistic
| this is going to be one of the earlier optimizations delivered
| by Valhalla.
| adgjlsfhk1 wrote:
| C#?
| pron wrote:
| You can start trying the first part of Project Valhalla today
| (with a ready-made JDK build):
| https://inside.java/2025/10/27/try-jep-401-value-classes/
|
| No specialised generics at first, and this "beta" Early Access
| flattens only tiny objects on the heap, but changes to both will
| come later. Most of the foundation is there.
| tofflos wrote:
| Eclipse Collections also comes with an API that seems nicer than
| the one provided by the standard library - so it might be worth
| checking out even if you're not interested in primitives.
| aatd86 wrote:
| And here I was, wondering if it was about embedding go in a java
| program... ahah.
| Sharlin wrote:
| > For better or worse, we've had them in Java for over 30 years.
|
| Just in case someone wants to feel old. C was younger when Java
| 1.0 was launched than Java is now.
| itronitron wrote:
| Also worth mentioning the Cern Colt API...
|
| https://dst.lbl.gov/ACSSoftware/colt/
|
| https://en.wikipedia.org/wiki/Colt_(libraries)
|
| https://link.springer.com/chapter/10.1007/978-1-4302-0854-9_...
___________________________________________________________________
(page generated 2025-11-02 23:01 UTC)