Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nim 1.4

nim-lang.org

Post reply on HN
Print view View original

51–60 of 144 posts

Re: Nim 1.4

#51

Post by nivviv »

A small perspective insight from a game developer:

We (Beamdog) are using nim in production for Neverwinter Nights: Enhanced Edition, for the serverside parts of running the multiplayer infra.

nim is uniquely good in providing an immense amount of value for very little effort. It gets _out of my way_ and makes it very easy to write a lot of code that mostly works really well, without having given me any serious traps and pits to fall into. No memleaks, no spurious crashes, no side-effect oopses, anything like that. It's C/++ interop has been a huge enabler for feature growth as well, as we can partly link in game code and it works fine. For example, our platform integrates seamlessly with native/openssl/dtls for game console connectivity. And it all works, and does so with good performance. It is all now a set of quite a few moving components (a message bus, various network terminators, TURN relays, state management, logging and metrics, a simple json api consumed both by game clients and web (https://nwn.beamdog.net), ...).

We're still lagging behind and are on 1.0.8, but that is totally fine. It's tested and works, and there's no real incentive to move to 1.2 or 1.4 - yet!

Usage for our game has expanded to provide a few open source supporting utilities (https://github.com/Beamdog/nwsync) and libraries (https://github.com/niv/neverwinter.nim/) too. The good part about those is that they are cross-platform as well, and we can provide one-click binaries for users.

OTOH, There's been a few rough edges and some issues along the way. Some platform snafus come to mind, but those have been early days - 0.17, etc. Some strange async bugs had been found and fixed quickly though.

Good and bad, at least for me, nim has been a real joy to work with. If I had the chance to message my 3-years-younger, I'd just say "yea, keep going with that plan", as it turned out to save us a lot of development time. I suspect the features we've put in wouldn't have been possible in the timeframe we had, if it would have been all written in, say, C++.

Re: Nim 1.4

#52

Post by dilap »

untog wrote: post #46
nn3 wrote: post #43

Earlier quoted context omitted.

>Well of course it's not surprising, with memory safety as one of its goals. Where is this idea coming from that memory safety has to be complicated? Nearly all languages (basically everything except C/C++/Assembler) people are using are memory safe. And usually it's not complicated at all.

Well Rust's complication is memory safety and the lack of garbage collector. You see similar issues in a language like Swift, but Swift lets you create a memory leak very easily if you're not aware of the issues. Which can be fine when you're just starting out, you can always learn about it later. But Rust isn't so charitable: you must learn about memory safety upfront. The plus side is that it's significantly more d…

I've only played with Rust a little bit, but I think something that often goes under-remarked is that its ownership system doesn't just give you "static GC" -- it also guarantees no data races for multithreading. This is pretty awesome.

Re: Nim 1.4

#53

Post by treeform »

mcintyre1994 wrote: post #44
Boxxed wrote: post #3

There are a lot of gotchas with the new GC that make me nervous about this release: > As far as we know, ARC works with the complete standard library except for the current implementation of async... That's not a great endorsement... > If your code uses cyclic data structures, or if you’re not sure if your code produces cycles, you need to use --gc:orc and not --gc:arc. Seems like this is a big onus to put on the use…

At an ELI5 level, does anyone know why Swift can have ARC and async but Nim's ARC doesn't work with async? Is it just implementation details of Nim's async specifically instead of anything more fundamental to ARC? Just asking out of curiosity.

Yes. There is nothing fundamental to nim's ARC working with nim's async. There are attempts on make nim's async cycle free.

Re: Nim 1.4

#54

Post by treeform »

leorize wrote: post #10
Boxxed wrote: post #3

There are a lot of gotchas with the new GC that make me nervous about this release: > As far as we know, ARC works with the complete standard library except for the current implementation of async... That's not a great endorsement... > If your code uses cyclic data structures, or if you’re not sure if your code produces cycles, you need to use --gc:orc and not --gc:arc. Seems like this is a big onus to put on the use…

I believe the phrasing might not be clear to everyone, so here's a reduced version: * Nim's current async implementation creates a lot of cycles in the graph, so ARC can't collect them. * ORC is then developed as ARC + cycle collector to solve this issue, and it has been a success. * This 1.4 release introduces ORC to everyone so that we can have mass testing for this new GC and eventually move torwards ORC as the de…

Your explanation is very clear. Thanks.

Re: Nim 1.4

#55

Post by elcritch »

neverartful wrote: post #37
nepeckman wrote: post #15

Since Nim has hit the front page twice in the past day, let me just say: if you're at all curious about the language, try it out over the weekend. Nim isnt quite as simple as Zig (to compare to another compiled language with a smaller ecosystem), but the more advanced features stay out of the way until you need them. If you've worked with any static language, you probably know 80%-90% of what you need to write produc…

"Nim isn't quite as simple as Zig" My experience is complete opposite. I find Nim to be very simple and Zig to be not simple. What's the problem with Zig? I find the documentation to be chaotic. I believe that this is largely due to the rapid pace of changes (including changes that break earlier code).

That makes sense. I haven't tried Zig, but it's still pretty early in its history. That means a lot of syntax change, similar to Rust which is settling down, or Swift. Nim's been around long enough that it's settled it's syntax a while back.

Before I started really digging into Nim, it seemed like it was always changing the language a lot (feature churn). However, most of those changes have been compiler support for different GC's and other backend languages, which don't generally break existing code. I've tried Nim code from 4 years ago, and its almost the exact same syntax. Sometimes stdlib names changed. I think syntax change is the part that gets people a lot in terms of daily "complexity".

It actually reminds me of the feel of Python 2, before Python 3 that seems to add new syntax & language complexity every release. Well Python 2 but with a more solid language theory (e.g. everything can be a statement, etc). The trickiest part of day to day Nim are: var vs no-var, object vs ref object, and some iterator annoyances.

Re: Nim 1.4

#56

Post by treeform »

speps wrote: post #42
xyproto wrote: post #41

I was skeptical towards Nim. Then I wrote a small program that uses SDL2, and compared it to the same program written in over 10 other programming languages. Nim has an excellent combination of ease of use and performance.

Can you output WebAssembly/Emscripten project that uses SDL2?

Yes. People have done this.

Re: Nim 1.4

#57

Post by treeform »

untog wrote: post #18
anta40 wrote: post #17

Earlier quoted context omitted.

"and much much easier to pick up than Rust." That's my impression so far, too. Previously, I already had some experiences with C, Pascal, and Python. Then learning Nim just feels natural. Not so much with Rust. Well of course it's not surprising, with memory safety as one of its goals.

Yes, I think for me Nim could be a great answer for when I want to throw together a quick script. Right now I'll often use JS/Node for that and I'm not going to switch to Rust because it'll take a lot longer to get a rough and ready script going.

I have so many little nim scripts all over the place.

Re: Nim 1.4

#58

Post by Abishek_Muthian »

nivviv wrote: post #51

A small perspective insight from a game developer: We (Beamdog) are using nim in production for Neverwinter Nights: Enhanced Edition, for the serverside parts of running the multiplayer infra. nim is uniquely good in providing an immense amount of value for very little effort. It gets _out of my way_ and makes it very easy to write a lot of code that mostly works really well, without having given me any serious traps…

Interesting, thanks for sharing.

May I ask, did you consider Go and decided against it for any reason considering your requirements of quick development, cross-platform, interoperability are all guaranteed features of Go which should have given better peace of mind considering a production application?

Re: Nim 1.4

#59

Post by icey »

Nim is a lot of fun to write, and the language is small enough that you could build something fun / useful in a weekend. The community is also very responsive. Definitely worth checking out!

Re: Nim 1.4

#60

Post by samuell »

It is nice with a lot of innovation now in the ahead-of-time compiled languages camp.

What worries me is the fragmentation, and the fact that no one language seems to check all of the (subjective set of) boxes for a general purpose high-speed, ahead-of-time compiled language [0].

E.g, Crystal seems to be the only one supporting a modern concurrency story (similar to Go), but has a huge problem with compile times.

Nim looks nice in many respects, but last I checked, they don't have anything like Go-like concurrency. Maybe not on everyone's wishlist, but as the world move toward flow everything/everywhere[1], I personally find this to be a problem.

[0] https://docs.google.com/spreadsheets/d/1BAiJR026ih1U8HoRw__n...

[1] https://www.amazon.com/Flow-Architectures-Streaming-Event-Dr...

Post reply on HN