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

Nim 1.4

nim-lang.org

Post reply on HN
Print view View original

71–80 of 144 posts

Re: Nim 1.4

#71

Post by cb321 »

Abishek_Muthian wrote: post #67
cb321 wrote: post #62

Earlier quoted context omitted.

Go code runs much more slowly than Nim code in my experience. Nim realizes better ergonomics than Python in some ways (UFCS, command syntax, user-defined operators) and as good performance & lightweightness as C/Rust. I'm honestly surprised Nim is not the secret weapon of many start-ups. Nim is much more "open architecture" instead of pushing some "single, canned turn-key fits most users" solutions. Having a juggerna…

Statement on performance is surprising, I haven't personally benchmarked Nim against Go so couldn't say about that. But I started using Go for the same reasons pointed out in parent and after being tired of changing Python code to C to resolve performance issues. How about concurrency?

There is a link in another of my comments here and because Nim is pretty open architecture you can roll your own basis for what you want (more than most languages) such as: https://github.com/mratsim/weave

Re: Nim 1.4

#72

Post by jimbob45 »

nivviv wrote: post #65
tylorr wrote: post #61

Earlier quoted context omitted.

What's the dev experience been like? Do you feel like there is good editor support for debugging and such?

I've been using vscode+nim. Debugging was mostly just writing correct code in the first place! ;) The only gripe I have is sometimes nimsuggest hanging itself at 100% cpu use, and I have to kill it manually. Even with the rather oldschool approach of echo/logging.nim usage, things tend to turn around quickly. I have not felt the need to be able to attach a debugger to the process, mostly because our architecture is v…

What build system are you using if not MSBuild then?

Re: Nim 1.4

#73

Post by 9214 »

cb321 wrote: post #49
thelazydogsback wrote: post #48

NIM and Red (also on HN today) seem both seem to have an interesting and intersecting feature set. Anybody here used or heavily evaluated both that can comment?

Rebol/Red is more like Python/Cython - able to be fast but falling back to an interpreter for dynamic things. As such there are probably more "performance footguns" (though any such thing is ultimately subjective based on programmer awareness). Nim feels more like what C++ (or Python) should always have been. Not sure if this helps. It's kind of a "big" question.

No, it's actually the other way around: Red and Rebol are interpreted by default, and Red has a bootstrapping AOT compiler capable of bridging it with Red/System (a C-like sub-language), which it turn targets machine code. However, since Red is highly dynamic, compiler cannot preserve semantics across the whole language, so it keeps some parts for the interpreter to process at run-time. And sometimes that's the only option, since code can be generated on-the-fly or pulled over the network: Red is homoiconic and has quite powerful meta-programming facilities on top of that.

Re: Nim 1.4

#74

Post by nivviv »

jimbob45 wrote: post #72
nivviv wrote: post #65

Earlier quoted context omitted.

I've been using vscode+nim. Debugging was mostly just writing correct code in the first place! ;) The only gripe I have is sometimes nimsuggest hanging itself at 100% cpu use, and I have to kill it manually. Even with the rather oldschool approach of echo/logging.nim usage, things tend to turn around quickly. I have not felt the need to be able to attach a debugger to the process, mostly because our architecture is v…

What build system are you using if not MSBuild then?

Our production stuff runs on Linux, so we just wrap it into docker and that's that.

Personally, I develop on Mac and it runs natively there the same as on Linux.

Windows binaries for the tooling releases I used to build with a cross-compiler, but more recently, GH actions looks attractive enough to take that role.

Edit: Sorry, could have been clearer. The build system is just running the binary directly via nim cpp -r in development, and for production it's nimble. The dockerfile is handcrafted, but of trivial complexity.

Re: Nim 1.4

#75

Post by elcritch »

nivviv wrote: post #65
tylorr wrote: post #61

Earlier quoted context omitted.

What's the dev experience been like? Do you feel like there is good editor support for debugging and such?

I've been using vscode+nim. Debugging was mostly just writing correct code in the first place! ;) The only gripe I have is sometimes nimsuggest hanging itself at 100% cpu use, and I have to kill it manually. Even with the rather oldschool approach of echo/logging.nim usage, things tend to turn around quickly. I have not felt the need to be able to attach a debugger to the process, mostly because our architecture is v…

https://nim-lang.org/blog/2017/10/02/documenting-profiling-a... -- Not sure how good the VSCode debugging integration is, but all the requirements are there including gdb/lldb. Word is JetBrains folk wrote a new Nim plugin too. Personally, I like the `writeStackTrace` bit.

