> Let's take a couple of simple examples of when manual memory management is helpful:
>
> - implement a complex data structure that requires a lot of memory: you can request a chunk of memory from the kernel, do an area-allocation and choose to allocate/free on your own terms.
Rust fully supports this case with arenas.
> - implement a performant concurrency model. You essentially need some sort of scheduler to give various threads access to the shm via cas primitives.
And that's why the new scheduler is written in Rust.
Furthermore, manual memory management is helpful when you are implementing a browser that doesn't want a stop the world GC.
> You've exposed the lower-level rt/sync via libextra/sync.rs, but it's frankly not a big improvement over using raw pthreads.
It's just a wrapper around pthreads, for use internally by the scheduler and low-level primitives. It is not intended for safe Rust code to use. Of course it's not a big improvement over pthreads.
> The scheduler is a toy (rt/rust_scheduler.cpp)
That's why it's getting rewritten. You're looking at the old proof of concept/bootstrap scheduler. Please see the new scheduler in libstd/rt. It will probably be turned on in a week or two.
> and the memory allocator is horribly primitive (rt/memory_region.cpp; did I read correctly? are you using an array to keep track of the allocated regions)
There is a new GC that is basically written, just not turned on by default yet. Furthermore, manually-managed allocations no longer go through that list.
> Rust really has no way of accomplishing it, because you I don't get access to free().
Of course you do. `let _ = x;" is an easy way to free any value.
> The best you can do at this point is to use some sort of primitive reference counter (not much unlike cpython or shared-pointer in C++), because it's too late to implement a tracing garbage collector.
This is just nonsense, sorry. Graydon has a working tracing GC, it's just not turned on by default because of memory issues on 32 bit when bootstrapping. This is not too difficult to fix and is a blocker for 1.0.
Furthermore, did you not see the mailing list discussions where we're discussing what needs to happen to get incremental and generational GC?
> And you just threw performance out the window by guaranteeing that you will call free() everytime something goes out of scope, no matter how tiny the memory.
This is what move semantics are for. If you want to batch deallocations like a GC does (which has bad effects on cache behavior as Linus is fond of pointing out, but anyway), move the object into a list so it doesn't get eagerly freed and drop the list every once in a while.
> Lastly think about why people use C and C++. Primarily, it boils down to compiler strength. The rust runtime doesn't look like it's getting there; atleast not in its current shape.
The benchmarks of the new runtime are quite promising. TCP sending, for example, is faster than both node.js and Go 1.1 in some of our early benchmarks. And sequential performance is on par with C++ in many cases: http://pcwalton.github.io/blog/2013/04/18/performance-of-seq...
Please supply evidence (aka. code) to back your one-liners. I assume you're talking about libextra/arena.rs. It's very straightforward; there's a big comment at the top of the file, so I don't have to point out how primitive or sophisticated it is.
> And that's why the new scheduler is written in Rust.
You're talking about libstd/rt/sched.rs. So it uses the UnsafeAtomicRcBox<ExData<T>> primitive (from libstd/std/sync.rs) to implement the queues. The event loop itself is a uvio::UvEventLoop. Looking at the rest of libstd/rt/uv, I see that your core evented io is libuv (aka. Node.js). For readers desiring an accessible introduction, see [1]. Otherwise, sched.rs is very straightforward.
> There is a new GC that is basically written
Unless you're expecting some sort of blind worship, I expect pointers to source code. I found libstd/gc.rs, so I'll assume that it's what you're talking about. Let's see what's "basically" done, shall we?
You use llvm.gcroot intrinsic to extract the roots, and then _walk_gc_roots to reference count. You've also written code to determine the safe points, and have implemented _walk_safe_point. For readers desiring an accessible introduction to gc intrinsics in llmv, see [2]. The history indicates that nobody has basically touched gc.rs since it was written by Elliott a year ago, so I'm not going to investigate further.
The reason it's not enabled enabled by default is quite simple: it's not hooked up to the runtime at all. You still have to figure out when to run it.
> Graydon has a working tracing GC
You're not understanding this: the whole point of running an open source project is so you can proudly show off what you've written and get others involved. Your one-liners are not helping one bit.
> did you not see the mailing list discussions where we're discussing what needs to happen to get incremental and generational GC?
No, and that should be the purpose of your reply: to provide links, so people can read about it. I'm assuming you're talking about this [3]. Okay, so you need read and write barriers, and you mentioned something about a hypothetical Gc and GcMut; readers can read the rest of the thread for themselves: I don't see code, so no comments.
> TCP sending, for example, is faster than both node.js and Go 1.1 in some of our early benchmarks.
TCP sending is libuv: logically, can you explain to me how you're faster than node.js? No comments on Go at this point.
> And sequential performance is on par with C++
So you emit relatively straightforward llvm IR for straightforward programs, and don't do worse than clang++. Not surprising.
This is the one link you provided in your entire comment. Learn to treat people with respect: showing a programmer colorful pictures of vague benchmarks instead of code is highly condescending. Yes, I've seen test/bench.
If you're hiding some code in the attic, now is the time to show it.
I find some of your comments very aggressive. Yet you are lecturing people about being condescending. I honestly much prefer pcwalton's tone which I find much less condescending, interestingly.
Pointing at code can be indeed useful, but it looks to me like you are comparing apple to oranges: Rust is not at 1.0 yet, so comparing code that isn't yet production-ready with Go or whatever technology that is already mature is not all that useful.
Saying that, in it's current state, Rust is not a good choice for production code is acceptable and fairly obvious. Extrapolating to the point of saying that it is doomed seems like quite an exaggeration to me, and not respectful of the work people are putting into this project.
> Unless you're expecting some sort of blind worship, I expect pointers to source code. I found libstd/gc.rs, so I'll assume that it's what you're talking about. Let's see what's "basically" done, shall we?
I don't really want to draw out this argument, but I called your reply FUD because you were claiming things that were not true, such as that we cannot implement tracing GC.
Hm, a conservative mark-and-sweep that uses tries to keep state. I wonder how the gc task is scheduled, but you're not feeling chatty; so I'll drop the topic.
I made claims based on what I (and everyone else) could see in rust.git; I have no reason to be either overtly pessimistic or overtly optimistic. At the end of the day, the proof is the pudding (aka. code): we are only debating facts, not hypotheticals.
Either way, it was an interesting read. Sure, I took a karma hit for saying unpopular things, and people feel sour/ hurt/ [insert irrational emotion here]; that's fine. Nevertheless, I hope the criticism helped think about some issues.
I think you took a karma hit not for saying unpopular things, but for assuming bad faith. One of the lead developers of the Rust language pointed out some gaps or mistakes in your comment about Rust. Instead of appearing eager to correct yourself, you appeared eager to defend your original statements and all but accused him of lying. I'm certain you could have made the same substantive points with a more reasonable/humble tone and not been downvoted.
For example, when you learn new information like "there's a tracing GC in progress" and you want to look at the source code, you could choose to say "Oh, cool! I didn't know that. Could you give a link with more information or source?" instead of lecturing the other commenter about how they are Doing Open Source Wrong.
I don't have a position to defend, and I am nobody to make any statements of any significance: I did a code review, and I was critical about it. If anything, I want the project to succeed. Evidence? [1]
He asked me why I thought Rust would've live for long, and I spent hours reading the code and writing a detailed coherent comment to the best of my ability. He dismisses my comment as "FUD" [2] and responds with one-liners. The final comment with a link to his blog with colorful graphs was terribly condescending. Him being a lead developer doesn't mean squat to me: a bad argument from him is still a bad argument.
No, I'm not going to stoop to begging for scraps: if I wanted to do that, I'd be using proprietary software; Apple or Microsoft nonsense. In this world, the maintainer is the one who has to take the effort to educate potential contributors. He is clearly doing a terrible job, and I pointed that out.
No, I never accused him of lying. I accused him of making a bad argument, and not giving me sufficient information to post a counter-argument, which is exactly what he did.
And no, I did not "defend" my original argument: I posted a fresh review of fresh code (the one in src/libstd/rt, as opposed to the one in src/rt).
On the point of tone. Yes, I've spent many years on harsh mailing lists and my language is a product of that experience. Are you going to discriminate against me because of that, irrespective of the strength of the argument?
I will repeat this once more: the only currency in a rational argument is the strength of your argument; don't play the authority card.
Rust fully supports this case with arenas.
> - implement a performant concurrency model. You essentially need some sort of scheduler to give various threads access to the shm via cas primitives.
And that's why the new scheduler is written in Rust.
Furthermore, manual memory management is helpful when you are implementing a browser that doesn't want a stop the world GC.
> You've exposed the lower-level rt/sync via libextra/sync.rs, but it's frankly not a big improvement over using raw pthreads.
It's just a wrapper around pthreads, for use internally by the scheduler and low-level primitives. It is not intended for safe Rust code to use. Of course it's not a big improvement over pthreads.
> The scheduler is a toy (rt/rust_scheduler.cpp)
That's why it's getting rewritten. You're looking at the old proof of concept/bootstrap scheduler. Please see the new scheduler in libstd/rt. It will probably be turned on in a week or two.
> and the memory allocator is horribly primitive (rt/memory_region.cpp; did I read correctly? are you using an array to keep track of the allocated regions)
There is a new GC that is basically written, just not turned on by default yet. Furthermore, manually-managed allocations no longer go through that list.
> Rust really has no way of accomplishing it, because you I don't get access to free().
Of course you do. `let _ = x;" is an easy way to free any value.
> The best you can do at this point is to use some sort of primitive reference counter (not much unlike cpython or shared-pointer in C++), because it's too late to implement a tracing garbage collector.
This is just nonsense, sorry. Graydon has a working tracing GC, it's just not turned on by default because of memory issues on 32 bit when bootstrapping. This is not too difficult to fix and is a blocker for 1.0.
Furthermore, did you not see the mailing list discussions where we're discussing what needs to happen to get incremental and generational GC?
> And you just threw performance out the window by guaranteeing that you will call free() everytime something goes out of scope, no matter how tiny the memory.
This is what move semantics are for. If you want to batch deallocations like a GC does (which has bad effects on cache behavior as Linus is fond of pointing out, but anyway), move the object into a list so it doesn't get eagerly freed and drop the list every once in a while.
> Lastly think about why people use C and C++. Primarily, it boils down to compiler strength. The rust runtime doesn't look like it's getting there; atleast not in its current shape.
The benchmarks of the new runtime are quite promising. TCP sending, for example, is faster than both node.js and Go 1.1 in some of our early benchmarks. And sequential performance is on par with C++ in many cases: http://pcwalton.github.io/blog/2013/04/18/performance-of-seq...