3 ms·

Care to give a brief overview of what you find appealing? I've never looked into the language before.

davidkunz 4y ago
Other comments already gave great examples but for me personally: - Concise syntax - Elegant language constructs (e.g. method call syntax) - Great macro system - You have control over what GC you use - Great performance - Everything is simple, it's easy to read other people's code
frigid 4y ago
I particularly like, from the syntax side: - Python-style syntax with significant indentation - Uniform Function Call Syntax: a.len() == a.len == len(a) - Fully unqualified imports by default: which might seem scary to Python programmers, but works great in practice because of static typing - All of the above makes code readable and succinct And from a language features side: - Compiles to C with all the architectural targets that come with it - Compilation to C also allows for easy C interop: wrap function signatures and types and you're done - This, in turn, means that Nim libraries can bootstrap off of the massive C ecosystem, while adding nicer APIs on top - Extremely performant GC by default: optional Rust-style annotations can further improve performance, and you can remove all overhead and manually manage memory with C-style pointers if you'd like - Useful compile-time templates and macros that can directly change the AST The community is also active and helpful on IRC/Matrix/Discord/Gitter (bridged together)
- frigid 4y ago
  One really important thing I forgot to mention is how extendable Nim is - first class support for macros and AST manipulation is very powerful. This cuts back significantly on the amount of functionality that needs compiler magic. So you'll see alternative (or new) implementations of core language features like async, threading, DSLs, typeclasses, traits, etc available as external packages, with just about the same user experience as if they were built into the stdlib or compiler.
- vegai_ 4y ago
  >- Uniform Function Call Syntax: a.len() == a.len == len(a) a.len() == len(a) seems like a good idea, but I'm not so sure about a.len... Isn't that a bit ambiguous?

Other comments already gave great examples but for me personally: - Concise syntax - Elegant language constructs (e.g. method call syntax) - Great macro system - You have control over what GC you use - Great performance - Everything is simple, it's easy to read other people's code

frigid 4y ago

I particularly like, from the syntax side: - Python-style syntax with significant indentation - Uniform Function Call Syntax: a.len() == a.len == len(a) - Fully unqualified imports by default: which might seem scary to Python programmers, but works great in practice because of static typing - All of the above makes code readable and succinct And from a language features side: - Compiles to C with all the architectural targets that come with it - Compilation to C also allows for easy C interop: wrap function signatures and types and you're done - This, in turn, means that Nim libraries can bootstrap off of the massive C ecosystem, while adding nicer APIs on top - Extremely performant GC by default: optional Rust-style annotations can further improve performance, and you can remove all overhead and manually manage memory with C-style pointers if you'd like - Useful compile-time templates and macros that can directly change the AST The community is also active and helpful on IRC/Matrix/Discord/Gitter (bridged together)

frigid 4y ago
One really important thing I forgot to mention is how extendable Nim is - first class support for macros and AST manipulation is very powerful. This cuts back significantly on the amount of functionality that needs compiler magic. So you'll see alternative (or new) implementations of core language features like async, threading, DSLs, typeclasses, traits, etc available as external packages, with just about the same user experience as if they were built into the stdlib or compiler.
vegai_ 4y ago
>- Uniform Function Call Syntax: a.len() == a.len == len(a) a.len() == len(a) seems like a good idea, but I'm not so sure about a.len... Isn't that a bit ambiguous?