Hi all,
My first post to this forum. I found out about Nim a month or so ago and have been playing around since. It's been a very pleasant experience, with Nim's clean syntax (especially coming recently from Python) and friendly learning curve.
A big shout-out to the developers and the Nim community, you are doing a great job and if you keep going more great things will lie ahead.
I'll also take the opportunity to share my first Nim project - grim. It brings graph data structures to Nim, similar to the Neo4j-style database. Probably there are similar libraries already available, this is my attempt to learn Nim. I'll happily discuss improvements and or PRs. In the future, if I have time, I hope to add graph searching tools and other cool graph algorithms + Neo4j integration.
Best,
Thanks Erik for this lib. I'm curious why you store node attributes in heterogenous table. In compiled language i expect graph to be a generic with custom Node and Edge types known at compile time, smth like
var g = newGraph[MyNodeType, MyEdgeType]()
The short answer is probably that I've probably been exposed to too much Python over the last years... The longer answer is that I am thinking of a much more general data structure than a graph of ints, or floats, or any other single type. One where general data can be stored and searched efficiently, leveraging modern graph theory for performance. (Not there yet, though...)
Regarding the Object vs ref Object it may be a misunderstanding of the concepts from my side... I was thinking of the ref as a shared data structure and the object as being copied around. For performance, I imagined that having one ref on the heap was better than copying data on the stack. But I could be wrong here, and I am glad to be enlightened by someone with more Nim experience.
Thanks for the feedback.