NimConf 2022 – Nim Online Conference | Hacker News Reader

NimConf 2022 – Nim Online Conference

nim-lang.org

155 pointsWithinReason36 comments

a bit more info for those who do not follow too much:

- first talk by Andreas will update us on Nim 2.0 which is planned within the year and where the most important part will be the switch to orc memory management (deterministic memory management with garbage collection only limited to collect cycles).

- Suhei will talk about moe, vim inspired command line editor, see https://github.com/fox0430/moe (last year he talked about nicoru, docker in nim!)

- Tanguy from status, main sponsor of nim (they are building a lightweight ethereum node in nim) will talk about libp2p (in nim AND other langs), which is relevant for crypto web 3 world

- Antonis recently release a very nice library for fuzzing (an automated bug finding technique), see https://github.com/status-im/nim-drchaos

- I will be presenting with Hugo on nimib, a "framework"/DSL way to turn nim code in html (sort of replaces jupyter for nim, can do more than that); in particular we made very easy with nimib to take advantage the capability of nim to compile to js.

- next Hugo will present on how he created a nimib slides theme (based on reveal.js, at least 4 of the presentation seem to be based on nimislides)

- Can has created a very interesting an experimental deep learning framework for Nim based on a differentiable array programming language (and he has been doing great work on other stuff too, like owlkettle): https://github.com/can-lehmann/exprgrad

- Ryan will talk more about his incredible and frugal Entity Component System https://github.com/rlipsc/polymorph He did present on this topic in February but it seems it has progressed much and we might be seeing some very cool demonstration (that's speculation from thumbnail...)

- Juan has been working of having Nim work with Unreal Engine "the world's most open and advanced real-time 3D creation tool for photoreal visuals and immersive experiences". he has been working with Andreas to have Incremental Compilation (next big thing coming in the core language) so it looks pretty exciting

- I know very little about the work of Chris on Nim-SOS and Nim-htpx (see https://github.com/ct-clmsn/nim-sos ) but it looks to be impressing work in the area of scientific computing

- finally Andre/treeform is consistently producing great libraries and talks on Nim and I would not miss that talk for the world.

all videos are pre recorder but authors will be around in the chat to interact.

further discussion might appear here: https://forum.nim-lang.org/t/9539

Exciting to see ORC being the focus for 2.0! We’re using ARC (pure reference counting, minus the cycle collector) for our embedded firmware, and it’s been pretty excellent. Sink and Lent are great, as is the adoption of destructors/RAII-like approaches. Combined with Nims awesome compile time and meta programming features (for truely zero cost abstractions — nothing better than have the compiler help us write correct firmware code and have all those fancy types and checks disappear in the C output!), it’s been awesome. There’s some rough edges here and there, mostly due to the interplay of ESP-IDF having a pretty buggy malloc implementation, but being able to ask Nim to expandArc and tell me where the destructors are being put to track down accidental cycles or leaks has been handy — and it’ll only get better and easier as Nim adopts even more powerful tools :)

It’s a remarkably pragmatic language in a lot of ways, at least in my opinion. Can’t wait for the rest of the talks!

so nice to hear :). nim looks really great for embedded. this nim conf it seems we missed the embedded talk (was elcritch working on one?). are there pointers on stuff you are doing or you can share the name of your company?

