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

61–70 of 86 posts

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

#61

Post by pcwalton »

aidenn0 wrote: post #7
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. 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`. Nim should be emitting these intrinsics where possible: http://clang.llvm.org/docs/LanguageExtensions.html#checked-a...

- Nim does not emit checks for shifts by more than the width of a type. Therefore you can get undefined behavior.

- Nim blindly dereferences null pointers, which is undefined behavior. In fact, I managed to get clang to optimize out the null pointer check here:

    echo("Counting to ten: ")
    for i in countup(1, 10):
        var k: ref int = nil
        var l = k[]
        echo($l)
In debug mode, this program throws an exception; in release mode, this program prints zero over and over for me, because clang optimized out the null pointer dereference per C semantics. I could probably make this program write arbitrary memory without using any of Nim's unsafe features.

I'm not sure if all three of these are Nim bugs, but they seem like it. Compiling to C is tricky.

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

#63

Post by Araq »

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…

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.

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

#64

Post by chipsy »

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…

Everybody was embarrassed about that day. It was a lot of toxicity over an issue that had already been resolved in technical terms, and dragged on for hours, but Andreas was mostly gracious throughout. I give him a lot of credit for being willing to trade blows with aggressive users without using Linus-style shame tactics himself. However there is also some recognition of how disruptive it is to allow discussion to spiral out of control like that. The channel is considering a more policy-driven approach to handling these kinds of situations. It has never banned anyone in its history to date, but it may have to cross that bridge soon.

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

#65

Post by def- »

marijn wrote: post #62

Last time I looked at Nim, I was put off by the lack of algebraic data types and pattern matching. I still can't find anything about them in the manual. Am I missing something, or is this something it just doesn't have?

Instead of ADTs there are object variants in Nim: http://nim-lang.org/manual.html#object-variants

With ADTs:

  data Shape a =
    Rectangle
      { x :: Float
      , y :: Float
      , width :: Float
      , height :: Float
      }
    | Circle
      { x :: Float
      , y :: Float
      , radius :: Float
      }
With Object Variants, note that we don't have to repeat x and y:

  type
    ShapeKind = enum Rectangle, Circle
  
    Shape = object
      x, y: float
  
      case kind: ShapeKind
      of Rectangle: width, height: float
      of Circle: radius: float
The pattern matching in Nim is quite limited. Something like this works:

  let (x, y) = getCoordinates()
But Nim doesn't have (x,y) = (y,x) for example, instead swap can be used.

You could implement your own pattern matching using metaprogramming: http://www.drdobbs.com/open-source/nimrod-a-new-systems-prog...

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

#66

Post by agumonkey »

kevin_thibedeau wrote: post #47
Mikeb85 wrote: post #39

Having played with both Nim and Rust, I also prefer Nim. Basically Rust is a slightly more pleasant C++, but still huge, complicated, things break all the time, and there's no IDE support to help you make sense of anything. It's probably more robust, maybe faster as things get big, but I haven't got there yet. Nim is as easy to write as Python, the toolchain is very easy to set up, creating Nim interfaces (with docum…

It's a shame that it doesn't have the mindshare: 27 nim/nimrod questions on SO, 1548 rust. Still not "notable" enough for a Wikipedia entry. I can see nim getting stuck lingering on the margin like Objective-C did before OSX.

Is there a flagship project using Nim ? Rust has Servo. I've read here and there that this is the best way for a language to catch on.

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

#67

Post by proveanegative »

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…

Could you elaborate a little about why you rejected Erlang?

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

#68

Post by pcwalton »

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.

> 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.

They aren't really designed for performance though. For example, `-fsanitize-undefined-trap-on-error -fsanitize=null` emits explicit comparisons against null for every pointer load instead of catching SEGV like (for example) Java or Go do.

From what you're saying it sounds like maximum performance plus memory safety isn't a design goal for Nim. That's totally reasonable. It does mean that Nim and Rust have very different aims, however, and comparisons between the two need to take this into account.

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

#69

Post by jwecker »

proveanegative wrote: post #67
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…

Could you elaborate a little about why you rejected Erlang?

I actually coded a predecessor to the system under development a few years ago and have used Erlang and more recently Elixir a lot, but in the end it just wasn't low-level enough, fast enough, or runtime-free-enough for our current project (for example we need to generate real-time processing kernels that can run on GPUs and FPGAs-- a realm not even really contemplated at the Erlang level).

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

#70

Post by jwecker »

parley wrote: post #45
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 also apologize beforehand for a long reply. Long posts get long replies. I can definitely understand this point of view, but I just can't agree. The parent probably wants his/her claim that Nim seems as memory-safe as Rust to not be interpreted literally, as a literal interpretation would make the statement false (by any fair comparison using idiomatic code from both languages to accomplish the same thing). What th…

Thanks for the thoughtful response- it didn't come across as combative at all to me.

The true, provable safety of Rust was what drew me to it as well. I've always hated having to choose between un-principled memory management (with it's security and functionality vulnerabilities that can lie dormant for many years before kicking your butt) and garbage-collection forcing you away from the metal and removing deterministic reasoning about memory usage, runtime behavior, and runtime overhead.

I've been going through the academic papers, forerunners, and source-code for Rust's static memory routines and borrowing semantics. My hope and suspicion is that it can be added to Nim without core changes to the language like lifetimes. It's definitely not a guarantee, but with lots of experience in both languages now I feel very strongly that adding region-based-memory-management to Nim is possible while adding Nim's clarity, abstractions, and efficiency to Rust feels impossible.

I agree that at the moment Rust is the only responsible choice right now if provable memory safety is a primary concern, but I suspect that will change. In the mean-time, for us anyway, the price was too high in productivity when we discovered that we could do manual memory management in Nim in very well-considered isolated places and confidently use Nim's fast, real-time deterministic per-thread garbage-collection for everything else without a noticeable performance penalty.

Having said that, I don't think I actually disagree with anything you said (:

Post reply on HN