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

91–100 of 150 posts

Re: Nim 2.0 thoughts

#91

Post by elcritch »

BracketMaster wrote: post #85
thechao wrote: post #33

Earlier quoted context omitted.

Do you have anything public? I’ve been following LLHD for a while; I like the idea of a shared middle end. LLHD’s front end is Verilog/VHDL which are … not great. Are you translating, or building your own sim runtime?

Simulator is written internally in Nim. There isn't really a good FOSS IR for RTL sims on the market currently. I absolutely refuse to use MLIR or anything based on LLVM for that matter. LLVM takes up to 40 minutes to rebuild on my Apple silicon. This is completely unacceptable in terms of rapid iteration.

Nim really had fantastic potential for RTL and other hardware interaction languages. Best of luck in making progress with the RTL! I’d be really interested if it could become something for program CPLD or FPGA included in some microcontrollers now.

Re: Nim 2.0 thoughts

#92

Post by elcritch »

TylerE wrote: post #59
eikenberry wrote: post #55

Earlier quoted context omitted.

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

It’s good to note that the C/C++ generated by Nim compiles much faster than normal C/C++ code since they don’t include a lot of headers.

Re: Nim 2.0 thoughts

#93

Post by elcritch »

michaelsbradley wrote: post #52
fastball wrote: post #49

Earlier quoted context omitted.

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 reme…

Note I’m using Nim with the new GC (both ARC & ORC) on dual core esp32’s.

Locks do work with ARC, though some care needs to be taken. Both the Nim and free-rtos multi-threaded queues work well with the correct move/sink annotations.

The design of ARC allows you to move entire memory graphs between separate heaps. It works fine, but what’s not working is the compile time verification that a given memory graph is only owned/aliased by the top pointer. So there’s a lot of work to do in making it “safer and easy” to use.

Here’s an example: https://github.com/elcritch/nesper/blob/f54fff8b240e94684ae8...

Re: Nim 2.0 thoughts

#94

Post by sigzero »

mrweasel wrote: post #69
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?

What made me pick Go over Nim is a bigger standard library. For my use Nim is missing a good http server package/module and templating. If those two things had been present I would pick Nim over Go, it’s just a nice language for some like me, who have mostly done Python. I’m not sure if this was a bug in a third party module, but I also struggled a little with unicode support.

Something like:

https://nim-lang.org/docs/asynchttpserver.html

https://github.com/zendbit/nim.zfblast

Re: Nim 2.0 thoughts

#95

Post by elcritch »

throwaway894345 wrote: post #51
fastball wrote: post #49

Earlier quoted context omitted.

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.

There’s a few of us working in this area, well rather Nim on embedded microcontrollers. :-)

It works fantastically, though most of us aren’t traditional hard real time folks. Nevertheless Nim’s new ARC is excellent for this area. The overhead of the GC basically is just an increment/decrement on an integer (no atomic). That means it’s fast and predictable for modern MCUs and plays well with C code. If you want a tight interrupt function you can stick an object in global variable and know it won’t incur GC overhead.

It’s relatively easy to reason about where and when you want memory to be free’ed (actually easier than Rust). Also allocator pools are easy to utilize.

On a side note, as the Nim compiler improves moves and sinks analysis, the runtime overhead of ARC approaches that of Rust’s compile time memory management, especially with a lot of Rust code that use lots of Rc wrappers.

P.S. I’m planning to write a Nim wrapper for Zephyr RTOS when I get time later in the summer, and improve the existing FreeRTOS support too.

Re: Nim 2.0 thoughts

#96

Post by elcritch »

patrickmn wrote: post #30
khaledh wrote: post #21

Earlier quoted context omitted.

Then you end up with an ecosystem with mixed conventions. Not good IMO.

You can literally do whatever you want with any library you use in your own codebase and have a consistent convention in your own code regardless of what your dependencies' authors preferences are. In other words, if the library authors used camelCase but you want to use snake_case in your code, you just do it. It's very strange at first, and I had the same reaction as you, but it's actually quite nice. (I say that a…

Same here, at first making camelCase and snake_case interchangeable seemed like a terrible idea. But in practice I can read and grok libraries that use either and in your code call it using your preference. It just kinda works.

Re: Nim 2.0 thoughts

#97

Post by isubasinghe »

nimmer wrote: post #63
eikenberry wrote: post #55

Earlier quoted context omitted.

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.

Nim compiles to C and then runs GCC (not LLVM) to compile the binary. Overall, it's much faster than Go and Rust.

I get that Nim can be faster than Go but I don't see how it can be faster than Rust, could you please elaborate as to why?

Re: Nim 2.0 thoughts

#98

Post by searealist »

nimmer wrote: post #66
forgotpwd16 wrote: post #58

Earlier quoted context omitted.

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.

Nim is getting very close to Rust in terms of safety (but without the verbose ownership management) https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc... https://nim-lang.org/blog/2020/12/08/introducing-orc.html

Memory safety with GC is easy. Rust is novel because it offers memory safety without GC. Your links mention GC.

Re: Nim 2.0 thoughts

#99

Post by ferdowsi »

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?

Including inheritance in nim was a design mistake and is enough to make me pass on it. Go and Rust were correct in avoiding inheritance in the language.

Re: Nim 2.0 thoughts

#100

Post by iamcreasy »

nimmer wrote: post #63
eikenberry wrote: post #55

Earlier quoted context omitted.

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.

Nim compiles to C and then runs GCC (not LLVM) to compile the binary. Overall, it's much faster than Go and Rust.

Is transpiled C readable?
Post reply on HN