I sincerely hope Nim will pick up more steam. I find it quite enjoyable and a good jack of all trades. You can literally write anything in Nim, in a reasonable amount of time while having decent performance if you have good libraries, frameworks and documentation.
Nim 1.6.2
21–30 of 162 posts
Re: Nim 1.6.2
#22Genuinely curious - why should I care about Nim? There are already a plethora of general purpose languages (both compiled and interpreted). Also, is anyone using Nim today? What's the adoption?
Fast as C, slick as Python. Highly productive with great performance.
Re: Nim 1.6.2
#23Earlier quoted context omitted.
I was a interested in Nim until I learned that getBlochenAngle and get__B_L_O_C_H_E_N_ANGLE are the same identifier. > https://nim-lang.org/docs/manual.html#lexical-analysis-ident...
Agreed. First world problem, though I've tried couple of times to get into nimlang, but this feature is such an anti-pattern (anti-feature) that it drove me crazy. I could not easily and reliably grep/search anything. Not to mention that reading code requires extra mental overhead (especially being new to the language), that `getAttr`, `get_attr`, etc., are actually the same thing. Why this was implemented into the l…
Try nimgrep: https://nim-lang.org/docs/nimgrep.html
If you install Nim with choosenim[+], nimgrep will be available in ~/.nimble/bin along with the compiler, nimble, and some other helpful executables.
Re: Nim 1.6.2
#24Genuinely curious - why should I care about Nim? There are already a plethora of general purpose languages (both compiled and interpreted). Also, is anyone using Nim today? What's the adoption?
Of the current crop of new(ish) systems languages, it’s the one that feels most fun to me. It reminds me of Ruby, not necessarily technically (obviously there’s Crystal for that), but in the sense that it’s a breath of fresh air coming from more austere languages.
I wouldn’t make a career or company bet on it (compared to Rust which I think is a very sensible choice) but I’m always keen to noodle away at new hobby projects in Nim.
Re: Nim 1.6.2
#25other interesting activities going on currently in the nim space:
- advent of nim (advent of code with nim): https://forum.nim-lang.org/t/8657#56695
- call for participation to FOSDEM: https://forum.nim-lang.org/t/8671
Re: Nim 1.6.2
#26Genuinely curious - why should I care about Nim? There are already a plethora of general purpose languages (both compiled and interpreted). Also, is anyone using Nim today? What's the adoption?
For me it's the intersection of performance like Rust, the readability like Python, the ability to generate native executables without dependencies like Go and a very cool type system. All while delivering fast compile speeds! The adoption isn't like Rust and Go, but Nim is growing: https://github.com/nim-lang/Nim/wiki/Organizations-using-Nim and the community is active across all socials. Some downsides: not a big e…
> performance like Rust
I've just looked at some benchmarks, and even though Nim claims C-like performance, that never seems to be confirmed by independent tests. It is usually a bit behind C / C++ / Rust / Crystal, and roughly on-par with Golang.
Fast enough for sure, but "half the speed of C" would be more honest it seems?
Re: Nim 1.6.2
#27Earlier quoted context omitted.
I was a interested in Nim until I learned that getBlochenAngle and get__B_L_O_C_H_E_N_ANGLE are the same identifier. > https://nim-lang.org/docs/manual.html#lexical-analysis-ident...
My personal blocker is that identifiers are all imported globally by convention, so when you see that there is a call to a method called "get", you have to get to the top of the file or mouse over the call to see what lib it is from. A "get" from the http lib is not the same as a "get" from the kv store lib.
There is some logic as to why that is. Here [1] is an explanation for why it makes sense but the tldr is that you don't want to be manually importing functions such as `$` and `+`. In languages like Python, those are defined as methods on the object being imported (e.g. `.__str__()`) so they come along for free. Not so in Nim. If there's a conflict (same name, same signature), the compiler will warn you but it's extremely rare.
Re: Nim 1.6.2
#28Earlier quoted context omitted.
I was a interested in Nim until I learned that getBlochenAngle and get__B_L_O_C_H_E_N_ANGLE are the same identifier. > https://nim-lang.org/docs/manual.html#lexical-analysis-ident...
Indeed I too find this off-putting. I understand the rationale behind it, but developers are used to extreme attention to detail, and this discards an important aspect of detail in the important area of naming.
>It allows programmers to mostly use their own preferred spelling style, be it humpStyle or snake_style
It's interesting that some languages, like Go, are specifically designed to avoid it (there's a built-in formatting tool for a single coding convention), while in other languages having a zoo of different styles is viewed as a great idea and the language is designed for it. Or is it about linking with existing C libraries? In that case, I'd introduce some sort of name mapping via attributes/annotations as a whitelist, instead of allowing this behavior by default.
Re: Nim 1.6.2
#29Earlier quoted context omitted.
For me it's the intersection of performance like Rust, the readability like Python, the ability to generate native executables without dependencies like Go and a very cool type system. All while delivering fast compile speeds! The adoption isn't like Rust and Go, but Nim is growing: https://github.com/nim-lang/Nim/wiki/Organizations-using-Nim and the community is active across all socials. Some downsides: not a big e…
> performance like Rust I've just looked at some benchmarks, and even though Nim claims C-like performance, that never seems to be confirmed by independent tests. It is usually a bit behind C / C++ / Rust / Crystal, and roughly on-par with Golang. Fast enough for sure, but "half the speed of C" would be more honest it seems?
Maybe so, but sometimes benchmarkers forget to employ compiler options like:
nim c -d:danger -d:lto --opt:speed
https://nim-lang.org/docs/nimc.html
Also, --gc:arc and --gc:orc are going to bring a stronger game to the table as they continue to mature (already pretty far along).
Re: Nim 1.6.2
#30Genuinely curious - why should I care about Nim? There are already a plethora of general purpose languages (both compiled and interpreted). Also, is anyone using Nim today? What's the adoption?
If I would pick one, I would pick Zig.
The language that is missing is a simple language that can work well with C or C++, compiles fast, is easy to read, has a good lib, etc.
There are not enough non-GC languages that are statically compiled.
I really, really want a pythonic, statically compiled language. I don't want templates, OOP, abstract stuff, just A C-like language, more readable, with good syntactic sugar. My dream is that there would be as much time money and effort spent on python, than was spent en js engine like v8 and spidermonkey.
There are barriers that make python not really viable everywhere, and I wish it would not be the case.