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

Author of “Unix in Rust” Abandons Rust in Favour of Nim

github.com

Post reply on HN
Print view View original

81–86 of 86 posts

Re: Author of “Unix in Rust” Abandons Rust in Favour of Nim

#81

Post by GravityWell »

codexon wrote: post #43
jwecker wrote: post #17

We just switched from Rust to Nim for a very large proprietary project I've been involved with after rejecting proofs of concept in Go and Erlang earlier in the process. This despite the fact that we had formally decided on Rust, had tons of code developed in it, and only stumbled upon Nim by complete accident randomly one day. Even though many large components were already developed in Rust we have already reached p…

I love how Nim is getting along but I am rather afraid to put in production. The number of compiler bugs is a bit scary. https://github.com/Araq/Nim/labels/High%20Priority And also from what I've heard, the tooling isn't very good. Autocomplete isn't context sensitive and using GDB to resolve a variable like "foo" actually becomes "foo_randomnumber".

> The number of compiler bugs is a bit scary.

I see similar lists for GCC when a branch is underway. I'm actually impressed with the number of active contributors, and I find the design very compelling. I'll be keeping an eye on this project.

Re: Author of “Unix in Rust” Abandons Rust in Favour of Nim

#82

Post by aidenn0 »

pcwalton wrote: post #61
aidenn0 wrote: post #7

Earlier quoted context omitted.

> Not sure compiling to C as an extra step is going to do to reliablity or performance in Nim but we'll see. Interesting times. Having worked with languages that target C, machine code and C, I will make a few predictions: Compiling to C shouldn't hurt reliability anymore than compiling to LLVM. Performance will likely be somewhat less, particularly as "readable C" is the target, not arbitrary C. > Basically he likes…

> Compiling to C shouldn't hurt reliability anymore than compiling to LLVM. How does Nim deal with the fact that null pointer dereferences, signed integer overflow, and shifts by more than the width of a type are undefined behavior in C, and therefore the optimizer can cause memory safety problems if they occur? Edit: I just tested myself: - Nim emits checks for signed overflow, but they don't seem to optimize to `jo…

Okay, that's just bad[1]. It's not hard to avoid the undefined behaviors in C with machine generated code; it's not that there are a lot of undefined behaviors, just that they are often non-intuitive. A computer doesn't care if they are intuitive or not, so avoiding them in code-gen isn't that hard.

It sounds like Nim passes the lack of safety of C up to the user a bit (e.g. in the null pointer dereferences) in exchange for improved performance.

1: And by "bad" I mean "not a tradeoff I would make." I actually can see good reasons for doing so, it just doesn't fit my priorities.

Re: Author of “Unix in Rust” Abandons Rust in Favour of Nim

#83

Post by e12e »

jwecker wrote: post #17

We just switched from Rust to Nim for a very large proprietary project I've been involved with after rejecting proofs of concept in Go and Erlang earlier in the process. This despite the fact that we had formally decided on Rust, had tons of code developed in it, and only stumbled upon Nim by complete accident randomly one day. Even though many large components were already developed in Rust we have already reached p…

As for scripting: I just tested on Debian Jessie, and at least for trivial code (read: not nim itself) -- nim seems quite content to work with tcc. Tcc is a pretty awful choice for c compiler in general -- but while my current desktop is a little too fast to be able to tell -- nim w/tcc was typically as fast on first compile (read: compiler not cached in ram) as clang/gcc were on second run). Honestly, on this box:

    time ./bin/nim --cc:tcc c -r examples/hallo.nim
vs

    time ./bin/nim --cc:gcc c -r examples/hallo.nim
    time ./bin/nim --cc:clang c -r examples/hallo.nim
is a toss-up -- and they all lose against:

    time python3 -c 'print("Hello, world")'
(by an order of magnitude that ends up being almost insignificant, it's ~0.5 seconds for clang/gcc on first run, ~0.2 seconds for tcc and ~0.02 seconds for python). But the binary tcc makes runs in ~0.001 -- or basically too fast to time -- gcc/clang versions are presumably faster).

Normally I think the startup time for python is less than instant (especially without dropping some standard includes/search with -sS) -- but apparently when running on a quad-core i7 at ~4Ghz with the OS on an SSD -- it makes no practical difference. I'll try later on my slower laptop (which is slow enough that "python -c "print('hello')"" doesn't feel quite instant) -- but the main point I wanted to make was that nim -c -r with --cc:tcc makes for a quite usable "scripting" tool, thanks to tcc's compilation/startup/parsing speed (if nim w/gcc/clang wasn't fast enough already).

Re: Author of “Unix in Rust” Abandons Rust in Favour of Nim

#84

Post by renox »

pcwalton wrote: post #19
acomjean wrote: post #3

Basically he likes the way Nim compiles to C fairly cleanly. Helps him because he knows and understands C, and reading between the lines he wants to target systems that already have C compilers, but not Rust ones. He seems to like Rust it just likes Nim better, feels currently its better suited. Actually fairly calm about it. Different people prefer different languages for a variety of reasons. Not sure compiling to…

> Not sure compiling to C as an extra step is going to do to reliablity or performance in Nim but we'll see. Interesting times. At least as far as Rust is concerned, I firmly believe that compiling to LLVM IR was the right choice. When you compile to C, you're limited by what the language gives you, so you're out of luck if you want to annotate the IR with optimization info like GC metadata, precise aliasing info, or…

Also it allowed Rust devs to define an interesting semantic for integer overflow (trap on debug, on release either trap or contain an undefined value) I don't think that they would have been able to use the 'undefined value' vs 'undefined whole program' if they had chosen to generate C.

Re: Author of “Unix in Rust” Abandons Rust in Favour of Nim

#85

Post by throawai »

keyle wrote: post #76
tokyo1000 wrote: post #18

What is Nim's community like? I ask because I first learned about Nim a few weeks ago when some people were chatting about it on Slashdot. One comment [ http://slashdot.org/comments.pl?sid=6771453&cid=48860921 ] quoted from that day's Nim irc logs and well it was a little disturbing. There was a lot of insulting and name calling going on and it didn't leave a good impression on me. I don't want to judge the entire Ni…

I've hung in the nim community for a few weeks and I've found them extremely helpful. You do get heated arguments but it goes to show the passion. Do not let a few individuals showing off their bullying skills turn you off from a wonderful programming language. IRC is IRC.

You've been hell banned. Message the mods. Best of luck.

Re: Author of “Unix in Rust” Abandons Rust in Favour of Nim

#86

Post by strcat »

Araq wrote: post #63
pcwalton wrote: post #61

Earlier quoted context omitted.

> Compiling to C shouldn't hurt reliability anymore than compiling to LLVM. How does Nim deal with the fact that null pointer dereferences, signed integer overflow, and shifts by more than the width of a type are undefined behavior in C, and therefore the optimizer can cause memory safety problems if they occur? Edit: I just tested myself: - Nim emits checks for signed overflow, but they don't seem to optimize to `jo…

Shrug , you left out: - Conservative GC marking of the stack. - No stack overflow check in release mode. Compiling to C is not tricky, it is horrible and we don't do it for the fun of it! That said, clang has lots of options to tame C's undefined behaviour. Guess what, you can enable these too for C code generated by Nim.

> - No stack overflow check in release mode.

-fstack-check in GCC guarantees that the guard page will be hit (as long as there is one), assuming no undefined behaviour like buffer overflows. It has a negligible cost and should really be enabled by default. It only has to add a one byte write per uninitialized page on the stack, and a less efficient dynamic alloca due to probes.

Post reply on HN