141–150 of 213 posts
I wrote a post on how Reddit uses Nim: https://www.reddit.com/r/RedditEng/comments/yvbt4h/why_i_enj... More and more large companies and startups are adopting Nim. Super excited for Nim 2.0 and huge thanks to all who contributed!
Ineresting.
Are there any stats / data on this, or is it anecdotal?
Even if anecdotal, can you name some names?
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?
The problem apparently is that they didn't actually have full type inference and the expressions on the right were given their types (probably a tuple of int x int x cstring) before they attempted the assignment into foo. Now they're using unification (they call it "top-down inference", so I'm guessing it's regular unification like other type inference systems use) so that the expression on the right will have the co…
So, Nim doesn’t seem to be under an umbrella of a non-profit. Isn’t this destined to be a problem at some point regarding either acquisition of rights or succession? Edit: Ouch. Just found this thread. Very disappointing, and actually makes a greater case for institutional ownership: https://forum.nim-lang.org/t/10312
Earlier quoted context omitted.
I don't know if my particular version is noteworthy, but I recently started making updated Nim bindings for OpenCV and it was kinda fun. I don't consider myself an advanced C++ programmer, but Nim made the process easier than I had feared it would be. https://github.com/tapsterbot/mvb-opencv
Not familiar with Nim enough to figure it out - are the bindings auto generated in similar style like opencv bindings to any other supported language (python, julia, objc, rust, etc)?
What are some noteworthy projects or libraries written in Nim?
- npeg lets you write PEGs inline in almost normal notation: https://github.com/zevv/npeg
- owlkettle is a declarative macro-oriented library for GTK: https://github.com/can-lehmann/owlkettle
- ratel is a framework for embedded programming: https://github.com/PMunch/ratel
- futhark provides for much more automatic C interop: https://github.com/PMunch/futhark
- nimpy allows calling Python code from Nim and vice versa: https://github.com/yglukhov/nimpy
- questionable provides a lot of syntax sugar surrounding Option/Result types: https://github.com/codex-storage/questionable
- nlvm is an unofficial LLVM backend: https://github.com/arnetheduck/nlvm
- chronos is an alternative async/await backend: https://github.com/status-im/nim-chronos
- cps allows arbitrary procedure rewriting in continuation passing style: https://github.com/nim-works/cps
A longer list can be found at https://github.com/ringabout/awesome-nim.
What are some noteworthy projects or libraries written in Nim?
We have written pixie: https://github.com/treeform/pixie . Pixie is a 2D graphics library similar to Cairo and Skia written entirely in Nim. Which I think is a big accomplishment. It even has python bindings: https://pypi.org/project/pixie-python/
Earlier quoted context omitted.
It looks simple but in a typed language it's actually somewhat tricky. The compiler needs to infer that the 1 is a float type, 2 is a byte, and compile it appropriately. 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 ex…
> It looks simple but in a typed language it's actually somewhat tricky. But that example looks about as simple as it can be, so I clearly must miss something. > The compiler needs to infer that the 1 is a float type, 2 is a byte, and compile it appropriately. And I don't understand _why_ it has to infer anything, as the type is explicitly declared. I mean, there are 2 possibilities: * 1 is both a valid integer and a…
The seq declaration doesn’t need to be inferred. However the right side does need to be inferred from the declaration.
> I mean, there are 2 possibilities: * 1 is both a valid integer and a float literal => Nim needs the type declaration on the left to unify the type
Yep, `1` is an ambiguous number literal. So the compiler needs to back the info from the type into the assignment expression. Not super hard to do for simple cases, but it can become expensive for complex types.
Earlier quoted context omitted.
And I'm surprised by how terribly it ranks – basically dead last against everything, even the Python frameworks, which is impressive.
Interesting. The Vercel benchmarks make it look pretty good. Only slightly behind rust. https://programming-language-benchmarks.vercel.app/zig-vs-ru... Benchmarks are as much about the skill of the programmer as they are about the language. I suspect those numbers could improve drastically.
Earlier quoted context omitted.
It looks simple but in a typed language it's actually somewhat tricky. The compiler needs to infer that the 1 is a float type, 2 is a byte, and compile it appropriately. 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 ex…
> It looks simple but in a typed language it's actually somewhat tricky. But that example looks about as simple as it can be, so I clearly must miss something. > The compiler needs to infer that the 1 is a float type, 2 is a byte, and compile it appropriately. And I don't understand _why_ it has to infer anything, as the type is explicitly declared. I mean, there are 2 possibilities: * 1 is both a valid integer and a…