mummy
nim-results
| mummy | nim-results | |
|---|---|---|
| 7 | 1 | |
| 255 | 137 | |
| - | - | |
| 8.4 | 6.9 | |
| 7 days ago | about 2 months ago | |
| Nim | Nim | |
| MIT License | GNU General Public License v3.0 or later |
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.
mummy
- Nim v2.0 Released
- Mummy – web server written in Nim that returns to the ancient ways of threads
-
Nim version 2.0.0 release candidate
Personally this preciseness is just a distraction, but it sounds like you have learned from the constraints and can now take the training wheels off again.
Very curious about those cases, yet to find one myself that was not because of a bad design decision. Though I am also very big on the idea of `ambiguous grammar, rigorous implementation`, for natural language too. (Toki Pona is a somewhat extreme example but the contextual grammar, and holistic minimalism is fascinating)
Not to make it longer than needs to be; But take the example code in this readme: https://github.com/guzba/mummy
Being able to quickly script this without thinking about cases or style on the first pass is a really lovely way of reducing friction imho.
-
Mummy, a new multithreaded HTTP + WebSocket server that returns to the ancient ways of threads
Added a WebSocket chat example here: https://github.com/guzba/mummy/blob/master/examples/chat.nim
nim-results
-
Nim v2.0 Released
> You can also not really have productive and well-fitting errors-as-values in a language that emphasizes UFCS
Eh, https://github.com/arnetheduck/nim-results and associated syntax from https://github.com/codex-storage/questionable would beg to disagree. Nim's stdlib does not have productive and well-fitting errors because it suffers from inertia and started far before the robust wonders of recoverable error handling via errors-as-types entered the mainstream with Rust (IMO: and refined with Swift). Option/Result types are fantastic and I do so wish the standard library used them: but it's nothing a (very large) wrapper couldn't provide, I suppose.
I do strongly think that other languages are greatly missing out on UFCS and I miss it dearly whenever I go to write Python or anything else. I'm not quite sure how you think UFCS would make it impossible to have good error handling? Rust also has (limited, unfortunately) UFCS and syntax around error handling does not suffer because of it. If by errors-as-values you mean Go-style error handling, I quite despise it - I think any benefits of the approach are far offset by the verbosity, quite similarly to Java's checked exceptions.
What are some alternatives?
nim-chronos - Chronos - An efficient library for asynchronous programming
RFCs - A repository for your Nim proposals.
fungus - Object variants done like other langugaes
jester - A sinatra-like web framework for Nim.
nimpy - Nim - Python bridge
owlkettle - A declarative user interface framework based on GTK 4
nimbus-eth2 - Nim implementation of the Ethereum Beacon Chain
mvb-opencv - Minimum Viable Bindings to OpenCV for Nim
rust - Empowering everyone to build reliable and efficient software.
sokol-rust - Rust bindings for the sokol headers (https://github.com/floooh/sokol)
norm - A Nim ORM for SQLite and Postgres