That's not Rust's philosophy. Garbage collection is great—when it makes sense to use it. Rust is designed to make garbage collection optional, following the way systems software has been designed for decades.
> Mozilla as an organization is not going to be capable of admitting they made a mistake with Servo/Rust and recoding it in Nim.
I've already gone over multiple times why Nim would not be a good fit for Servo (which is not to say that Nim is a bad language, just that it would not be a good fit for Servo).
Here's a post about removing GC from core rust 2 years ago: http://pcwalton.github.io/blog/2013/06/02/removing-garbage-c...
Next: they didn't kill GC. They removed it from core, because rust is capable of having gc implemented as a library. Standard library still has two gc-enabled pointers - Rc and Arc. You can use them in current code to have garbage collected values.
Most systems software gets by fine with a combination of thread-safe and thread-local RC. Reference counting is a form of garbage collection that works really well when it's used only for the subset of data that needs GC--which is the style that Rust encourages anyhow.
For Servo we need a javascript engine. We're already using Spidermonkey. It has a GC for Javascript; we're already paying those costs. The Rust-side representation of DOM objects is also managed by the GC; that makes sense because these are tied to Javascript things.
We don't use the GC elsewhere. I think at some point we did, but the only place now in Servo where GC is used is where the data is strongly connected to data already managed by the SM GC.
Nim's GC is for general-purpose use in a language. Spidermonkey's GC is for GCing javascript, which already has an extensive runtime (which the GC ties into heavily). "Nim's GC is better than Spidermonkey's" is a statement of no value (and oversimplifies the situation) unless the context is specified. Using the SM GC to collect random Rust objects would be a bad idea. Somehow rigging up spidermonkey to use a Nim-like GC in Rust (all other things being the same) would also be a bad idea. Two different scenarios, two different GCs.
At the same time, we're putting a lot of thought into how to properly add an optional tracing GC. It's important that it doesn't impact the no-GC case, which is still, of course, primary.
The current reference counted types don't just get used for convenience, they get used because they describe the actual life cycle of the data they contain. A tracing GC would be similar.
Gc is "just" an automatic memory management. Rust is not a garbage collected language, but it does have optional garbage collection available.
The decision was only done at the point when the devs were confident that the ownership/borrowing system could manage all the normal workloads done by GC, and that GC could now be implemented well into the language as a library.
As a side note; it's really easy to see the wrong in things. It takes more work to try to find the good in things. You might find that you're better able to connect with people by being more optimistic.
The fact that using Rust to write a simple website isn't very handy doesn't mean it's a bad language. Web development simply isn't its primary focus: this is a systems programming language we're talking about. The mere fact that it is being considered for writing web apps is impressive since Rust is supposed to be a better C++, not a better Ruby, Python or Node.js. Rust mainly emphasizes performance and safety. This means all the 'magic' that happens in a dynamic language is exposed to the programmer, and has a cost: the code is more verbose, and seemingly simple things are more complicated.
Rust is very popular now. That doesn't mean it has a great design. One of the very first design decision/belief they made was "no code can perform with garbage collection". Well, garbage collection does cause quite a few performance problems, but that doesn't mean it can't work if you engineer it right.
Personally I think Go and Nim are better languages as a general statement, both for applications and systems programming.
I know I am going out on a limb making a negative statement like that, and previously Nim developers have tried to discourage me from saying negative things about Rust. Those guys are smart and have social skills and they realize they should be careful to be nice to Rust developers because sophisticated developers looking for things like performance, type safety, etc. with a C or C++ background are really going to benefit from Nim if they give it a chance and Rust developers are prime candidates for Nim conversion.
So let me just say clearly that I don't associate with the main Nim community, the core developers, or anyone really. Nothing I say here reflects on them I hope.
I literally have no friends in fact.
I don't understand people, or pay much attention to them, or interact with them very much. When I do interact I say what I really think, not what people want to hear.
What I DO understand is technology. From a very early age I have been programming in everything from different types of assembly language to C to C++ to Ruby, Javascript/CoffeeScript/ES7, different variants of SQL, Rust, Forth, OCaml, etc.
Mozilla is a leading technology organization with many contributors. Rust is a new technology with quite a few people innovating on it.
Unfortunately, Rust starts with a bad design decision and never really recovers from that design decision. The values and perspective are lacking a modern, contemporary perspective.
The Rust worldview is trapped in the C++ era.
I have been primarily a JavaScript developer both on the front and back end for many years now. Why? Because I like to make useful applications and I am sane and paying attention.
But in a world where people were better informed and had better judgement and the best things won out rather than the most popular, Rust would be an obscure language being toyed with by a few academics for (perhaps?) implementing certain parts of kernels, the new browser from Mozilla would be fully peer-to-peer capable (using IPFS/gittorrent/swarm/ndn etc), written in Nim of course, use JIT/VM/something Nim for scripting, and have thrown out JavaScript/ES6/ES7 AND CSS for good. Of course, in this ideal world there would be no google monopolizing all advertizing and capturing most good engineering talent, since semantic markup and p2p query would also be be built in to this browser, making google irrelevant. The default mode for the browser would be virtual reality, with the ability to render 2d operating systems or markdown/images on arbitrary 3d surfaces.
But instead we have the world we have. All advertising must follow the dictates of a giant all-powerful global corporation. Mozilla is trapped in a pseudo-C++ mindset and spending most of its efforts trying to reproduce the intractable mess of decades of CSS hacks, in the time the engineers have left after going through in excruciating detail all of the possible ways to 'borrow' memory. CSS, a brilliant system that is a pain the in the ass not only for programmers but also designers, so complex that only two computer programs in the world are known to do a reasonable job of rendering it accurately.
Its time to stop dragging the old tools, mindsets, and technical debt forward. Stop judging things on the basis of momentum or authority (Google/Mozilla/Microsoft) and start using your brain to select things rationally.
Mozilla as an organization is not going to be capable of admitting they made a mistake with Servo/Rust and recoding it in Nim. Just like the world is not going to accept that we should throw out CSS and use any other simple system that can reproduce graphic designs. And we are not getting rid of JavaScript with its horrible threading model and garbage collection anytime. But we should. In a sane world we would learn from our mistakes and throw all of that out.