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

Nim version 2.0.0 release candidate

nim-lang.org

Post reply on HN
Print view View original

71–80 of 121 posts

Re: Nim version 2.0.0 release candidate

#71

Post by cb321 »

elcritch wrote: post #68
diimdeep wrote: post #65

In my understanding, Nim at the moment is really a transpiled language, instead of compiled. Transpiled to C, then tooling uses clang or gcc to do compilation from C to target platforms. It is like TypeScript to JS in C/C++ world. Very clever to stand this way on the shoulders of giants, but the amount of moving parts is staggering and horrifying.

The distinction between compilation and transpiling is a bit imprecise, but yes. But oddly the basic C that Nim compiles to is fairly resilient and stable. I'd actually expect the Nim compiler to bitrot way less than languages based on LLVM, which have a very short half life. So Nim's approach has some challenges, but surprisingly has less moving parts than you'd think. I'd be confident I could get the current Nim co…

Besides @elcritch's and @pjmlp's excellent points {language "level" is vague & all compilers translate}, C as a backend target has other virtues (though is by no means The Only Way). E.g., TinyC/tcc optimizes for time to compile (it is a single pass over its input) not generated object code qualities like run-time/file-size. This can give Nim code almost interpreter-like edit-compile-debug devel cycles, but even just changing the default gcc -Og to gcc -O0 can be a huge improvement. [1] (`passL:"-lm" --mm:markAndSweep` and recently `--threads:off` became necessary for tcc due to atomics/C11 dependencies, but it is already a kind of "debugging compilation mode".) Similarly, work on space-saving/alternate libc's like musl [2] can be leveraged, [3] although using `config.nims`/NimScript can also lengthen compile-times by 100 milliseconds or so.

[1] https://forum.nim-lang.org/t/8677 [2] https://musl.libc.org/ [3] https://github.com/kaushalmodi/hello_musl/blob/master/config...

Re: Nim version 2.0.0 release candidate

#72

Post by pjmlp »

diimdeep wrote: post #65

In my understanding, Nim at the moment is really a transpiled language, instead of compiled. Transpiled to C, then tooling uses clang or gcc to do compilation from C to target platforms. It is like TypeScript to JS in C/C++ world. Very clever to stand this way on the shoulders of giants, but the amount of moving parts is staggering and horrifying.

It is a compiled language, how the backend is implemented it is an implementation detail, transpiled was a term the JS community came up with, which you won't find in languages like Eiffel that always compiled to native code via C for the last 30 years.

Or C++ and Objective-C in their yearly days, or the P2C Pascal compiler from 40 years ago.

Re: Nim version 2.0.0 release candidate

#73

Post by pjmlp »

actuallyalys wrote: post #19
wyldfire wrote: post #15

Earlier quoted context omitted.

> Has anybody had the opportunity to compare the costs and benefits? Heap allocators are very significant cost over stack. Nim's designed for different use cases. Rust statically checks memory usage, and provides Arc for use cases that can only be modeled dynamically.

The name is confusing, but Nim's Arc is not the same as Rust's: https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc... . Rust (and apparently Swift) uses Arc to refer to atomic reference counting, whereas Nim's means automatic . There's still overhead, but it would be more comparable to Rust's Rc, I believe.

Swift uses ARC to mean automatic, and its use comes from Objective-C's ARC.

Re: Nim version 2.0.0 release candidate

#74

Post by throw827474737 »

diimdeep wrote: post #65

In my understanding, Nim at the moment is really a transpiled language, instead of compiled. Transpiled to C, then tooling uses clang or gcc to do compilation from C to target platforms. It is like TypeScript to JS in C/C++ world. Very clever to stand this way on the shoulders of giants, but the amount of moving parts is staggering and horrifying.

