An idividual drawn to novel immature languages switches their interest as language matures.
Author of “Unix in Rust” Abandons Rust in Favour of Nim
21–30 of 86 posts
Re: Author of “Unix in Rust” Abandons Rust in Favour of Nim
#22Earlier quoted context omitted.
The presence or lack of a GC has nothing to do with the Kernel. The Kernel is simply another program, with specific requirements and limitations. So long as your language allows you to write and call raw assembly, you can write a Kernel. It's worth remembering that Rust has a form of GC as well - it uses a reference counting collection mechanism which is executed at scope boundaries instead of as a separate thread or…
Kernels tend to want to be very specific about how memory is being used. GCs cause the opposite situation. i.e. these "specific requirements and limitations" you mention have a LOT to do with memory.
Kernels need to be very specific about how other program's memory is being used. And they try and keep their own memory usage low (and predictable) because that's easier to understand and debug and doesn't waste system resources.
Just because there's a GC on the kernel's memory doesn't mean that the GC is somehow now working on all the process' memory that the kernel is running. That's not how the kernel works. The page table just holds a bunch of information about which processes are using which pages, garbage collecting a particular page table entry because the entry wasn't being used anymore wouldn't cause the memory which the entry was pointing to to suddenly be destroyed. And if the page table entry somehow gets to the point where it could be garbage collected that would mean that nothing is referencing it anymore, which would (in a properly written kernel free of bugs!) mean that the process isn't using the memory anymore, so there's no harm done.
Re: Author of “Unix in Rust” Abandons Rust in Favour of Nim
#23We 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…
> - Seems as safe as Rust with much cleaner syntax and simpler semantics. (this is something we're actively quantifying at the moment). Easily 10x the productivity. _Almost_ beats Rust at its core strength.
> Less safety than Rust when doing manual memory management (hasn't been an issue and we believe unlikely to be an issue in practice).
One major safety issue with Nim is that sending garbage collected pointers between threads will segfault, last I checked (unless you use the Boehm GC). Moreover, Nim is essentially entirely GC'd if you want (thread-local) safety; there is no safety when not using the GC. So Nim is in a completely different category from Rust; Rust's "core strength" is memory safety without garbage collection, which Nim (or any other industry language, save perhaps ATS) does not provide at all.
Re: Author of “Unix in Rust” Abandons Rust in Favour of Nim
#24Basically 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…
I am sure most languages could be compiled to C if you wanted. C++ started that way with the at&T cfront compiler.
Re: Author of “Unix in Rust” Abandons Rust in Favour of Nim
#25I 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.
> It does make me wonder if we'll ever see a Nim to rust transpiler.
Impossible, unless you compile to the unsafe Rust dialect. Nim is not memory safe in multithreaded mode, last I checked, while Rust is. So (unsafe) things expressible in Nim will not be expressible in Rust, because Rust's type system prevents them.
Re: Author of “Unix in Rust” Abandons Rust in Favour of Nim
#26Isn't Nim GCed? How are you going to build a kernel like that?
The presence or lack of a GC has nothing to do with the Kernel. The Kernel is simply another program, with specific requirements and limitations. So long as your language allows you to write and call raw assembly, you can write a Kernel. It's worth remembering that Rust has a form of GC as well - it uses a reference counting collection mechanism which is executed at scope boundaries instead of as a separate thread or…
> It's worth remembering that Rust has a form of GC as well - it uses a reference counting collection mechanism which is executed at scope boundaries instead of as a separate thread or co-routine.
And it's opt-in: you only pay for reference counting if you explicitly wrap your type in Rc. Moreover (and in contrast to Nim), you don't need to use reference counting for memory safety.
Re: Author of “Unix in Rust” Abandons Rust in Favour of Nim
#27Isn'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.
My issue with this approach is that it seems inherently racy in multithreaded programs. Nim gets around that issue by having a per-thread GC and segfaulting if you send pointers to other threads (unless you use the Boehm GC, last I checked)—your only backup seems to be manual memory management—but I don't see that as a scalable approach for large-scale software with dozens or hundreds of threads. (Not to mention that not having a thread-safe GC neglects a major benefit of a GC for lock-free data structures; having to use hazard pointers if you're a GC'd language seems like a shame.)
Re: Author of “Unix in Rust” Abandons Rust in Favour of Nim
#28Nim is the most fun language I have tried. I feel way more productive in it :)
Re: Author of “Unix in Rust” Abandons Rust in Favour of Nim
#29What 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…
In my experience it's very responsive and rational. It benefits as a language from being opinionated which is sure to ruffle feathers from time-to-time. Obviously not as big of a community as some others, but that hasn't been an issue for us.
I've seen heated flamewars about important issues rarely, about non-important/emotional issues only very rarely and only in IRC (where the current official policy is "we're a new language so don't kick someone out unless absolutely necessary"). More often with Nim you'll see the occasional "wtf- who implemented this? it needs to change to ---". To be honest, IRC isn't the best place to judge a "community"- trolls and good people venting have disproportionate voice there. And to be honest, if that exchange referenced was disturbing... just hope you never have to be involved in a decision with the Linux kernel team or (the most abrasive example I have first-hand knowledge of) the Apache development team 10 years ago ;-)
Notice there's only one comment there from Araq and it's trying to de-escalate things. If you were to pop onto IRC and ask something technical or philosophical that wanted a rational response Araq or many of the others not represented in that slashdot comment will most likely answer very politely and rationally within a minute or so (I think he's in Germany though? so timing may be an issue).
I think a better "feel" for a community can be gauged by the tone and quality of blog entries coming out and threads in github issues / pull-requests than IRC snippets.
That and the fact that if you decide to use Nim based on its technical merits then you _are_ the community- and at this early stage you can easily influence the tenor of discussions and decision-making for good if you choose.
Re: Author of “Unix in Rust” Abandons Rust in Favour of Nim
#30Basically 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…
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 (but not much), and (2) Nim compiles way faster than Rust.