Live data from Hacker News

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

github.com

51–60 of 86 posts

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

#51
post #9
post #4

I think the reasoning is sound, but this isn't an indication of either language being better than the other. Only that it's easier to look under the hood of Nim. I find Nim easier to read, and then as is with ruby, probably more productive for prototypes, but I'd like to see more use cases before I start to move in that direction. It does make me wonder if we'll ever see a Nim to rust transpiler.

2 different languages for 2 different use cases. Seems to me that Nim is more in league with Go and D while Rust is lower level with some syntactic sugar. Might be wrong but that's how I feel about these. Anyway it's great to have new french languages that you can still link to C libs when you need it.

I would agree. I don't think they compete directly, the only real similarities is they both compile to native code, and both are fast.

Nim is more of a Pascal/Python/Coffeescript hybrid with easy interoperability with C and nice tooling.

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

#52
post #48

Earlier quoted context omitted.

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.

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.

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

I don't think that "big idea" languages [1] are necessarily the provenance of corporations/committees as opposed to individuals. If anything, the opposite tends to be true, as large languages such as C++ and C# have tended to grow to encompass more and more features over time as their feature sets expand to accommodate more and more stakeholders. Rust in particular started out as an individual project, with a set of design constraints—those of low-level memory-safe systems programming—that have remained unchanged throughout its lifetime.

[1] I'm not really a fan of that term anyway, as "big ideas" are just design constraints, things that all languages have. Rust just happens to have a unique (among industry languages, save maybe ATS) set of them.

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

#53
post #48

Earlier quoted context omitted.

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.

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

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

#54
post #44

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 would say it is unfair to judge any language by their IRC channel unless they are core members of the group. In my experience IRC channels being rude is the norm rather than the exception.

> In my experience IRC channels being rude is the norm rather than the exception.

But it doesn't have to be that way. Rust has a very clear code of conduct (http://www.rust-lang.org/conduct.html) aimed at avoiding exactly that kind of rudeness, and it has so for a long time. As a result the #rust IRC channel is a very pleasant place to be.

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

#55
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…

To be fair to Nim, I don't see any reason why it couldn't be made memory safe by using the Boehm GC (though I'm not an expert in Nim by any means). Of course, using the Boehm GC negates the advantages of the thread-local heaps, but I don't think that Nim's implementation of them scales up to large-scale software in any case for the reasons I detailed in my other comments. IMHO, if you have a garbage-collected, multit…

Thanks for correcting me, Patrick. I certainly didn't mean to be unfair (especially as I replied to a comment I felt wasn't being completely fair itself, intentionally or not), and I should have been more precise about the use cases.

I agree about the GC considerations. I meant my points to mainly apply to the use cases where safety such as that offered by Boehm is eschewed in order to achieve other powers at its expense, which I feel is brought up a lot by Nim proponents as strengths during these discussions.

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

#56
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…

So since this is such an amazing language.. I wonder why it doesn't have a Wikipedia article? Oh, wait.. I remember. Its because Wikipedia admins are an incestuous cabal and will do anything to avoid admitting one of them was wrong. Or because Wikipedia in general is a joke.

Think I an exaggerating? I believe this is the best programming language out there. Just try to add a Wikipedia article. Not in a million years.

The Wikipedia notability rules and process are ridiculous and completely unfair, when every porn star, popular smut video on the internet, rare mushroom, and Pokemon DVD has an article.. But the best programming language in the world cannot.

This is an example of what is wrong with our society.

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

#57
post #50
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…

> The claim about being able to do "so much more at a low level", like e.g. being able to switch out libc variants, which allegedly is not possible in Rust due to accidental coupling. Is this a temporary difference? If so, it may only be relevant in the short term. I can't answer this question, but it would be interesting if someone did. It's definitely intended that the Rust standard library can compile against many…

Thanks for clearing that up!

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

#58

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 am from the Smalltalk community (very, very friendly) and just recently got into Nim but my experiences so far has been positive. Sure, more "heated discussions", but I have so far attributed that to possibly younger participants and also a strong IRC presence. I would also say that most of the harsh language I have seen has had a "tongue in cheek" tone to it. Also, I would claim its a very selected few people that like to engage in that kind of heat - thus not representative in any way. But also good that its brought up - I don't like such a tone either.

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

#59

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…

You're right, a more hands-on approach is needed. We've discussed it a bit, and no opposition has been raised to using +q more often.

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

#60
post #12
post #11

Isn't Nim GCed? How are you going to build a kernel like that?

GC in Nim is highly configurable: you can pause GC or even delay it indefinitely. Plus there's lots of tweaks you can make to how GC treats your code using Nim's pragma system. And no, the standard library does not rely on GC like in D.

> And no, the standard library does not rely on GC like in D.

This isn't correct, it relies heavily on GC.

Post reply on HN