Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nim 2.0

nim-lang.org

Post reply on HN
Print view View original

21–30 of 213 posts

Re: Nim 2.0

#21

Post by jackmott42 »

fastball wrote: post #12
rbjorklin wrote: post #9

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...

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

It isn't really a language community so interested in web server efficiency, and until recent years threading efficiently was kind of tricky with the GC scheme they used. If someone wanted Nim to rank high you could do it, but I'm not sure it is worth the effort?

Re: Nim 2.0

#22

Post by michaelsbradley »

fastball wrote: post #12
rbjorklin wrote: post #9

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...

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

Possibly it wasn't compiled with `-d:release`. I only looked briefly — is there a way to see the source code and cli flags used for the various implementations?

Re: Nim 2.0

#23

Post by echelon »

pavlov wrote: post #8
netbioserror wrote: post #2

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.

Same as Rust. Vec and HashMap are stack pointers to the heap-allocated container storage space.

Re: Nim 2.0

#25

Post by summarity »

brodouevencode wrote: post #13

What are some noteworthy projects or libraries written in Nim?

https://findsight.ai is my project, written in Nim

I gave a talk about it here: https://www.youtube.com/watch?v=elNrRU12xRc including some more intense use of Nim (for inline PEG grammars and data-parallel processing with Weave)

Re: Nim 2.0

#26

Post by 0cf8612b2e1e »

_xivi wrote: post #6

Just started learning Nim recently and really loving it. Even though it's older than its peers like Rust and Go, it still quite the underdog. Hope more people start paying attention to it.

Go had full time engineers designing the language, tooling, docs, etc. Nim has never had huge industry sponsorship, so comparing the languages on age alone is hardly fair.

Re: Nim 2.0

#27

Post by WhereIsTheTruth »

Could be a fun python alternative

Questions:

- value/object semantic: i peeked at some code, and i can't tell what is a value, and what is a reference type, is everything heap allocated?

- tooling: what's the state of their language server? does it work with all of their language features?

- debugging: does gdb/lldb understand nim's types and slices?

And finally: is a no-gc mode available?

I'll play with it later today, it's always been in my todo list of languages to try, now is the perfect time

Re: Nim 2.0

#28

Post by flohofwoe »

jadbox wrote: 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).

I maintain auto-generated bindings for my C libraries for Zig and Nim (and Odin and Rust - although the Rust bindings definitely need some love to make them a lot more idiomatic).

I think looking at the examples (which is essentially the same code in different languages) gives you a high level idea, but they only scratch the surface when it comes to language features (for instance the Zig examples don't use any comptime features):

Zig: https://github.com/floooh/sokol-zig/tree/master/src/examples

Nim: https://github.com/floooh/sokol-nim/tree/master/examples

Odin: https://github.com/floooh/sokol-odin/tree/main/examples

Rust: https://github.com/floooh/sokol-rust/tree/main/examples

Re: Nim 2.0

#29

Post by netbioserror »

remram wrote: post #15
pavlov wrote: post #8

Earlier quoted context omitted.

> “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".

Dynamic data structures by their nature have to be allocated to the heap. What I mean by "prefers the stack" is that you don't have to make a managed ref and dereference a managed pointer type. You just make a `seq[int]`, use it as a `seq[int]`, and pass it as a `seq[int]`, just like stack data. Behind the scenes, it has a unique scoped pointer with no mental overhead.
Post reply on HN