121–130 of 213 posts
Improved type inference
...
let foo: seq[(float, byte, cstring)] = @[(1, 2, "abc")]
Earlier quoted context omitted.
There's no unwrapping any pointers or boxes or what-not That doesn't happen by default in C++ either. std::vector some_seq{1, 2, 3, 4, 5, 7};
or even just std::vector some_seq{1, 2, 3, 4, 5, 7}; nowadays (for a value of nowadays that is 5 years old for GCC and 6 years old for Clang)
Been happily crunching away at Nim in production. I'm working on what is mainly a data analysis and report generation tool, compiled as a CLI executable that gets called by server scripts. Nim makes fast, small executables. It has an excellent heterogenous JSON data structure and a good dataframe library. It prefers the stack so strongly that dynamic data structures (sequences and tables, basically its lists and dict…
You have convinced me to look in to Nim! Can you speak to the build system(s)? CMake is the bane of my existence.
You can also compile C projects with Nim like bearssl [1]. Nim takes care to compile the C files and recompile them when config flags change. It's actually really nice.
1: https://github.com/status-im/nim-bearssl/blob/99fcb3405c55b2...
Earlier quoted context omitted.
For Rust at least one can use https://github.com/arnetheduck/nbindgen
that looks interesting, thanks! Did you try it if it delivers on promises? There was not any new commit since 2020 so not sure if the project is stale by now.
As someone who doesn't know much about Nim: Improved type inference ... let foo: seq[(float, byte, cstring)] = @[(1, 2, "abc")] This looks like a normal type declaration to me, why is there any inference involved?
Previously Nim didn't do any "reverse" type inference so you'd need to say `@[1'f64, 2'byte, "abc")]`. That was because it's a constraints problem that can become exponentially expensive to solve. Exploding compile times in Rust and Swift are good examples of this. But there's limited subsets which can still be quick and are helpful like this case.
It seems almost too good to be true. Well done! Could someone share some bad experiences when adopting Nim so I can weight that in? I'm seriously considering it.
I have a shortlist of pain points: - Tooling is not great. The language server has a tendency to silently crash on occasion, and it's no rust-analyzer to begin with. A tooling rewrite has been delayed behind proper incremental compilation, which has been delayed behind ARC/ORC... - Interfaces ("concepts") are experimental and there are two differing implementations. - It lacks proper sum types and structural pattern…
We've talked about this before! You know it has sum types, just not the variation you want.
Looking forward to trying out this release! After programming professionally for 25 years, IMO Nim really is the best of all worlds. Easy to write like Python, strongly typed but with great inference, and defaults that make it fast and safe. Great for everything from embedded to HPC. The language has an amazing way of making code simpler. Eg UFCS, generics, and concepts give the best of OOP without endless scaffoldin…
To be fair, I did have to spend like 2 hours tuning my ESP32 code for handling a 22 kSPS ADC where microseconds matter. ;) Mostly just to avoid extra allocations as I was pretty new to Nim at the time.
Ah, but no major regressions in performance or changes needed for ~4 years!
As someone who doesn't know much about Nim: Improved type inference ... let foo: seq[(float, byte, cstring)] = @[(1, 2, "abc")] This looks like a normal type declaration to me, why is there any inference involved?