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

Mastering Nim – now available on Amazon

nim-lang.org

Post reply on HN
Print view View original

71–80 of 106 posts

Re: Mastering Nim – now available on Amazon

#71

Post by forgotpwd16 »

deltaonefour wrote: post #37

There's 3 languages in the same class. Julia, Nim and Crystal. I'm specifically curious about Crystal vs. Nim. Benchmarks show that crystal is pretty much faster, but I'd also like to know the advantages of why someone would choose Nim over Crystal I'm looking for reasoning that is deeper then just superficial language syntax differences. Has anyone extensively used both? I would like an unbiased view from someone wh…

Julia isn't in the same class and workflow usually differs significantly from the others.

Re: Mastering Nim – now available on Amazon

#72

Post by nimmer »

greybox wrote: post #67
127 wrote: post #44

Earlier quoted context omitted.

My experience after a couple of weeks: Pros: Extremely good C and C++ interop Significant indentation Very good performance Quick compilation Terse, but readable Easy cross platform Powerful macros and close to trivial DSL construction Very little code to do a lot of stuff Incoming future features look very promising Cons: Hard to predict and control program performance, LTO does a lot of heavy lifting Immature ecosy…

I love nim, but I disagree with the "quick compilation" point here. The compilation is horrendously slow. (by default it compiles down to C, then to exe from there).

It's much faster than C++, Rust, Go and many others.

Re: Mastering Nim – now available on Amazon

#73

Post by planetis »

127 wrote: post #44
brightball wrote: post #17

Earlier quoted context omitted.

That’s how I feel about Elixir. Everything else just feels wrong now. I’d be curious to get your Nim highlights.

My experience after a couple of weeks: Pros: Extremely good C and C++ interop Significant indentation Very good performance Quick compilation Terse, but readable Easy cross platform Powerful macros and close to trivial DSL construction Very little code to do a lot of stuff Incoming future features look very promising Cons: Hard to predict and control program performance, LTO does a lot of heavy lifting Immature ecosy…

> Many libraries have bugs, missing features or just a very clunky API. Or maybe they are deprecated or abandoned all together.

For me missing libraries never stopped me, I could always port/wrap whatever I needed. However with the advent of AI assisted coding, working on libraries is even faster and at some point I hope I wouldn't spend much time rolling decent libraries that are ports of existing github projects.

Re: Mastering Nim – now available on Amazon

#74

Post by konkordat »

dmitriid wrote: post #35
auggierose wrote: post #10

Earlier quoted context omitted.

An e-book is going to heavily (and negatively) impact the sales figures for the print book. So I wouldn't hold out for that. Looking at the price of the book, he wants to make money from it, so no e-book is probably the right strategy.

> Looking at the price of the book, he wants to make money from it The price of a printed book includes: - the price of materials - the price of printing - the price of transportation - the price of storage - the margins and profits of all of the above - the margins and the profit of the store And then, and only then, the author making money, if any. How is e-book going to impact the author's profit, exactly?

Manufacturing of a book is really cheap. It's just a little part of overall cost. Nowadays it may cost more becauase of higher prices of paper. Everything else is managed by amazon for their cut. Stop shilling. The author is just greedy.

Re: Mastering Nim – now available on Amazon

#75

Post by zimpenfish »

nimmer wrote: post #72
greybox wrote: post #67

Earlier quoted context omitted.

I love nim, but I disagree with the "quick compilation" point here. The compilation is horrendously slow. (by default it compiles down to C, then to exe from there).

It's much faster than C++, Rust, Go and many others.

I'm assuming this must be for huge projects?

I just compiled my toy project (detecting anomalous parity in integers) in nim 1.6.6 (4.23s), go 1.17.7 (2.43s to create both aarch64 and x86_64 binaries), zig 0.8.0-dev.1140 (2.04s to create aarch64 and x86_64 binaries) and C via clang 13.1.6 (0.14s).

nim's compilation is 175% of Go, 207% of zig, and 3021% of clang.

Re: Mastering Nim – now available on Amazon

#76

Post by Rochus »

zimpenfish wrote: post #75
nimmer wrote: post #72

Earlier quoted context omitted.

It's much faster than C++, Rust, Go and many others.

I'm assuming this must be for huge projects? I just compiled my toy project (detecting anomalous parity in integers) in nim 1.6.6 (4.23s), go 1.17.7 (2.43s to create both aarch64 and x86_64 binaries), zig 0.8.0-dev.1140 (2.04s to create aarch64 and x86_64 binaries) and C via clang 13.1.6 (0.14s). nim's compilation is 175% of Go, 207% of zig, and 3021% of clang.

