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

191–200 of 213 posts

Re: Nim 2.0

#191

Post by xigoi »

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…

> i can't tell what is a value

If a type is declared with 'ref', it's a reference type. Otherwise, it's a value type.

Re: Nim 2.0

#193

Post by fuzztester »

ThomasTJdev wrote: post #156
fuzztester wrote: post #141

Earlier quoted context omitted.

>More and more large companies and startups are adopting Nim. Ineresting. Are there any stats / data on this, or is it anecdotal? Even if anecdotal, can you name some names?

For startups, you can count us in[1]. Our backend, across all services, is using Nim. [1] https://cxplanner.com

Thanks

Re: Nim 2.0

#194

Post by snthpy »

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. Unfortunately it looks like it hasn't been updated in a while? Is that because it's complete or a lack of interest?

For example, the approach mentioned at the bottom of the README of integrating via nlvm (https://github.com/arnetheduck/nlvm) sounded great but appears to be unpursued.

Re: Nim 2.0

#195

Post by snthpy »

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.

I found the following article about Nim and Rust interop:

https://dev.to/dumblepytech1/the-way-integrate-rust-into-nim...

Haven't read it yet but it looks promising.

Re: Nim 2.0

#196

Post by 59nadir »

xigoi wrote: post #190
59nadir wrote: post #189

Earlier quoted context omitted.

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…

Many game developers want to focus on writing games instead of fighting a memory allocator. Unless you're making a 3D game with realistic graphics, you don't need every last bit of performance.

No one needs to be fighting allocators; they are far less inhibiting and pose less of an issue than GC or RAII will in the vast majority of cases. They're far easier and simpler to deal with on the whole as well. You're always interfacing with memory management somehow and the implicit way is usually much harder to work with overall. The idea that having an allocator and explicitly working with it is for "that last bit of performance" is a bit disingenuous, you're usually losing far more than that with implicit allocation and deallocation. On top of that you simply inherently have a harder time understanding the behavior of your program.

Re: Nim 2.0

#197

Post by xigoi »

59nadir wrote: post #196
xigoi wrote: post #190

Earlier quoted context omitted.

Many game developers want to focus on writing games instead of fighting a memory allocator. Unless you're making a 3D game with realistic graphics, you don't need every last bit of performance.

No one needs to be fighting allocators; they are far less inhibiting and pose less of an issue than GC or RAII will in the vast majority of cases. They're far easier and simpler to deal with on the whole as well. You're always interfacing with memory management somehow and the implicit way is usually much harder to work with overall. The idea that having an allocator and explicitly working with it is for "that last b…

Manual memory management is one more thing to care about instead of the actual logic. With automatic memory management, you don't need to think about memory at all; what could be simpler?

Re: Nim 2.0

#198

Post by ThomasTJdev »

lairv wrote: post #177
ThomasTJdev wrote: post #156

Earlier quoted context omitted.

For startups, you can count us in[1]. Our backend, across all services, is using Nim. [1] https://cxplanner.com

What's the experience of writing web backend with Nim ? Did you use existing libraries / framework ? How good is the concurrency compared to something like Go ?

One of the reasons for choosing Nim was the ease of getting a production ready web backend. For the core part of managing the backend we are using existing Nim libraries [1], and they are easy to expand and work with. I cannot give you a comparison with Go since I haven't managed that large Go projects - but for Nim we are all into the async and threading. I think the channels within the threading is hardest part in Nim, but work is being done it.

[1] https://nimble.directory [1a] https://github.com/dom96/jester/ [1b] https://github.com/planety/Prologue [1c] https://github.com/guzba/mummy

Re: Nim 2.0

#199

Post by 59nadir »

xigoi wrote: post #197
59nadir wrote: post #196

Earlier quoted context omitted.

No one needs to be fighting allocators; they are far less inhibiting and pose less of an issue than GC or RAII will in the vast majority of cases. They're far easier and simpler to deal with on the whole as well. You're always interfacing with memory management somehow and the implicit way is usually much harder to work with overall. The idea that having an allocator and explicitly working with it is for "that last b…

Manual memory management is one more thing to care about instead of the actual logic. With automatic memory management, you don't need to think about memory at all; what could be simpler?

Easier in the best case and much harder in the worst, when your lack of thinking is an issue (which it definitely will be unless you're prepared to use more of the machine for no reason). Simplicity is not about what's easier to use, it's about how you interface with something, how simple and straight forward that interface is to use, how many things are implicitly or explicitly affected by that thing, and so on. Automatic memory management usually implies an assumption that allocations can't fail, memory is infinite, etc., so the assumptions and complications are many. It also adds more code you didn't write and have no direct control over, which complicates your problem solving in many ways.

GC or other automatic memory management is only easier if you have absolutely zero care for resource usage. RAII will oftentimes lead to single allocations and deallocations, for example, unless you take care to not have it be so, which is an immense waste of resources.

It's fine if you don't care and you know that that's going to produce slow, bad software, but let's be honest about that instead of saying you can not care and everything will be fine.

Re: Nim 2.0

#200

Post by demizer »

sedatk wrote: post #135

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

On the flip side the Rust Foundation hasn't been that great either...
Post reply on HN