Hi folks,
I am Java dev who depends on Java collection heavily. I ported Eclipse Collections to Zig, it is about 500 files with most features from EC. It passes tests, performance is ok. I would like to talk with someone, who has Java,Scala or Kotlin exposure and is experienced with Zig, before I publicly release this.
Thanks
1 Like
Sounds like a mountain of workā¦ I have a hard time imagining how Java collections would work on Zig. Feels a bit antithetical (if this is a word). Would be really curious to see that though.
I did a lot of work in Java, in recent times more Kotlin. But when working with Zig my mindset completely changes from abstraction seeker to bit pusher. I enjoy both but mixing them feels like quite a feat of mental acrobatics.
5 Likes
Converting the code was easy part. I already had harness for Golang port, and it worked on Zig quite well (good type system). Hard part is to make it usable on Zig, Now it uses unmanaged arrays and error handling is bad.
Is there a way to contact you? Drop me DM at twitter handle, or email jan at kotek net
How well do you know Zig? How would you describe your experience level with it?
From the sounds of it, you just used AI to generate a ~500 file project with a minimal understanding of the language, and are now asking for others to review it in order to make it usable? My sincere apologies if that is inaccurate, but that is what I am gathering so far, hence I am a bit taken back by audacity of the request.
6 Likes
Not much, just learning. My background is in JVM and data structures.
Yes, it is machine translation. But it took some time.
I am not asking to review 500 files of code. I can do that myself. I need to understand what is actually needed. So I am asking for someone to discus this stuff with.
In Java we just mostly crash program if memory allocation fails, Zig handles this very differently. But there are many options, like overflowing to swap file.
1 Like
zig lets you choose! you can crash the program if you want, in some domains thats the better option or even needed.
instead of translating over java collections, implement stuff as you need them.
If youāre wanting to make a library for others, ask them directly. That should be a new topic and in the Brainstorming category.
1 Like
I believe you would have a better reception if you āsoft launchedā your collections and solicited public feedback, rather than trying to lure specific people off-site for a private discussion.
Thatās what we do here, look at code and talk about it. Perhaps a few representative examples? 500 types is a lot.
Welcome to the forum!
2 Likes
Itās great that you wanted to attempt this. One thing you can do is look closely at interfaces to collection type things in the zig standard library. And then think about what your data structures would be like if they were more conformant to the design patterns present there which demonstrate zig style and idioms.
What was your translation process and what kind of inputs do you steer it with?
1 Like
Welcome to ziggit!
I feel itās worth complementing these comments with this: zig is great at things that other languages arenāt, and of course vice-versa is true. Iāve loved blindly relying on garbage-collection in Python for years, but I would seriously pause if somebody asked me to implement some Python collections in zig, because (besides having to implement GC) Iād feel that Iād lose a lot of the advantages of zig, just making a zig collection API look as close-as-possible to Python. I want zig because I want the things Python canāt do wrt/ memory management and interface ergonomics. Iād fail in other ways, too, because pythonic things (e.g., some operators) are just not available at the language level in zig, and some patterns are not a great fit (usually with some good reason). A lot of basic collections exist in zigās std, and probably do all the āusualā stuff you need, anyway, soā¦. But Iām sure it was hard work, and perhaps the remaining work is exciting for you - great. Keep an open mind, though, to the limitations youāll encounter.
3 Likes
i canāt speak to Java collections, but the conventional way in zig would be to take an allocator as a parameter to the functions that need it. Then your collection doesnāt need to worry about things like swap files or handling OOM, the caller can decide the best way for their use case.
1 Like
The Java collections API is designed around interfaces such as Map, that are implemented by types such as HashMap. This allows swapping out different types that implement Map with miminal changes, i.e., a type of polymorphism.
āPortingā this design to Zig may be impractical. In Zig you would use comptime interfaces, meaning duck typing, for collections since you wouldnāt want the overhead of a vtable indirection. Zig doesnāt have comptime interfaces per se that are part of the language, so these would be largish duck-typed interfaces that would be described in documentation only, not using a language declaration.
In Zig, as far as Iāve seen, it is not a goal to abstract collection interfaces such that they can be swappable/polymorphic. So this may be considered contrary to usual Zig patterns. One reason for this bias is probably that interfaces are not built into the language. You could scrap the interfaces, but then I question the value of porting the design.
2 Likes
As an ex-kotlin dev, moving over to zig was one of the best thingās Iāve done for my dx - build, test, startup, memory, and response times have dropped through the floor from using spring/gradle to zig and httpz.
LLM assistance has been instrumental in my transition for helping me mentally move over from GC and abstraction obliviousness into knowing the true cost of everything I do - and making the tradeoffs obvious.
The mental shift from inheritence to vtables/fatpointer switches and the awe inspiring power of comptime has been eye opening about the costs that I used to pay without thinking. Another part of letting the jvm go is understanding that common crutches, like checked exceptions with payloads and stacktraces donāt exist, errors, yah, but if you care hard about stacktraces and exception payloads, you can get close w/ diagnostic side-channels on a threadlocal or task struct.
However, I would take a moment before blindly converting the collections libs, and think about what you actually want to do, why it might not fit in zigās philosophy or methodology, and maybe, just maybe, getting to know zig enough to make it even more powerful or simple.
Next time you want to reach for the utility of the java collections, ask yourself why, and ask a LLM what the zig of achieving your goal would look like (and why). Youāll find massive dx/runtime speedups and a more aware perspective.
2 Likes