Yeah elcritch was I thought but I also think he was super busy sadly :(

https://www.venturi.io/

That’s us! I’m hoping that now we have some devices out in the field in customers hands I can take some time to write some things up on it all — that’s if adding CANBUS support doesn’t kill me first anyway

yeah that happens, no worries. he will catch up on next occasion (next one might be Fosdem in February but it will be in person and so a bit out of reach for him, likely also for you?).

Nice site! Looking forward for a write up (especially since that would have meant you survived support)

Also, if you are too impatient to wait until tomorrow, you can just click through on the program you see links for the 2020 and 2021 Nim Conferences. (One 2021 link I saw is broken, but https://conf.nim-lang.org/ works for that - for now. I presume the plan is to swap that to 2022 and make the 2021 link work.)

HN people may be especially interested in the very first talk which is Andreas' vision for Nim 2.0.

Does anyone have experience with Nim and Zig that can talk about which use-cases each works better for?

I've only used Nim but generally if you can use a garbage collected language you should in most cases but there are many cases where you can't, reasonably, and so we have languages like Zig, Rust, C, etc. Unless you're going to be doing something very sensitive to performance to the extent that you were going to be thinking carefully about memory lifetimes anyways.

Isn't the GC of Nim optional?

Optional, though the language and standard library are kind of designed around it. So I'd say Nim can be used without the GC, but is optimized with the idea that you'll use the GC by default, with escape hatches for manual allocation when you need the power for performance or efficiency, e.g. manually managing big blocks of memory for tight loops.

Contrast to a language like Zig, which has a standard library and syntax built around the idea of manual allocators and what not, but is missing the "ease of use" of GC. Personally, I agree with GP, and like Nim's compromise of GC with a "I know better, let me do it manually" syntax, but there are domains where you want a language like Zig.

Correct. I'd add that with ARC (or ORC even), there's little reason to do manual memory management (alloc/free), even for embedded systems. ARC is an automatic memory management system based on reference counting, but there's no "runtime". It actually injects alloc and free calls at compile-time based on static analysis.

ORC adds runtime GC only for cycles, and will be the default in Nim 2.0.

You're information seems to be dated by the presentation.

TIL about Zig. It looks like it's been released a while ago (2016) but when I searched for how they handle concurrency all I could find was it's still in the research phase :(. I thought I was going to be able to find at least a design document like with Swift:

https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9...

> if you can use a garbage collected language

With ARC there's no GC runtime anymore, making Nim a competitor with Rust.

Do you mean with Rust's Rc or Arc?

They mean this: https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc...

I suggest you think of Nim as of a better Go - more ergonomic, easier to start being productive in, faster, giving more control if necessary (by descending into the unsafe territories of manual memory management, `emits` and such), more portable, suitable for workstations and embedded alike.

Zig is definitely not that. And I understand the description above misses the downsides of a small community and not the strongest ecosystem.

I learnt a bit of Nim few years ago, but haven't continue it. My understanding so far is unlike Go, Nim doesn't have concurrency built into the language/runtime?

Hopefully it should get better soon-ish, but concurrency (and even parallelism aka threads) unfortunately is probably Nim's weakest point at the moment.

On the good side, compared to go, Nim's interop with C is fully transparent (since Nim uses C as a backend). This means easy access to C libraries, but also makes it very appropriate for embedded targets like microcontrollers (especially with its ARC memory-management system, which is static/deterministic automatic reference counting).

Of course it does.

I think it is a stretch to compare Nim and Go as anything other than statically compiled languages. Nim is the anti-Go with every possible programming paradigm inside the language.

The implementation details and the development ethos differ, but from the pragmatic point they compete, offering higher abstraction level over C. Moreover:

- Both took some inspiration from languages of Wirthian family.

- Both promise easy onboarding, high readability and high productivity.

- Both rely on automatic memory management by default.

On the other hand, I agree that Nim feels and functions totally different while offering much more possibilities. You can definitely call Nim the anti-Go, but it doesn't negate the fact it could absolutely shine in the same domains, at least with a bit more love, attention and funding.

But they're both statically typed GC languages that compile to native binaries. Versus Zig which has no GC and is more akin to C, Rust, Ada, that sort of thing...

With ARC Nim is also very akin to Ada and Rust: https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc...

> ORC is Nim’s all-new cycle collector based on ARC. It can be considered a full-blown GC since it includes a local tracing phase (contrary to most other tracing GCs which do global tracing). ORC is what you should use when working with Nim’s async because it contains cycles that need to be dealt with.

From that blog post. Nim is great but it's more Go and less Rust...

> more Go and less Rust

Not at all, it does not have a runtime with a built-in thread pool and channels like Go.

Perhaps Nim will compile to Zig one day?

Anyone here used Nim for a bigger project? What was your experience like?

https://news.ycombinator.com/item?id=33287817

You bet I have! What would you like to know beyond that comment?

What's your debugging experience like? i.e. The tools you use, do you have to debug the C output, etc.

Because I live in embedded land, I use the compileOnly C output. What’s really nice about that though is with debugger:native enabled, it embeds source-map comments in the C back to the Nim lines they tie to! All in VSCode with gdb (and OpenOCD).

This gives me full interactive debugging, breakpoints etc of the Nim source directly — including via a JTAG from the ESP32 itself :) it’s super nice, considering none of the tools internally were built for Nim haha. The #Line macro is surprisingly powerful in C debugging land it turns out

If you’re doing desktop/non embedded stuff it’s even easier, and you can also enable useMalloc and run Nim programs through the Valgrind suite easily

see also this talk by Mamy (taken from last year nim conf) to see the experience of using it in production in status (main sponsor of nim): https://www.youtube.com/watch?v=5wljNaPkU7M&list=PLxLdEZg8DR...

We use it at www.cxplanner.com for a mix of micro/mono-services. Statically typed and good compile time combined with really fast code makes Nim perfect for us.

Could you elaborate why you chose Nim over other languages? The advantages need to be pretty strong when picking a niche language like this I would assume? Curious what the thought process was like.

While I work somewhere different, the choice basically came down to C/C++, or Nim (which compiles to either, and gives us the simplest binding story out there for handling external libraries and tools that our project requires).

Zig and Rust of course both exist, as does TinyGo, but Zig’s embedded story isn’t anywhere near complete yet, Rust is closer but it’s tendency to rewrite the embedded world from scratch (which is great for safety! Just bad for rapid firmware dev when we have a whole host of vendor drivers we need to use that aren’t supported in Rust’s embedded story yet) make them a pain

TinyGo was genuinely considered, but using a not-quite-normal compiler gave me the willies — which turned out to be a good choice as we have a lot of code sharing between the firmware and the server that it talks to (with a custom message protocol over TCP that’s encrypted — libsodium is great).

The long and the short of it for us was: do we want to write C/C++? Not really, it’s a pain to hire for and a pain to teach. And right now, Nim is a good slot in replacement/addition.

Early on in the project we wrote C libs to encapsulate some C driver code, and exposed that to Nim — and slowly migrated it all to Nim directly. Now it’s just ESP-IDF with Nim on top, no custom C code at all!

Reply on news.ycombinator.com