4 ms·
>if we want to start a new project how could we find programmers well-versed in Nim? If a programmer can't pick up a language like Nim in a few weekends (from
by kgeist 5y ago
>if we want to start a new project how could we find programmers well-versed in Nim?
If a programmer can't pick up a language like Nim in a few weekends (from what I gather, it's similar to Python and not much different from most common languages, i.e. not something relatively exotic like Haskell) then I don't know. Our mainly PHP shop transitioned to Go quite effortlessly. Today we hire PHP juniors without any Go experience (easier to find), we teach them, and then they work on Go codebases already after a month of internship. So lack of "professional Nim programmers" doesn't look like a problem to me.
Lack of libraries is a good point but from what I read, Nim compiles to C, so I understand they can have access to tens (hundreds?) of thousands C libraries without writing everything from scratch.
However, indeed, if you are to choose between, for example, Nim and Go for a new project, then I am not sure why would anyone prefer Nim. I'm really interested to know.
- sound1 5y ago> However, indeed, if you are to choose between, for example, Nim and Go for a new project, then I am not sure why would anyone prefer Nim. I'm really interested to know. Same here, curious to know what HN crowd recommends between Nim vs Go for new projects.
- _dain_ 5y agoNim 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.
- DeathArrow 5y agoNim is also faster than Go if we look at most benchmarks. Nim's memory management can be tuned quite a bit. Garbage collector can be even turned off. You can better tune to the underlying hardware if you need to. https://nim-lang.org/docs/gc.html https://nim-lang.org/docs/gc.html
- iamcreasy 5y agoI think it is true for people who have computer science/software engineering or any programming background, but for my statistician/data scientist friends - they skip a bit when they think they might need to learn a different language.