181–190 of 213 posts
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.
httpbeast[1] reached #6 at one point, but I think the author is busy with other things nowadays. https://www.techempower.com/benchmarks/#section=data-r18&hw=... [1] https://github.com/dom96/httpbeast
Earlier quoted context omitted.
To be fair to Nim, only Python has the huge ML ecosystem of numpy, scipy, pandas, opencv, pytorch, tensorflow, keres... Doing ML/AI style work in anything but python is really hard! That said Nim does have the nimpy library that allows for pretty seamless interop with python. Which means you can just import PyTorch, or scipy, or opencv and use them in Nim.
for me (mobile developer) interop with python is not enough because of really poor python story on mobile devices (iOS / android) when using native modules. I think if Nim had a seamless interop with Rust or even Zig it could piggyback on those communities to get some libraries for free.
Earlier quoted context omitted.
You might like Patty. It makes case types more ergonomic: https://github.com/andreaferretti/patty
Neat! Thanks for sharing. This might come in handy, although the constraint of unique field names across variant cases is still there.
Earlier quoted context omitted.
I’ve written programs in both, though it’s been a while since I used Nim now. I think I enjoyed writing Nim more. Zig is more boring, but for all the right reasons. I wouldn’t personally choose to write an OS in Nim, but I think Zig would be great for that when it’s mature. I personally started using it for embedded software. I would probably use Nim for CLI tools, server applications, maybe GUI applications and game…
nim seems good for embedded too,just use cross c compiler as the backend?
Earlier quoted context omitted.
I think the short answer is it's built on top of C tooling so it doesn't really need another way to do it because you can use emscripten. Search their forum for "web assembly". I did ask him about it eight years ago: https://forum.nim-lang.org/t/1392#8675 But that was a little early on and there have been other priorities for the language.
The reason I ask is that I was poking around and saw some projects to help with wasm compilation, and on this random list of wasm-capable languages [0], Nim is listed as "Work in Progress." Notably, Swift is ranked higher, and I view Swift as extremely experimental when it comes to wasm [0]: https://github.com/appcypher/awesome-wasm-langs
Is Nim 1 going to receive patches going forward? Or is it a hard upgrade?
"Nim is a programming language that is good for everything, but not for everybody." now you got me really interested. At some point dlang-betterc + zig + nim should have an interoperability article and share libraries.
Really, I'm quite hopeful for crabi: https://github.com/rust-lang/rust/pull/105586 An ABI for languages with a proper type system seems fantastic. Swift, Rust, Nim, D all share very similar type systems (and memory management systems) and it would be very cool to see what kinds of interop easy dynamic linking would allow.
Nim has been my favorite language for a while now, and I'm very excited to see version 2.0 finally released. A lot of these features have been items I've been looking forward to for some time. The only downside is some of the included modules being moved to 3rd party repositories, as mentioned at the very bottom. It's not a big deal, but it was nice having SQLite support built into the library. I suppose once you sup…
Libraries stagnate in the batteries included. Python carries some dead batteries since the 90's, but they are required there. While it's nice to have path or logging support in the batteries, some other things are better as third parties, to allow them to evolve.
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’ve written programs in both, though it’s been a while since I used Nim now. I think I enjoyed writing Nim more. Zig is more boring, but for all the right reasons. I wouldn’t personally choose to write an OS in Nim, but I think Zig would be great for that when it’s mature. I personally started using it for embedded software. I would probably use Nim for CLI tools, server applications, maybe GUI applications and game…
I wouldn't necessarily prefer Nim for any of the things you listed but this doesn't have the same argument as for games with Odin (which has great tools and libraries for making games as well as gives a much better overview of important things you'll have to care about for making them in terms of performance, etc.).
Rather, it's because I've found that Nim belongs with the other languages that think that complexity can be managed by being hidden well enough, which I've found is simply not the case when something actually needs to be debugged or you need to understand the behavior of the program.
Hiding/ignoring allocation errors, not making allocation explicit, not making deallocation explicit, etc., makes for a much worse time actually understanding what's going to happen. Adding tons of GC options like alternative GC implementations isn't going to fix it and this new one is really just another example of trying even harder to hide complexity.
I think the ultimate irony of these languages that have magical features like move semantics is that they do some of those things in the name of performance but in practice many of them are so complicated to write well-performing code in with these space technology features and non-obvious behavior that the end results are worse than much, much simpler languages. I've also found that these languages' development cycles (for the end user) isn't that much longer than the space tech ones because there is ultimately much, much less to use in them so people end up just writing the actual code instead of trying to wrangle all of the magic.
Earlier quoted context omitted.
I’ve written programs in both, though it’s been a while since I used Nim now. I think I enjoyed writing Nim more. Zig is more boring, but for all the right reasons. I wouldn’t personally choose to write an OS in Nim, but I think Zig would be great for that when it’s mature. I personally started using it for embedded software. I would probably use Nim for CLI tools, server applications, maybe GUI applications and game…
I suspect Nim would be much, much harder to wrangle for games than Zig (or easily the best of the bunch: Odin) since it doesn't make enough things clear at all in terms of allocation and only allows indirect control of allocation and deallocation. I wouldn't necessarily prefer Nim for any of the things you listed but this doesn't have the same argument as for games with Odin (which has great tools and libraries for m…