71–80 of 213 posts
Earlier quoted context omitted.
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?
Hopefully it'll get updated/replaced some time, but there's plenty of faster 3rd party ones already.
nim is a better python(syntax wise) that compiles to c(or c++,js,etc but c is the default) with GC turned on by default. I have always been wanting to use it outside of what my job needs(c/c++/python). I hope some big players adopt Nim to make it one of the mainstream language.
What are some noteworthy projects or libraries written in Nim?
https://git.sr.ht/~bptato/chawan
Also, there exists another Nim web browser project; from what I can tell, it's in somewhat earlier stages of development.
If someone at Manning Publications is reading this, it would be great to have a book on the newer Nim version, but please consider using a different typesetting with more readable fonts. I purchased the great book by Dominik Picheta, but am forced to use the .pdf because the dead tree version uses thin fonts that I find extremely hard to read even with the right pair of glasses. Font components (arms, lines, stems, e…
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 tod…
So "var i: int" is value, "var i: ref int" is a heap allocated reference that's deterministically managed like a borrow checked smart pointer, eliding reference counting if possible.
You can turn off GC or use a different GC, but some of the stdlib uses them, so you'd need to avoid those or write/use alternatives.
Let me say though, the GC is realtime capable and not stop the world. It's not like Java, it's not far off Rust without the hassle.
Earlier quoted context omitted.
And which language did you enjoy coding in the most? Yeah, a subjective question :-). (Edit: Missed the auto-generated part, so maybe you don't have an opinion on experience regarding this?)
I think actually Odin, although I was surprised by that (being more of a Zig fan). Odin has some neat convenience features which are nice for higher level code, while Zig can be a lot more 'draconian' by enforcing correctness even at the cost of some "line noise" (but I guess both languages are still in flux, so that might change). As for Nim I enjoyed it initially (because of the Python vibes I guess) but the automa…
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.
https://www.techempower.com/benchmarks/#section=data-r18&hw=...
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).
There were loads of specific differences, but if I could characterize both languages in a simple way:
- Nim seems to emphasize being a swiss army knife in the way that Python is, except as a compiled language.
- Zig is a much more focused language that tries to hit a certain specific niche - being a successor and replacement for C - and hits that mark spectacularly.
I think language preference comes down to what your personal needs and wants out of a new language that isn't being served by whatever you're using currently. I personally landed in the "Zig" camp because the way it approaches its ambition of being a C successor is intriguing, but I could see why other people might land on Nim.
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".
"var data: MyObject" is on the stack. "var arr: array[1000, MyObject]" is allocated on the stack sequentially.
Only dynamic seq or ref types use the heap by default.