Re: Nim 1.4

#76

Post by TylerE »

Abishek_Muthian wrote: post #67
cb321 wrote: post #62

Earlier quoted context omitted.

Go code runs much more slowly than Nim code in my experience. Nim realizes better ergonomics than Python in some ways (UFCS, command syntax, user-defined operators) and as good performance & lightweightness as C/Rust. I'm honestly surprised Nim is not the secret weapon of many start-ups. Nim is much more "open architecture" instead of pushing some "single, canned turn-key fits most users" solutions. Having a juggerna…

Statement on performance is surprising, I haven't personally benchmarked Nim against Go so couldn't say about that. But I started using Go for the same reasons pointed out in parent and after being tired of changing Python code to C to resolve performance issues. How about concurrency?

The performance shouldn't be surprising, as it compiles via C (So it benefits from 50 years of work on C compilers), and almost all of the language constructs compile to essentially equivalent C code.

Re: Nim 1.4

#77

Post by otherme123 »

Abishek_Muthian wrote: post #67
cb321 wrote: post #62

Earlier quoted context omitted.

Go code runs much more slowly than Nim code in my experience. Nim realizes better ergonomics than Python in some ways (UFCS, command syntax, user-defined operators) and as good performance & lightweightness as C/Rust. I'm honestly surprised Nim is not the secret weapon of many start-ups. Nim is much more "open architecture" instead of pushing some "single, canned turn-key fits most users" solutions. Having a juggerna…

Statement on performance is surprising, I haven't personally benchmarked Nim against Go so couldn't say about that. But I started using Go for the same reasons pointed out in parent and after being tired of changing Python code to C to resolve performance issues. How about concurrency?

Nim is on par with C in a lot of benchmarks, e.g. https://github.com/kostya/benchmarks. Go is the king of concurrency, so whatever you compare to it loses. That said, Nim has async/await for concurrency, and I find threads and threadpools easy to use for paralelism.

Re: Nim 1.4

#78

Post by jimbob45 »

nivviv wrote: post #74
jimbob45 wrote: post #72

Earlier quoted context omitted.

What build system are you using if not MSBuild then?

Our production stuff runs on Linux, so we just wrap it into docker and that's that. Personally, I develop on Mac and it runs natively there the same as on Linux. Windows binaries for the tooling releases I used to build with a cross-compiler, but more recently, GH actions looks attractive enough to take that role. Edit: Sorry, could have been clearer. The build system is just running the binary directly via nim cpp -…

So you use Docker to keep the build system unchanged between builds? That’s genius if so and cuts deeply into MSBuild’s main advantage (comprehensively delineated system settings).

Re: Nim 1.4

#79

Post by cb321 »

TylerE wrote: post #76
Abishek_Muthian wrote: post #67

Earlier quoted context omitted.

Statement on performance is surprising, I haven't personally benchmarked Nim against Go so couldn't say about that. But I started using Go for the same reasons pointed out in parent and after being tired of changing Python code to C to resolve performance issues. How about concurrency?

The performance shouldn't be surprising, as it compiles via C (So it benefits from 50 years of work on C compilers), and almost all of the language constructs compile to essentially equivalent C code.

Nim also has an emit pragma where you can just inline C code (or code for the Javascript backend or C++ backend, etc.). So, if there is some poorly optimized (for whatever reason) hot inner loop you can fix it right there, though you start sacrificing portability (often the trade off for optimal performance). You can even do SIMD intrinsics right in Nim no problemo just using the FFI Nim has for C calls.

Re: Nim 1.4

#80

Post by gtrs »

cb321 wrote: post #62
Abishek_Muthian wrote: post #58

Earlier quoted context omitted.

Interesting, thanks for sharing. May I ask, did you consider Go and decided against it for any reason considering your requirements of quick development, cross-platform, interoperability are all guaranteed features of Go which should have given better peace of mind considering a production application?

Go code runs much more slowly than Nim code in my experience. Nim realizes better ergonomics than Python in some ways (UFCS, command syntax, user-defined operators) and as good performance & lightweightness as C/Rust. I'm honestly surprised Nim is not the secret weapon of many start-ups. Nim is much more "open architecture" instead of pushing some "single, canned turn-key fits most users" solutions. Having a juggerna…

The advanced features Nim offers is in stark contrast with Go where simplicity is valued. But the power those features give you when you really need them is undeniable. There's no need to dance around certain problems.

I did move to Go from Python briefly for performance reasons but once I found Nim, there's just no going back. Simplicity might have real value in large projects but I just don't like my hands tied.

Post reply on HN