norm
questionable
Our great sponsors
| norm | questionable | |
|---|---|---|
| 3 | 3 | |
| 367 | 113 | |
| - | 4.4% | |
| 7.9 | 7.0 | |
| 3 months ago | 9 days 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.
norm
-
Nim v2.0 Released
Congratulations to everyone involved and the entire Nim community!
Nim has been my language of choice for the past decade and I'm really happy with the new features in Nim 2.0. Some of them are real gamechangers for my projects. For example, default values for objects theoretically allow me to make Norm[1] work with object types along with object instances. And the new overloadable enums is something Karkas [2] wouldn't be possible at all (it's still WIP though).
[1] https://norm.nim.town
[2] https://karkas.nim.town
-
Nim Version 1.6 Released
In the ORM field, Norm[1] is an actively maintained package that supports SQLite and Postgres. It's framework agnostic, I've used it with Jester and Prologue (it had nothing to do with Prolog btw).
Among frameworks, Prologue is the most actively developed and feature rich.
[1] https://norm.nim.town
-
Invisible DB Driver / ORM without a single cool feature [experiment]
[1] https://norm.nim.town
questionable
-
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.
-
Stop Building on Corporate-Controlled Languages
If exceptions aren’t your cup of tea, look into using stew/results and questionable instead:
https://github.com/status-im/nim-stew/blob/master/stew/resul...
https://github.com/status-im/questionable#readme
Re: std/db_sqlite, your probably better off using sqlite3_abi:
https://github.com/arnetheduck/nim-sqlite3-abi#readme
What are some alternatives?
prologue - Powerful and flexible web framework written in Nim
pekko - Build highly concurrent, distributed, and resilient message-driven applications using Java/Scala
httpbeast - A highly performant, multi-threaded HTTP 1.1 server written in Nim.
nim-chronos - Chronos - An efficient library for asynchronous programming
godot-nim - Nim bindings for Godot Engine
owlkettle - A declarative user interface framework based on GTK 4
jester - A sinatra-like web framework for Nim.
v - Write Nim only with 'v'
vscode-nim
sokol-rust - Rust bindings for the sokol headers (https://github.com/floooh/sokol)
INim - Interactive Nim Shell / REPL / Playground
sokol-zig - Zig bindings for the sokol headers (https://github.com/floooh/sokol)