I do think that there are applications for which GC will always be slower than alternative systems such as arena allocation that Rust provides safe support for. (As an extreme example, the binary-trees shootout benchmark.) A language that does not provide safe manual memory management will lose in either performance or safety for these applications. I prefer not to make statements like "GC is slower than manual memory management", since there are many applications for which this is not true (for example, the level generation benchmark). Rather, I'd say that manual memory management provides a level of control that can allow skilled programmers to write applications that outperform those in languages with a "one size fits all" memory management scheme.
what I mean is this - we all knew that the rb tree implementation of stl wasn't that hot, neither was its sort (note - this is 7 years back), however that library enabled a c++ project to be jumpstarted in significantly less time than building everything from scratch.
as a language creator, you may not want to touch the design choices you made and make it more "accessible" for a simpler use case - as the previous poster wrote, upgrading from python.
however, you could potentially expose an accessible subset of the language as a standardised library. of course, this may lead to language rust (!!) at scale, but I would argue that its a good problem to have then.
I would be in your target market then - significantly better than python, inherently memory safe, easy to use, worse than c++.
It's not that simple. You can't start with a language that lacks memory safety and add it later. Nor can you start with a language that uses global concurrent GC and try to reel it back in without losing safety. C++ is in the former category and I think there is no way for them to add memory safety at this point. Languages in the latter category really have no way of going back on global concurrent GC; the entire ecosystem is built around garbage collection.
Safe manual memory management is balanced on a very delicate precipice. You must carefully design your language around it for it to work. It is not something that can just be added later, like a faster red-black tree algorithm.
For a large portion of my career, I was building EDA (silicon design automation tools), so I have worked with trying to optimize one bit at a time with unsafe pointers biting my back constantly. IMHO partitioning an EDA netlist is a NP-hard problem, so there have been lots of very interesting startups that tried to solve that problem and failed.
I now work with Ruby and Python.
Trust me I do know the value of everything you wrote: I am just wondering - requesting even - if there is a way to bridge the "accessibility" gap. Is there a way (anything - a "quickstart" library or a safe-but-suboptimal-subset, etc.) that enables me to start hacking with Rust in a matter of minutes ?
Yes, and as I wrote, I think there's a very significant place for Rust among embedded and systems programmers. But for someone who's just looking for a fast alternative to C, Nimrod has been quite nice.
> ...handwaving...handwave....
I was trying to give you the specifics you asked for, not handwave. I don't think I could have answered your question any clearer. And I don't think pointing out the complexity inherent in 3 different pointer types is handwaving. It's a very specific statement.
>...but be informed with your criticisms
You asked me to elaborate on my criticisms, and then you criticize my criticisms? Look, I understand that Rust is your baby, and apologies if I've treated it unfairly, but why ask for why I found Rust complex if you're just going to discount it?
To be clear, I'm talking from the perspective of an intermediate-level programmer, with a couple years of experience, who taught himself to program in his 30s. I can certainly see the value of the design choices you've made for an expert programmer like yourself, with many years of experience, who can benefit from the kind of fine control Rust provides. But to someone like me, who's just looking for some caveman-level (but very significant) speedup from Python, and something I can call from Python, Nimrod has proven more than adequate and a whole lot easier to use than C/++.
>This is a perfect example of how single benchmarks can be misleading
So to be clear, are you saying Nimrod can't reach ballpark C/Rust/D/Go speeds?
EDIT: Wow, I've made comments critical of Apple and Google and not gotten as many downvotes as I'm getting here. But just to be clear, I'm not at all being sarcastic when I say "expert programmer". I'm aware of that pwalton is a very talented programmer and language designer.