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

Nim 2.0 thoughts

forum.nim-lang.org

Post reply on HN
Print view View original

51–60 of 150 posts

Re: Nim 2.0 thoughts

#51

Post by throwaway894345 »

fastball wrote: post #49
serverholic wrote: post #45

Earlier quoted context omitted.

Nim has a garbage-collector right? In that case I don't see how you can compare Nim and Rust. The Go comparison makes more sense.

Yes garbage-collected, with a caveat. From the website: > Nim's memory management is deterministic and customizable with destructors and move semantics, inspired by C++ and Rust. It is well-suited for embedded, hard-realtime systems.

This is interesting. The hard-realtime folks are a conservative bunch (understandably so); I wonder how much traction Nim is getting in that space.

Re: Nim 2.0 thoughts

#52

Post by michaelsbradley »

fastball wrote: post #49
serverholic wrote: post #45

Earlier quoted context omitted.

Nim has a garbage-collector right? In that case I don't see how you can compare Nim and Rust. The Go comparison makes more sense.

Yes garbage-collected, with a caveat. From the website: > Nim's memory management is deterministic and customizable with destructors and move semantics, inspired by C++ and Rust. It is well-suited for embedded, hard-realtime systems.

The reference counter with "destructors and move semantics..." is not presently the default, though it will be in the future. The OP mentions that.

The current default GC involves a somewhat unusual memory model that can make certain kinds of multi-threaded programming difficult: each thread has its own heap and independent GC; memory subject to GC cannot be read/written across threads and locks can't be used to remedy the situation; if you force the compiler to accept code that violates the "no shared" rule, the ref count of the GC on one thread or another will eventually get corrupted and the program will crash with SIGSEGV.

However, by allocating on and copying to/from the shared heap (which is never subject to garbage collection) you can do message passing across threads.

Re: Nim 2.0 thoughts

#53

Post by memco »

xigoi wrote: post #20
adenozine wrote: post #11

Earlier quoted context omitted.

Sure. I'm on phone, so hopefully this paste doesn't look awful, but it's right from the website homepage iterator oddNumbers[Idx, T](a: array[Idx, T]): T = for x in a: if x mod 2 == 1: yield x The three different sets of brackets, the mixed : and =, it just seems inelegant to me. I don't really know how I'd improve it, so it's just pointless, ignorant complaining on my part. Pay me little mind.

The equivalent in Python would be: T = TypeVar("T") def odd_numbers(a: list[T]) -> Iterator[T]: # implementation I don't really find that less verbose, in terms of brackets and symbols…

Does Nim have comprehensions? Even if you're striving for equivalent signatures the inner body of the function can be expressed as a comprehension in Python:

  T = TypeVar("T")
  def odd_numbers(a: Iterable[T]) -> Iterator[T]:
    yield from (n for n in a if n % 2 == 1)

Re: Nim 2.0 thoughts

#54

Post by michaelsbradley »

memco wrote: post #53
xigoi wrote: post #20

Earlier quoted context omitted.

The equivalent in Python would be: T = TypeVar("T") def odd_numbers(a: list[T]) -> Iterator[T]: # implementation I don't really find that less verbose, in terms of brackets and symbols…

Does Nim have comprehensions? Even if you're striving for equivalent signatures the inner body of the function can be expressed as a comprehension in Python: T = TypeVar("T") def odd_numbers(a: Iterable[T]) -> Iterator[T]: yield from (n for n in a if n % 2 == 1)

See collect: https://nim-lang.org/docs/sugar.html#collect.m%2Cuntyped%2Cu...

Re: Nim 2.0 thoughts

#55

Post by eikenberry »

Oreb wrote: post #35

I started using Nim recently and have been very impressed. It feels like a better Rust than Rust, and a better Go than Go. Why doesn’t Nim get more attention?

How is the compiler, speed wise? One thing I really like about Go and really don't like about Rust are their relative compiler speeds. I think it makes a big different for the language and Nim has a chance to get this right as they didn't make the mistake of using LLVM and it's bad compiler UX.

Re: Nim 2.0 thoughts

#56

Post by otherme123 »

pindab0ter wrote: post #44
komuher wrote: post #42

Man nim is such a cool language it just need some more community and better docs to get some hype.

What's the main use case of Nim, would you say? Is it good for personal project/automation, for desktop or web apps? Etc.

I started using it for parsing heavy files, just for the speed. Slowly I replaced Python with Nim for almost everything, even when it doesn't make much sense (e.g. for controlling Selenium), and only use Python when I need graphics (Matplotlib) or some other libraries that I cannot replace.

IMO the main case is when you need C speed but you don't want to code in C.

Re: Nim 2.0 thoughts

#57

Post by Zababa »

fastball wrote: post #49
serverholic wrote: post #45

Earlier quoted context omitted.

Nim has a garbage-collector right? In that case I don't see how you can compare Nim and Rust. The Go comparison makes more sense.

Yes garbage-collected, with a caveat. From the website: > Nim's memory management is deterministic and customizable with destructors and move semantics, inspired by C++ and Rust. It is well-suited for embedded, hard-realtime systems.

Would comparing it to Swift be fair? At least on the memory management side.

Re: Nim 2.0 thoughts

#58

Post by forgotpwd16 »

Oreb wrote: post #35

I started using Nim recently and have been very impressed. It feels like a better Rust than Rust, and a better Go than Go. Why doesn’t Nim get more attention?

It may be better than Go but I don't see how it is comparable to Rust. Rust's biggest selling point is compilation-checked memory and thread safety guarantee without garbage collection. Nim instead uses a garbage collector, or a reference counter similar (but deterministic) to Swift which can cause memory leaks, or manual memory management.

Re: Nim 2.0 thoughts

#59

Post by TylerE »

eikenberry wrote: post #55
Oreb wrote: post #35

I started using Nim recently and have been very impressed. It feels like a better Rust than Rust, and a better Go than Go. Why doesn’t Nim get more attention?

How is the compiler, speed wise? One thing I really like about Go and really don't like about Rust are their relative compiler speeds. I think it makes a big different for the language and Nim has a chance to get this right as they didn't make the mistake of using LLVM and it's bad compiler UX.

Pretty good. The actual compilation is via clang, so there's a lot of heavy lifting done by that.

So basically nim actually compiles .nim -> .c -> binary

Re: Nim 2.0 thoughts

#60

Post by georgelyon »

BracketMaster wrote: post #22

One thing people don't often bring up is how great nim is for writing DSLs. DSLs really matter in the hardware and digital design space - a space that seems to be completely devoid of innovation when it comes to tooling. A couple languages that try to bring RTL into the 21st century are nMigen-Python and Chisel-Scala. I'm currently writing an RTL in Nim. Nim's macro system allows you to do really cool things like ins…

This sounds cool, I would be very interested if you had any public code. It’s _very_ early days but I’m working on a similar project in Swift: https://github.com/circt/Edith
Post reply on HN