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

71–80 of 86 posts

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

#71

Post by tokyo1000 »

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.

What if that's just because people have fewer problems with Nim than they have with Rust? The number of SO questions is a better measure of how often and how many people run into problems than it is a measure of overall popularity.

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

#72

Post by parley »

jwecker wrote: post #70
parley wrote: post #45

Earlier quoted context omitted.

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 determinis…

Thanks for your reply! An enjoyable exchange in the midst of what often feels like a bit of a very tiring flame war.

I am constantly on the lookout for languages that could be suitable for replacing (or greatly diminishing) the use of C/C++ in my work, and so far Rust is one of the front runners.

However, I am also very much aware of some of the troubles I would most likely face in convincing my colleagues, like language complexity and productivity, and I completely respect the decision that it may not be worth it, depending on a wide variety of factors.

I try to keep an open mind, and I look forward to reading more about the improvements to Nim you envision! Thanks again (and good night). :)

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

#73

Post by omaranto »

steveklabnik wrote: post #32
omaranto wrote: post #30

Earlier quoted context omitted.

LLVM's optimization passes are pretty awesome, but so are GCC's. My guess is that both methods can get you good performance, and that what performance you do get depends on how good the LLVM bitcode or C you generate is. I've tried using Rust and Nim for very small programs (Project Euler problems and some text munging), and currently it seems to me that (1) Nim's executables are always a little faster than Rust's (b…

One reason you may find text munging to be faster in Nim is that we have an different algorithm than they do that's better in the worst case but slower in many small cases. Plus, Rust's are UTF-8 aware by default, and Nim's are not. (This doesn't mean that it's still not the same from a user's perspective, just explaining a bit about why, and that this might change in the future.)

Those are good points about string processing (and I wasn't aware of them, thanks!), but when I said Nim programs typically run a little faster I didn't mean only text munging, also my Project Euler type code: lots of loops, arrays randomly accessed and integer arithmetic. For those numeric programs the difference is pretty small, so maybe it's just the same slight edge that GCC sometimes has on Clang. (I guess I could try installing Clang, recompiling the Nim programs with Clang instead and checking if that brings their performance closer to the Rust ones.)

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

#74

Post by pcwalton »

jwecker wrote: post #70
parley wrote: post #45

Earlier quoted context omitted.

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 determinis…

> 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'm not so sure. The trickiest part of getting memory safety without garbage collection working is not the lifetimes but the borrow check, which relies on inherited mutability and, most importantly, the lack of aliasable mutable data. The APIs and libraries of garbage collected imperative languages invariably depend on aliasable, mutable memory. Consider something as simple as a tree or graph data structure with mutable nodes. Or consider taking two mutable references to different indices of an array, or splitting an array into mutable slices with dynamically computed indices. These are all things you (presumably) can do today in Nim, and a borrow checker would break them. The likelihood that the library APIs depend on being able to do it is very high.

I never say never: you could implement multiple types of references, some GC'd and some not, and copy the Rust borrowing semantics. But they would be incompatible with most existing APIs and libraries. I don't think it can be realistically retrofitted onto a language without breaking most APIs: aliasable, mutable data is just too common.

Regarding efficiency/performance, what in particular seems impossible to add to Rust?

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

#75

Post by Mikeb85 »

def- wrote: post #53
Mikeb85 wrote: post #48

Earlier quoted context omitted.

It's possible. I personally just hope that Araq and others keep working on it. Right now it's quite easy to use without a lot of libraries written in Nim, because of interoperability. Besides, I see Nim more as a 'secret weapon' sort of language, or something that individual programmers use. Rust is more of a 'big idea' language, so it makes sense a corporation is pushing it.

> Rust is more of a 'big idea' language, so it makes sense a corporation is pushing it. Araq just announced that Nim has financial backing now: http://forum.nim-lang.org/t/870

Fantastic. And thanks for that link. I was messing around with some 3D stuff in Nim, and he's working on 3D C++ stuff too I see...

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

#76

Post by keyle »

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.

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

#77

Post by jostmon »

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.

This is actually one of the things that keeps turning me away each time I try Nim. All software has bugs, got it, but in my mind a language nearing 1.0 should squash some of that list (or remove/feature gate things causing them) before even thinking about a 1.0 IMO.

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

#78

Post by jostmon »

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…

Have you read the following article?

https://gradha.github.io/articles/2015/02/goodbye-nim-and-go...

I'm curious about your thoughts on it being that the author speaks about some areas you're currently talking about.

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

#80

Post by dom96 »

jostmon wrote: post #77
codexon wrote: post #43

Earlier quoted context omitted.

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. This is actually one of the things that keeps turning me away each time I try Nim. All software has bugs, got it, but in my mind a language nearing 1.0 should squash some of that list (or remove/feature gate things causing them) before even thinking about a 1.0 IMO.

In my opinion, 1.0 is about the language specification becoming stable. That said, some experimental features have actually been gated in preparation for the 1.0 release.
Post reply on HN