Live data from Hacker News

Nim 2.0

nim-lang.org

11–20 of 213 posts

Re: Nim 2.0

#11
post #4

Anyone have working experience with Nim and Zig? I'd love to hear how they are similar and contrast. I'd also would like to see some idiomatic web server benchmarks between the two (now with Nim v2).

Zig doesn’t seem to have an implementation for the TechEmpower Benchmarks but Nim does: https://www.techempower.com/benchmarks/#section=data-r21&l=y...

Nim's should probably be redone with mummy (multi-threaded) and chronos (async single-threaded) for a better showing:

https://github.com/guzba/mummy

https://github.com/status-im/nim-chronos

Re: Nim 2.0

#12
post #4

Anyone have working experience with Nim and Zig? I'd love to hear how they are similar and contrast. I'd also would like to see some idiomatic web server benchmarks between the two (now with Nim v2).

Zig doesn’t seem to have an implementation for the TechEmpower Benchmarks but Nim does: https://www.techempower.com/benchmarks/#section=data-r21&l=y...

And I'm surprised by how terribly it ranks – basically dead last against everything, even the Python frameworks, which is impressive.

Re: Nim 2.0

#14
Nim looks awesome. Does anyone know why it doesn't have first-class support for wasm? That's the only thing that would keep me from diving into it more.

Re: Nim 2.0

#15
post #8

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…

> “It prefers the stack so strongly that dynamic data structures (sequences and tables, basically its lists and dictionaries) are pointers on the stack to heap data, where the lifetime is managed by the stack frame.” Isn’t that the same as a C++ vector or map on stack? They allocate internally as needed, and the whole container is destroyed when it goes out of scope.

Agreed, only being able to put pointers on the stack, no data, would make me think it "prefers the heap".

Re: Nim 2.0

#16

What are some noteworthy projects or libraries written in Nim?

Lots of high-quality Nim projects and libs are being worked on and used by the folks at Status:

https://github.com/status-im/nimbus-eth2

https://github.com/orgs/status-im/repositories?language=nim&...

Re: Nim 2.0

#17
Congratulations to everyone involved and the entire Nim community!

Nim has been my language of choice for the past decade and I'm really happy with the new features in Nim 2.0. Some of them are real gamechangers for my projects. For example, default values for objects theoretically allow me to make Norm[1] work with object types along with object instances. And the new overloadable enums is something Karkas [2] wouldn't be possible at all (it's still WIP though).

[1] https://norm.nim.town

[2] https://karkas.nim.town

Re: Nim 2.0

#18
post #8

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…

> “It prefers the stack so strongly that dynamic data structures (sequences and tables, basically its lists and dictionaries) are pointers on the stack to heap data, where the lifetime is managed by the stack frame.” Isn’t that the same as a C++ vector or map on stack? They allocate internally as needed, and the whole container is destroyed when it goes out of scope.

Basically, but it requires no extra syntax. `var some_seq = @[1, 2, 3, 4]` is a stack-managed sequence. That's all there is to it. There's no unwrapping any pointers or boxes or what-not, the type is just `seq[int]`. Put another way, things that have become best practice in C++ are default in Nim with no syntactic noise.

Re: Nim 2.0

#20

Earlier quoted context omitted.

Zig doesn’t seem to have an implementation for the TechEmpower Benchmarks but Nim does: https://www.techempower.com/benchmarks/#section=data-r21&l=y...

Nim's should probably be redone with mummy (multi-threaded) and chronos (async single-threaded) for a better showing: https://github.com/guzba/mummy https://github.com/status-im/nim-chronos

Why does the stdlib implementation do so badly in the first place?
Post reply on HN