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

111–120 of 213 posts

Re: Nim 2.0

#111

Post by pointystick »

drbaba wrote: post #69
Bostonian wrote: post #30

If your Python programs heavily use Pandas and Numpy, could there still be speed benefits to translating them to Nim?

Following up on this: As someone who uses Python with NumPy/SciPy heavily, are there any Nim libraries that would make the transition smooth? Libraries that can help with e.g. sparse matrices, linear algebra, differential equations, etc.

I've not used them myself but there was an effort to group these kinds of libraries in a common 'SciNim' community:

https://github.com/SciNim https://scinim.github.io/getting-started/

Generally, projects created by Mamy Ratsimbazafy (mratsim) are a good start since he's very adept at optimisating data science-related libraries.

You might want to ask in the #science channel of the Nim Discord server since although it's often quiet, that's where people working on these repositories hang out.

Re: Nim 2.0

#112

Post by Tiberium »

pzo wrote: post #98
alwaysbeconsing wrote: post #94

Earlier quoted context omitted.

araq/Andreas Rumpf, the project lead, has also published a book: https://nim-lang.org/blog/2022/06/29/mastering-nim.html

unfortunately there is no ebook version and it seems araq is against publishing ebook (probably because of worrying about piracy) - for me who is travelling a lot, hard copy is a no go.

Araq has mentioned he'll create a new edition of the book for Nim 2.0, and publish it as an e-book, see https://forum.nim-lang.org/t/10366

Re: Nim 2.0

#113

Post by j-james »

otherme123 wrote: post #104
aquova wrote: post #43

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.

Yes, an experiment was run a while back, incorporating community-maintained code in a "fusion" repo shipped with the compiler by default. It didn't work very well. Discoverability and maintainability of stdlib-like things is hard.

Re: Nim 2.0

#114

Post by alwaysbeconsing »

cobby wrote: post #88
c-cube wrote: post #82

Earlier quoted context omitted.

When I looked at it a few years ago, the compiler didn't prevent you from accessing fields from the wrong variant, and didn't provide exhaustivity checks. So I think it still falls short of this (excellent) litmus test :/

Also Nim requires you to use unique field names across all variants.

This annoying restriction is lifted in Nim 2; see the linked announcement.

Re: Nim 2.0

#115

Post by moigagoo »

talldrinkofwhat wrote: post #84
arc619 wrote: post #57

Looking forward to trying out this release! After programming professionally for 25 years, IMO Nim really is the best of all worlds. Easy to write like Python, strongly typed but with great inference, and defaults that make it fast and safe. Great for everything from embedded to HPC. The language has an amazing way of making code simpler. Eg UFCS, generics, and concepts give the best of OOP without endless scaffoldin…

Ahem. Ahem. Contact info?

Are you hiring Nim devs?

Re: Nim 2.0

#116

Post by ElegantBeef »

pzo wrote: post #100
treeform wrote: post #92

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.

For Rust at least one can use https://github.com/arnetheduck/nbindgen

Re: Nim 2.0

#117

Post by j-james »

haolez wrote: post #96

It seems almost too good to be true. Well done! Could someone share some bad experiences when adopting Nim so I can weight that in? I'm seriously considering it.

I have a shortlist of pain points:

- Tooling is not great. The language server has a tendency to silently crash on occasion, and it's no rust-analyzer to begin with. A tooling rewrite has been delayed behind proper incremental compilation, which has been delayed behind ARC/ORC...

- Interfaces ("concepts") are experimental and there are two differing implementations.

- It lacks proper sum types and structural pattern matching in the core language. There are a number of quite good macro-based libraries that provide for this, however: fusion/matching, andreaferretti/patty, beef331/fungus, alaviss/union...

- Optional types are not the standard: the stdlib will throw exceptions. This is more so a personal preference than anything.

But that's about it. I do like Nim quite a lot.

Re: Nim 2.0

#118

Post by ElegantBeef »

janAkali wrote: post #34
WhereIsTheTruth wrote: post #27

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…

1. Nim uses 'var' modifier to pass by reference, e.g. "proc (n: var int)...", default behaviour is pass by value. And there're also raw pointers and references (safe pointers). >is a no-gc mode available? You can disable gc, but most of standard library depends on it. But in Nim 2.0 there's finally support for ARC and ORC (ARC + cycle collector).

> default behaviour is pass by value

Is not exactly true, smaller than 24 bytes is passed by value, the compiler optimizes larger calls and passes by reference implicitly.

Re: Nim 2.0

#119

Post by pzo »

ElegantBeef wrote: post #116
pzo wrote: post #100

Earlier quoted context omitted.

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.

For Rust at least one can use https://github.com/arnetheduck/nbindgen

that looks interesting, thanks! Did you try it if it delivers on promises? There was not any new commit since 2020 so not sure if the project is stale by now.

Re: Nim 2.0

#120

Post by seertaak »

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.

It very much is, and the point is, it _used_ to be more like java. Araq basically pulled off a very daring switchover from reference based language system to a value based one.

So now the language can credibly claim the same as c++ - no room left closer to the metal. But it's packaged in a much nicer syntax (imho), and has features like macros which we can expect I'm C++ in maybe 10 years, if we're lucky.

Post reply on HN