zero-functional VS questionable

Ones that have not been mentioned so far:

nlvm is an unofficial LLVM backend: https://github.com/arnetheduck/nlvm

npeg lets you write PEGs inline in almost normal PEG notation: https://github.com/zevv/npeg

futhark provides for much more automatic C interop: https://github.com/PMunch/futhark

nimpy allows calling Python code from Nim and vice versa: https://github.com/yglukhov/nimpy

questionable provides a lot of syntax sugar surrounding Option/Result types: https://github.com/codex-storage/questionable

ratel is a framework for embedded programming: https://github.com/PMunch/ratel

cps allows arbitrary procedure rewriting to continuation passing style: https://github.com/nim-works/cps

chronos is an alternative async/await backend: https://github.com/status-im/nim-chronos

zero-functional fixes some inefficiencies when chaining list operations: https://github.com/zero-functional/zero-functional

owlkettle is a declarative macro-oriented library for GTK: https://github.com/can-lehmann/owlkettle

A longer list can be found at https://github.com/ringabout/awesome-nim.

Nim's not perfect. Come on, ask me to explain the differences between the not one, not two, not three, not four, NOT FIVE, but seven (at time of writing) garbage collectors you can specify at compile time. Or how to cross-compile a static program using regexes; something I can do without thinking in Go and Rust, but here I have to think about "impureness". Or why you need a third party package for functional programming because the built-in one is inefficient. Spoiler: I can't.

Check this out: https://github.com/zero-functional/zero-functional

> 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.

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