Nim in 2020: A Short Recap • Hacker News Board

Re: Nim in 2020: A Short Recap

#101

Post by nikki93 » Thu, Dec 31, 2020, 7:25 PM UTC

didibus wrote: post #11

pizza234 wrote: post #2

Very interesting. Is the memory model essentially a middle ground between GC-based and manual memory management?: > Scope-based memory management (destructors are injected after the scope) - generally reduces RAM usage of the programs and improves performance. How does Nim handle references? How similar is this to Rust's lifetimes GC-ed instead of manually managed? Is this essentially like Rust, with the main differe…

Seems Nim will do some static analysis where if it can infer a reference is locally scoped in some way, it will deterministically inject a call to the destructor at the end of the scope. If not, it will do reference counting which will also have (if using orc) an extra cycle detection pass so that the references count references can also handle cycles. Finally, Nim will also do some static analysis, and if it can inf…

Refcounted refs have copy and destruct semantics, and then what you're talking about is basically move semantics over those refs. Refcount increments be elided if the ref is "moved." The increment is only needed on copy. Additionally, a moved-from value doesn't need to be destructed (in the case of a refcounted ref -- decrementing the count and deallocating the pointed-at memory if count goes to zero). A talk about similar concepts in the "Lobster" language that explains it pretty well I think: https://youtu.be/WUkYIdv9B8c

Re: Nim in 2020: A Short Recap

#102

Post by nikki93 » Thu, Dec 31, 2020, 7:28 PM UTC

didibus wrote: post #26

k__ wrote: post #17

Earlier quoted context omitted.

So if I understand that correctly: Nim will try to do a light version of Rust's borrow checking and then gradually move from static to dynamic solutions for memory management. I read that Nim's GC is optional, does this mean it can be deactivated and when the static memory management fails, I can do it manually for the edge cases that would otherwise done by the GC? Hope this makes sense, haha.

> So if I understand that correctly: Nim will try to do a light version of Rust's borrow checking and then gradually move from static to dynamic solutions for memory management I think that's an okay way to put it. Though it might be best to think of it the other way around. It'll default to GC and copying data around (pass by value) and will try to optimize things if it can to more deterministic memory management an…

Also seq[T] and closures involve GC (and some other types maybe).

Re: Nim in 2020: A Short Recap

#103

Post by nikki93 » Thu, Dec 31, 2020, 7:41 PM UTC

Rompect wrote: post #41

suncore wrote: post #7

Earlier quoted context omitted.

I think the main difference (benefit?) is that Nim has the convenience of a garbage collected language while retaining good and predictable performance (e.g. via ARC/ORC and thread-local GC). Rust has no GC so requires more from the programmer. Personally, I'd rather use a GC language to have less complexity in the code even though I have to spend some more time learning to use the GC correctly.

For normal purposes, dealing with Rust's lifetimes will be easier than spending some time "learning to use the GC correctly"

Nim's ARC thing is pretty different from blackbox GCs you have to poke with a stick like Go's or JVM's. It's pretty deterministic where additional calls are inserted by the compiler, and you can use --expandArc or look at the generated C.

As a single anecdote -- I've studied Rust before and it's been a while. Pretty familiar with C++ move semantics stuff. I decided to read the Rust book again while also learning Nim simultaneously; and I had an entt wrapper and graphics rendering in Nim without GC before I finished getting through the borrow checking chapter in the Rust book.

Re: Nim in 2020: A Short Recap

#104

Post by notdang » Thu, Dec 31, 2020, 7:45 PM UTC

runald wrote: post #12

Too bad nim uses a whitespace-sensitive syntax like python, something I personally dislike.

Always wondering how blind people can use these whitespace-sensitive languages. Are there specialized screen readers?

Re: Nim in 2020: A Short Recap

#105

Post by elcritch » Thu, Dec 31, 2020, 7:57 PM UTC

weitzj wrote: post #86

elcritch wrote: post #56

