21–30 of 121 posts
Too bad nim uses a whitespace-sensitive syntax like python, something I personally dislike.
That's actually one of it biggest advantages over the competition. I wish more languages cared about readability.
So yeah, for me it makes the language less readable, that is, it makes it harder to parse the code as I read it.
Your mileage may vary indeed...
Earlier quoted context omitted.
How does karax run Nim client side? Cross compile to js or a wasm blob? Or something else entirely?
Nim compiles to js (as well as c and c++)
Like, if I wanted to make my own C compiler, how much would I have to implement for it to be usable with Nim-generated code?
Does it use a fairly constrained subset or does it use a lot of C and the standard library?
I imagine the latter but just curious.
Too bad nim uses a whitespace-sensitive syntax like python, something I personally dislike.
Too bad nim uses a whitespace-sensitive syntax like python, something I personally dislike.
You're free to use Golang or another language. Nim has a great feature set and will be a good fit for Python or Ruby teams wanting a more performant language. At the same time, it's more expressive than Golang and will fill a niche Golang couldn't meet. I like that we now have Golang, Rust, Swift, Nim, and Kotlin. They're all doing new things and excelling at their own niches.
Earlier quoted context omitted.
Seems Nim will do some static analysis where if it can infer a reference is locally scoped in some way, it will deterministically inject a call to the destructor at the end of the scope. If not, it will do reference counting which will also have (if using orc) an extra cycle detection pass so that the references count references can also handle cycles. Finally, Nim will also do some static analysis, and if it can inf…
So if I understand that correctly: Nim will try to do a light version of Rust's borrow checking and then gradually move from static to dynamic solutions for memory management. I read that Nim's GC is optional, does this mean it can be deactivated and when the static memory management fails, I can do it manually for the edge cases that would otherwise done by the GC? Hope this makes sense, haha.
Sort of. You either deactivate it completely with --gc:none ; or, you do it on per-variable basis by using a "ptr" (pointer) type, which is outside of the GC's realm. Any variable declared "ref" (reference) is within the realm of Nim's GC, and will be tracked by the gc you chose (none, boehm, mark&sweep, arc, orc, ...).
Additionally, you can define type bound operators to help the GC do its job, but IIRC (and I'm not sure I understand correctly), that doesn't turn off arc/orc - rather, it tells them how to apply some things.
Earlier quoted context omitted.
Seems Nim will do some static analysis where if it can infer a reference is locally scoped in some way, it will deterministically inject a call to the destructor at the end of the scope. If not, it will do reference counting which will also have (if using orc) an extra cycle detection pass so that the references count references can also handle cycles. Finally, Nim will also do some static analysis, and if it can inf…
So if I understand that correctly: Nim will try to do a light version of Rust's borrow checking and then gradually move from static to dynamic solutions for memory management. I read that Nim's GC is optional, does this mean it can be deactivated and when the static memory management fails, I can do it manually for the edge cases that would otherwise done by the GC? Hope this makes sense, haha.
I think that's an okay way to put it. Though it might be best to think of it the other way around. It'll default to GC and copying data around (pass by value) and will try to optimize things if it can to more deterministic memory management and pass by reference.
> I read that Nim's GC is optional, does this mean it can be deactivated and when the static memory management fails, I can do it manually for the edge cases that would otherwise done by the GC?
It isn't optional like that. It's more that by default all data is passed by value and allocated on the stack. And if you want to create things on the heap, you need to be explicit about it, at which point you can choose if you want the pointer to be managed by Nim's GC or manually. That's done by having two type of pointers, ref will be under GC, and ptr won't.
In what cases is Nim a better option than Rust? Would be great if anyone with more experience can share more information.
I consider Nim to be a compiled, faster Python. Nim is very easy to read and understand, and prototype in, vs. Rust.
People coming from Python that expect a "compiled, faster" Python often find a compiled, faster language but have very weird concepts expecting that language to behave like Python though it isn't.
Very interesting. Is the memory model essentially a middle ground between GC-based and manual memory management?: > Scope-based memory management (destructors are injected after the scope) - generally reduces RAM usage of the programs and improves performance. How does Nim handle references? How similar is this to Rust's lifetimes GC-ed instead of manually managed? Is this essentially like Rust, with the main differe…
Environments like Mesa/Cedar at Xerox PARC already made use of it, back in 1985.
https://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/parc...
Earlier quoted context omitted.
So if I understand that correctly: Nim will try to do a light version of Rust's borrow checking and then gradually move from static to dynamic solutions for memory management. I read that Nim's GC is optional, does this mean it can be deactivated and when the static memory management fails, I can do it manually for the edge cases that would otherwise done by the GC? Hope this makes sense, haha.
> So if I understand that correctly: Nim will try to do a light version of Rust's borrow checking and then gradually move from static to dynamic solutions for memory management I think that's an okay way to put it. Though it might be best to think of it the other way around. It'll default to GC and copying data around (pass by value) and will try to optimize things if it can to more deterministic memory management an…
Earlier quoted context omitted.
Nim compiles to js (as well as c and c++)
How much of C and the standard library does it use? Like, if I wanted to make my own C compiler, how much would I have to implement for it to be usable with Nim-generated code? Does it use a fairly constrained subset or does it use a lot of C and the standard library? I imagine the latter but just curious.
Full disclosure, not everything works - different backends tend to have slightly different bugs/coverage, but this also applies to c++ and js backends. But I use tcc as my default backend (in my nim.cfg file) every day and only run into problems like a time or two per year.