C seen by some for a long time as a "high-level" assembler :D, and if you choose a safe subset.. and given also e.g. how the LLVM pipeline and other compiling works, and how old and widespread C is, I think it is a clever portability and reuse a lot approach, and the fear of too many parts is exaggerated and not much different from other transpiling&compiling (that difference is also very blurry one and depends on viewpoint, don't think there is one precise definition for that?) pipelines... also not the first to do so.

Re: Nim version 2.0.0 release candidate

#75

Post by isofruit »

_Wintermute wrote: post #2

As a casual nim user, there's plenty I probably don't appreciate enough in there, but thing I'm most looking forward to are the default values for objects.

I am looking forward to them supporting distinct DateTime types (basically used-defined clones of the DateTime type with custom behaviour). Currently using the constructor package to do the same thing, but being able to throw out a dependency is always nice.

Re: Nim version 2.0.0 release candidate

#76

Post by elcritch »

samsquire wrote: post #25
zozbot234 wrote: post #20

Earlier quoted context omitted.

If you want good multithreaded support and don't care much about ensuring perfect thread-safety at all times, you can't beat Go for real-world use.

Yes I like Go but I am yet to do any professional development in it. Go is a M:N scheduler with M kernel threads and N lightweight threads I wrote a 1:M:N lightweight scheduler which preempts hot loops. I don't know when Golang preempt goroutines outside of a channel send - I believe it's in stack growth or in other words when a method is called. My userspace scheduler preempts while true and for loops by setting the…

No, not directly but Nim supports async. Effectively it turns the function into an Iterator whose state can be passed around. Those are put into Futures.

Its possible to write your own async engine, or you could use the iterator yourself if you really wanted. It's actually not too hard.

Checkout: https://github.com/status-im/nim-taskpools

Edit: also Nim compiles to C, so its possible to do whatever you can do in C with a bit of fiddling. Also theres coro https://nim-lang.org/docs/coro.html

Re: Nim version 2.0.0 release candidate

#77

Post by isofruit »

zozbot234 wrote: post #16
synergy20 wrote: post #14

among nim, zig and rust, I'm most likely to learn nim, it has been there for a while and it is solid and has so many good stuff in it, it just needs more 'marketing'. in particular, python really should help its popularity as their syntax are similar and both are very expressive.

Is syntax really that big of an obstacle to learning a first programming language? The semantics of a C-like language like Nim could hardly be more different to Python's, they're pretty much at opposite ends in the stack.

It can be. I would've loved to pick up Rust, the patterns for code structuring etc. that are evolving from it seem interesting to me. But getting the syntax right is just fairly difficult compared to other languages and at some point you just lose your patience. At the same time there's not enough learning material that works for me to dive into the deeper contexts to make it "click" for me.

Contrasting that to my experience with nim, I could get going almost immediately and thus didn't get held up much with the basics, which gave me more time to dive into more interesting concepts that it provides, like templates, compile-time-evaluation (new for me as a pythonista back then), macros etc.. I still got stuck here and there, mind you, but that was for more complex question than "How do I get a config from place X without the compiler yelling at me", and the discord was very helpful for that.

Re: Nim version 2.0.0 release candidate

#78

Post by planetis »

snthpy wrote: post #49
v3ss0n wrote: post #47

Earlier quoted context omitted.

Nim community is pretty much against python developers. The founder is vocal about that.

There's my problem with nim. I was really excited about it two years ago and tried to get into it. Unfortunately I found the community not very welcoming. All the issues I had, had been raised before and dismissed. I've since switched to Rust. The syntax isn't quite as nice but it's outweighed by the fact that the community is great and the memory safety is a game changer!

My problem with rust, is that community is overzealous to promote their language, even in the cost of spreading lies and misinformation and harassment. I was routinely attacked by anonymous accounts. The common thing they say is people using other language than rust are dumb. A few weeks ago some people joined the nim discord and besides promoting rust, they started name calling. I stay miles away from rust, it has by far the worst community. It's shameful.

Re: Nim version 2.0.0 release candidate

#79

Post by TylerE »

geenat wrote: post #56

Default values and named parameters, thank you! Golang has neglected both of these. Both seemingly rare yet highly productive features to be found in a compiled language. Love the quick compile times and go-like single binary compilation. Case-insensitivity seems very cool for interoperability. Total underappreciated gem. My only hangup is the syntax feels wordy, but it's leagues better compared to Rust or Go in that…

Macros shouldn’t have any performance implications.

The whole point is that they happen at compile time.

Re: Nim version 2.0.0 release candidate

#80

Post by TylerE »

diimdeep wrote: post #65

In my understanding, Nim at the moment is really a transpiled language, instead of compiled. Transpiled to C, then tooling uses clang or gcc to do compilation from C to target platforms. It is like TypeScript to JS in C/C++ world. Very clever to stand this way on the shoulders of giants, but the amount of moving parts is staggering and horrifying.

What isn’t these days?

Even the C code (on many platforms) is going to transport to LLVM IR

Post reply on HN