Earlier quoted context omitted.

Nim fits great on microcontrollers! Benefit is that it compiles to C and therefore can run anywhere C can. It also lets you reuse all the rest of the embedded C environment and build tools, which given the nature of embedded toolchains is handy for hitting the ground running. Rust's standard library/runtime binaries are really heavy compared to Nim's.

How are your esp32 Nim deployments holding up? Do you have futur plans for the new esp32 riscv processors?

> How are your esp32 Nim deployments holding up?

They're doing great! Nim has proven surprisingly stable, which was a fear I had at first. The core team has improved compiler support and I've not run into any issues updating so far. It bolster's my confidence in Nim.

Even if Nim development were to suddenly "stop" tomorrow, it'd easily be useable for embedded for a decade or more. There's improvement to be made in Nim, but it's a resilient system design. If the same were to happen to Rust or Crystal, for example, you'd have issues keeping the compiler up to date with LLVM, etc. Compiling to C gives a lot of stability for embedded work. Sort of similar to how Delphi Pascal is still useable today.

One surprise came when I had to do some optimizations and went from `-d:debug` to `-d:release`. The debug code added enough overhead it fixed some timing issues with the high end ADC we're using. Moving to release mode made it too fast and required adding the required delay (it was in the ADC datasheet but forgot it). Easy to solve, but it's worth noting.

> Do you have futur plans for the new esp32 riscv processors?

If a risc-v processor supports C, then it already supports Nim! The real question is libraries and/or build support for the target. An afternoon of work can get the Nim build setup to work with almost any C/C++ build system. Really, Nim on risc-v just requires a target board and someone to sit down for a few hours. It's a fun "hacking exercise" :-)

As a side tangent, I'd like to make a first class "pure" FreeRTOS library as it's the most widely used RTOS. That's after dealing with a lot of annoying race conditions in the `esp-idf` and seeing the incredible amount of hacky C code in embedded systems.

Building on FreeRTOS but introducing esp32-like libraries for vfat/files/networking/etc that'd work across microcontrollers would make for an incredibly productive environment (for embedded work).

There's also the possibility of using DrNim [1] to add formal verification for certain algorithms! Nim's effect system is very flexible. Really useful would be using the "guards and locks" [2] to write and prevent deadlocks (and maybe avoid locks?) when writing resource management and device drivers. A lot of the esp-idf issue I've run into are race conditions or slow speed since even `echo`/`printf` must have a lock to protect the system UART. Those are open questions/problems, and I'm starting a new job next month so it depends on what the needs there end up being.

1: https://nim-lang.org/docs/drnim.html 2: https://nim-lang.org/docs/manual_experimental.html#guards-an...

Re: Nim in 2020: A Short Recap

#106

Post by johnisgood » Thu, Dec 31, 2020, 8:20 PM UTC

matthiaswh wrote: post #42

macleginn wrote: post #38

Earlier quoted context omitted.

When I started learning Nim, I did not really expect anything, but time and again I caught myself thinking, ‘This is so much like Python!’ Eventually I lost interest because I do not need a faster Python that is not Python, and I didn’t find much else to be enthusiastic about.

I've written a large-ish amount of Nim code on personal projects while using Python day to day at work, and almost every time I'm working with Nim my brain is screaming at me at how unlike Python it is. Nim took some inspiration from Python's syntax, but the similarity is only skin deep. The construct of the language is very, very different resulting in code that usually looks and is structured differently. IMO going…

I mentioned in what ways it is similar to Python, but of course it is different to it in other ways.

Re: Nim in 2020: A Short Recap

#107

Post by marcoms » Thu, Dec 31, 2020, 9:29 PM UTC

akka47 wrote: post #36

marcoms wrote: post #23

Earlier quoted context omitted.

This might have been excused if they didn't also forbid tabs unless you use a hack ( https://github.com/nim-lang/Nim/wiki/Whitespace-FAQ#tabs-vs-... ), was interested in learning until I found this out

