3 ms·

Nim has hygienic AST macros, so it has really good metaprogramming capabilities. An example of the sort of thing you can do with it: use pattern matching to imp

by _dain_ 5y ago

Nim has hygienic AST macros, so it has really good metaprogramming capabilities. An example of the sort of thing you can do with it: use pattern matching to implement a functional programming DSL: https://nim-lang.org/blog/2021/03/10/fusion-and-pattern-matching.html https://nim-lang.org/blog/2021/03/10/fusion-and-pattern-matc... This makes it really easy to reduce boilerplate and create low- or 0-cost abstractions for your problem domain. Example of this done in a microcontroller project here: https://www.youtube.com/watch?v=j0fUqdYC71k https://www.youtube.com/watch?v=j0fUqdYC71k Async/await is also implemented by metaprogramming, rather than as a "core" part of the language: https://www.youtube.com/watch?v=i0RB7UqxERE https://www.youtube.com/watch?v=i0RB7UqxERE Unrelated to the above, Nim also compiles to Javascript. So you can use the same language for both the backend and frontend.

kgeist 5y ago
>use pattern matching to implement a functional programming DSL DSLs have some use cases but generally I'd avoid being too clever and creating basically entire sublanguages for the sake of it - unless I really need to. Most projects don't need it, it's harder to pick up for novices (especially if there's a zoo of DSLs, different between projects). In Go the last resort is usually code generation, there are built-in tools for it. >Async/await is also implemented by metaprogramming, rather than as a "core" part of the language I guess most programmers don't really care if a feature is implemented in the language or in the library, provided it's easy to use. In Go, it's not extendable however; but so far, I've never had a need to extend the default goroutine scheduler. >Unrelated to the above, Nim also compiles to Javascript. So you can use the same language for both the backend and frontend. Go can be compiled to WASM, but practically I've never seen code that could be reused between backend/frontend because they solve different problems using different principles, so the idea of using one language for frontend/backend was never compelling to me. Maybe it's just me.

by _dain_ 5y ago

kgeist 5y ago

>use pattern matching to implement a functional programming DSL DSLs have some use cases but generally I'd avoid being too clever and creating basically entire sublanguages for the sake of it - unless I really need to. Most projects don't need it, it's harder to pick up for novices (especially if there's a zoo of DSLs, different between projects). In Go the last resort is usually code generation, there are built-in tools for it. >Async/await is also implemented by metaprogramming, rather than as a "core" part of the language I guess most programmers don't really care if a feature is implemented in the language or in the library, provided it's easy to use. In Go, it's not extendable however; but so far, I've never had a need to extend the default goroutine scheduler. >Unrelated to the above, Nim also compiles to Javascript. So you can use the same language for both the backend and frontend. Go can be compiled to WASM, but practically I've never seen code that could be reused between backend/frontend because they solve different problems using different principles, so the idea of using one language for frontend/backend was never compelling to me. Maybe it's just me.