ezno
libclc
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.
ezno
- Ezno's checker (Rust based type checker and compiler) is now open source
- Ezno's checker (a Javascript type checker and compiler written in Rust) is now open source
- Ezno: A TypeScript checker written in Rust
- Show HN: Ezno, a TypeScript checker written in Rust, is now open source
-
Ask HN: What is new in Algorithms / Data Structures these days?
> I'm curious if there are any practical reasons we don't see them implemented in more languages.
I believe it's because they're not exactly easy to implement and the resulting extensive type checking might also affect compiler performance.
By the way, another great example of refinement types (in JavaScript) is this one: https://kaleidawave.github.io/posts/introducing-ezno/
- Open sourcing Ezno – JavaScript compiler and TypeScript checker written in Rust
libclc
-
Ask HN: What is new in Algorithms / Data Structures these days?
This is something I planned (2015) on sharing at some point but then years flew by and here we are .. :}
It is a cacheline sized 'container' (CLC) of machine-word length records, with one record used to store the record order and remaining bits for metadata. So you can project different kinds of container semantics, such as FIFO or LRU -- any ordered set semantics -- on this meta record. Using arrays of CLCs you can create e.g. a segmented LRU, where the overhead per item is substantially less than a conventional pointer-based datastructure, and, is naturally suited for concurrent operations (for example by assigning a range to distinct worker threads), and ops require a few or couple of lines to be touched. The LRU (or whatever) semantics in aggregate will be probabilistic, as the LRU order is deterministic per unit container only. It is very fast :)
https://github.com/alphazero/libclc/blob/master/include/libc...
https://github.com/alphazero/libclc/blob/master/include/libc...
As for the non-deterministic aspects: Since container semantics e.g. LRU order is only applied at unit level, the overall cache is ~LRU. We can strictly quantify the 'ordering error' by observing the age of items in FIFO mode as they are removed: for a deterministic container the age of the item is equal to the total capacity of the queue, for a segmented (array) composed of FIFO queues, the age will have a effectively gaussian distribution around the capacity (number of units x unit capacity). But since these containers can use as few as 9 bits per entry vs 24 or more bytes for pointer based solutions (which use linked-lists), for the same allocation of memory, the capacity of the array of CLCs will be much greater, so, the distribution tail of 'short-lived' items will actually be longer lived than items in a strict queue for the same exact memory. Additional techniques, such as n-array hashing, and low order 'clock' bits at container level, can tighten this distribution significantly (i.e. ~LRU -> LRU) via better loading factors.
What are some alternatives?
highfleet-ship-opt - A c/c++ module and python extensions for automatic optimization of Highfleet ship modules. Try it live at https://hfopt.jodavaho.io
stc - Speedy TypeScript type checker
clingo - 🤔 A grounder and solver for logic programs.
rfcs - RFC process for Bytecode Alliance projects
egglog - egraphs + datalog!
flix - The Flix Programming Language
ann-benchmarks - Benchmarks of approximate nearest neighbor libraries in Python
peritext - A CRDT for asynchronous rich-text collaboration, where authors can work independently and then merge their changes.