Thanks for the data; that's what I call an elegant rebuttal.

Re: Mastering Nim – now available on Amazon

#77

Post by nimmer »

zimpenfish wrote: post #75
nimmer wrote: post #72

Earlier quoted context omitted.

It's much faster than C++, Rust, Go and many others.

I'm assuming this must be for huge projects? I just compiled my toy project (detecting anomalous parity in integers) in nim 1.6.6 (4.23s), go 1.17.7 (2.43s to create both aarch64 and x86_64 binaries), zig 0.8.0-dev.1140 (2.04s to create aarch64 and x86_64 binaries) and C via clang 13.1.6 (0.14s). nim's compilation is 175% of Go, 207% of zig, and 3021% of clang.

No, even small files. You must have issues with your setup. Are you sure your compiler is not built in debug mode?

Re: Mastering Nim – now available on Amazon

#78

Post by vegai_ »

frigid wrote: post #55
danielvaughn wrote: post #15

Earlier quoted context omitted.

Care to give a brief overview of what you find appealing? I've never looked into the language before.

I particularly like, from the syntax side: - Python-style syntax with significant indentation - Uniform Function Call Syntax: a.len() == a.len == len(a) - Fully unqualified imports by default: which might seem scary to Python programmers, but works great in practice because of static typing - All of the above makes code readable and succinct And from a language features side: - Compiles to C with all the architectura…

>- Uniform Function Call Syntax: a.len() == a.len == len(a)

a.len() == len(a) seems like a good idea, but I'm not so sure about a.len... Isn't that a bit ambiguous?

Re: Mastering Nim – now available on Amazon

#79

Post by zimpenfish »

nimmer wrote: post #77
zimpenfish wrote: post #75

Earlier quoted context omitted.

I'm assuming this must be for huge projects? I just compiled my toy project (detecting anomalous parity in integers) in nim 1.6.6 (4.23s), go 1.17.7 (2.43s to create both aarch64 and x86_64 binaries), zig 0.8.0-dev.1140 (2.04s to create aarch64 and x86_64 binaries) and C via clang 13.1.6 (0.14s). nim's compilation is 175% of Go, 207% of zig, and 3021% of clang.

No, even small files. You must have issues with your setup. Are you sure your compiler is not built in debug mode?

How would I check that? I installed it through homebrew via https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/... which doesn't seem to mention debug mode anywhere?

Re: Mastering Nim – now available on Amazon

#80

Post by cb321 »

greybox wrote: post #67
127 wrote: post #44

Earlier quoted context omitted.

My experience after a couple of weeks: Pros: Extremely good C and C++ interop Significant indentation Very good performance Quick compilation Terse, but readable Easy cross platform Powerful macros and close to trivial DSL construction Very little code to do a lot of stuff Incoming future features look very promising Cons: Hard to predict and control program performance, LTO does a lot of heavy lifting Immature ecosy…

I love nim, but I disagree with the "quick compilation" point here. The compilation is horrendously slow. (by default it compiles down to C, then to exe from there).

As with most things, "it depends". If you compile very macro compile-time virtual-machine heavy code that can be slow. If you compile to the c++ backend then that backend process can be slow. If you invoke some macro that generates mountains of Nim code translated to continents of C code it can be slow. If you use the default `nim.cfg` that has gcc -Og it can take a lot longer than gcc -O0, for example. Meanwhile, if you use the `tcc` backend even without incremental compilation it can be close to immediate feedback:

    $ touch foo.nim
    $ /usr/bin/time nim c foo.nim
    CC: ../usr/lib/nim/lib/std/private/digitsutils.nim
    CC: ../usr/lib/nim/lib/system/dollars.nim
    CC: ../usr/lib/nim/lib/system.nim
    CC: foo.nim
    Hint: gc: refc; opt: none (DEBUG BUILD, `-d:release` generates faster code)
    36891 lines; 0.154s; 39.434MiB peakmem; proj: /tmp/foo.nim; out: /tmp/foo [SuccessX]
    0.24user 0.02system 0:00.27elapsed 101%CPU (0avgtext+0avgdata 44360maxresident)k
    0inputs+0outputs (0major+13676minor)pagefaults 0swaps
(I point my default backend compiler to tcc in my $HOME/.config/nim/nim.cfg.) There are some more details in this nim forum thread: https://forum.nim-lang.org/t/8677

Unless your standards are "single digit milliseconds per file like tcc itself, please!", 240 ms is not so bad. (EDIT: And this is just on some 2016-era Intel i7-6700k box, not some liquid helium cooled 10 GHz whatever.)

Post reply on HN