what's wrong with setting tabs to 4 spaces?

Not sure what you mean, Nim doesn’t allow tabs so that wouldn’t work

Re: Nim in 2020: A Short Recap

#108

Post by federico_c » Thu, Dec 31, 2020, 10:24 PM UTC

elcritch wrote: post #105

weitzj wrote: post #86

Earlier quoted context omitted.

How are your esp32 Nim deployments holding up? Do you have futur plans for the new esp32 riscv processors?

> How are your esp32 Nim deployments holding up? They're doing great! Nim has proven surprisingly stable, which was a fear I had at first. The core team has improved compiler support and I've not run into any issues updating so far. It bolster's my confidence in Nim. Even if Nim development were to suddenly "stop" tomorrow, it'd easily be useable for embedded for a decade or more. There's improvement to be made in Ni…

Nim natively supports 64bit RISC-V since years and 32bit in the current devel.

Also, the compiler itself is built for rv64 in Debian.

Re: Nim in 2020: A Short Recap

#109

Post by filipeclduarte » Fri, Jan 01, 2021, 2:12 AM UTC

Excellent language! I’m using it for scientific computing and like it a lot. There are a few but useful and good libraries. Arraymancer,ggplotnim, alea and stats. Also, great Python integration nimpy library.

Re: Nim in 2020: A Short Recap

#110

Post by magicalhippo » Fri, Jan 01, 2021, 3:25 AM UTC

dxdm wrote: post #92

magicalhippo wrote: post #20

Earlier quoted context omitted.

I agree that the lack of explicit start/end markers for code blocks is a very unfortunate choice. It was a bold choice by Python, but in my experience it turned out to be a poor choice, and not one to be copied. That being said, it looks like a very exciting language and like Python I think I'd manage to enjoy it overall despite of that choice.

> the lack of explicit start/end markers for code blocks is a very unfortunate choice. > It was a bold choice by Python, but in my experience it turned out to be a poor choice Could you explain why? I've heavily used languages with explicit block delimiters as well as Python, in collaborative environments, and the significant whitespace in Python does not really cause me any trouble. There is some slight overhead of…

Just to give a bit of context, I've been programming for almost 30 years, using many different languages. I've worked on many things, but of particular relevance I was part of a small team for several years which amongst other things had a 100kloc Python project that I did significant work on. I continue to use Python for all sorts of smaller projects, and for the most part enjoy it a lot. I've worked on large C++ code bases for years as well, and many of the usual suspects.

To take the most subjective part first, for me, I just find implicit blocks much harder to parse than with explicit start/stop symbols/keywords. My eyes and brain just seem to have an easier time identifying the explicit blocks. It's like writing sentences without using a period to end them, but just three spaces say.

Yes it's a bit more verbose, but I find it really helps readability for me. This of course might very well be the way my brain works, or the way my brain learned to work as a result of my first programming experiences, hence being subjective.

A bit more objectively, in my experience it seems easier for myself and others to make mistakes at the end of implicit blocks, either having a line indented that shouldn't be or vice versa. It is my experience that with explicit blocks those faults tend to stick out like a sore thumb.

I even have an add-on for my current IDE which, amongst other issues, complains loudly about that. If the language had had implicit blocks it couldn't really do that to the same degree.

I also find explicit blocks is easier to use with tools, especially when diffing. When using a language with explicit blocks I can enable the ignore whitespace feature of the diff tool and if say an outer "if" was added, you get about two lines that changed. With implicit blocks all the lines of the block change, so you got to scan through them to make sure no "real" changes were made. I tended to spend a lot longer on non-trivial Python merges compared to say C++ due to this.

I've also had the misfortune to have to edit Python code using only simple tools, without any Python-magic or similar. It's a royal pain if you have to copy/paste code around.

But yeah, I accept it mostly boils down to preference. I mean clearly there are some more objective metrics, but how you weigh those will be subjective so, yeah...