hashmap
query-json
Our great sponsors
| hashmap | query-json | |
|---|---|---|
| 8 | 4 | |
| 1,626 | 574 | |
| - | - | |
| 5.3 | 3.5 | |
| about 2 months ago | over 1 year ago | |
| Go | Reason | |
| Apache License 2.0 | BSD 3-clause "New" or "Revised" License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
hashmap
-
Go 1.20 Released
Glad to see this make it into the core.
I've been using this library for ages now...
https://github.com/cornelk/hashmap
Always entertains me to see developers write all the lock/unlock code when they could just use that.
- Ask HN: Was it worth it for Go to add generics
- Gojq: Pure Go Implementation of Jq
-
HaxMap, a concurrent hashmap faster and more memory-efficient than golang's sync.Map
Assuming it is issue 54 and its age, I am now unsure about the usability.
Pre-allocating would not fix https://github.com/cornelk/hashmap/issues/47 as the bug is in the linked list. This is not grow related but an issue with concurrent Add/Delete on the list.
-
A Go implementation of the concurrency control algorithm in paper <Left-Right -A Concurrency Control Technique with Wait-Free Population Oblivious Reads>
Would be interesting to compare with https://github.com/cornelk/hashmap
query-json
-
Gojq: Pure Go Implementation of Jq
It's very possible it could be faster; jq seems to actually be fairly unoptimized. This implementation in OCaml was featured on HN a while back and it trashes the original jq in performance: https://github.com/davesnx/query-json
After seeing that one I did my own (less-complete) version in Rust and managed to squeeze out even more performance: https://github.com/brundonsmith/jqr
-
query-json: A story of cross-compilation with Reason
query-json is a faster and simpler re-implementation of jq's language in Reason.
There're probably better ways of achieving it since I made the implementation very unsafe davesnx/query-json/js/Js.re.
You can see more examples in the parsing tests
What are some alternatives?
go-left-right - A faster RWLock primitive in Go, 2-3 times faster than RWMutex. A Go implementation of concurrency control algorithm in paper <Left-Right - A Concurrency Control Technique with Wait-Free Population Oblivious Reads>
sonic - A blazingly fast JSON serializing & deserializing library
haxmap - Fastest and most memory efficient golang concurrent hashmap
yojson - Low-level JSON parsing and pretty-printing library for OCaml
js_of_ocaml - Compiler from OCaml to Javascript.
pq - Like jq, but with Python
xxHash - Pure Go implementation of xxHash (32 and 64 bits versions)
immutable-js - Immutable persistent data collections for Javascript which increase efficiency and simplicity.
go - The Go programming language
jsoo-react - js_of_ocaml bindings for ReactJS. Based on ReasonReact.
go-evmap - A Go implementation of Rust's evmap which optimizes for high-read, low-write workloads and uses eventual consistency to ensure that readers and writers never block each other.