71–80 of 118 posts
Earlier quoted context omitted.
Yes (as the Windows IOCP support is invaluable). But we will probably need to add threading support to it.
What do you mean add threading support? Last time I used libev (I thought libuv was just libev plus Windows) it allowed creating multiple loops for use in multiple threads just fine. Do you mean adding the ability to move file descriptors across threads into another loop?
Excerpt from Graydon's (BDFL) reply: > Despite all these caveats I have a very strong sense that writing the > runtime in Rust will go a long way to validate Rust in the domains it's > aiming for: concurrent and systems programming. Even in the task > scheduler, where there's quite a bit of unsafe code, the shared-nothing > nature of unique types forces you to consciously break the type system > to share memory, and…
Yes, please. Anything but C++. The progress of Rust and Go make me hopeful for the future.
Earlier quoted context omitted.
Indeed, the behavior described here is just a consequence of allowing pattern-matching when assigning variables. Say you wanted to do the Python trick of swapping two values: let a = 1; let b = 9; let (b, a) = (a, b); printf!("a: %i, b: %i", a, b); // a: 9, b: 1 ...or say you just wanted to grab a single item out of a tuple: let x = (1, 2); let (_, y) = x; // the underscore is the pattern for "ignore this" printf!("y…
Just for comparison: b, a = a, b is actually valid code in Lua (and works as expected). Grabbing only one value looks like this _, y = returnsTwoValues() -- grab only the second y = returnsTwoValues() -- grab only the first
a,_ = two_values()
_,b = two_values()> tasks are now migrated across threads by the scheduler, whereas in the old scheduler a single task was always run in the same thread. Is that done by having a single task queue with multiple schedulers, or through work-stealing by schedulers with no ready tasks in their queue? Would this open the possibility of configuring schedulers (including individually)? E.g. ensuring a given task stays pinned on a specific sc…
Right now it's the former, but Aaron Todd has a pull request to switch it to the latter.
> tasks are now migrated across threads by the scheduler, whereas in the old scheduler a single task was always run in the same thread. Is that done by having a single task queue with multiple schedulers, or through work-stealing by schedulers with no ready tasks in their queue? Would this open the possibility of configuring schedulers (including individually)? E.g. ensuring a given task stays pinned on a specific sc…
> Would this open the possibility of configuring schedulers ... I've been assured that it's the plan. I have no idea how much of it works right now though. I've only done one build with the new rt and it doesn't involve tasks.
Excellent [twirls mustache]
> I have no idea how much of it works right now though.
Yeah I don't expect it to work at this point, but knowing it's one of the end-goals is good.
Earlier quoted context omitted.
Yes, please. Anything but C++. The progress of Rust and Go make me hopeful for the future.
Why is it everytime people talk about replacing C++, someone always comes in and sticks Go into discussion? What does Go have to do with C++?
> tasks are now migrated across threads by the scheduler, whereas in the old scheduler a single task was always run in the same thread. Is that done by having a single task queue with multiple schedulers, or through work-stealing by schedulers with no ready tasks in their queue? Would this open the possibility of configuring schedulers (including individually)? E.g. ensuring a given task stays pinned on a specific sc…
Tasks can be 'pinned' to their own scheduler (i.e. thread) with `spawn_sched(SingleThreaded)`, and this is very important for tasks that call foreign code that blocks.
That's about the extent of the configurability at the moment, but I anticipate at least one other 'mode' in the future for coping with blocking tasks that don't want to be pinned to a specific thread.
Earlier quoted context omitted.
> * Games require portability. Not many platforms will have a rust compiler (Not to mention that current C++ compilers are very mature and highly optimizing). Rust uses LLVM as the backend, so any platform that Clang supports, Rust can too. (And also, it has the optimisations built in.) In fact, there's already support in the compiler for x86, x86-64, arm, and mips. (I'm not sure if mips actually works, but arm defin…
Really the portability that matters in this case (games) is probably Windows, which llvm and clang do not target very well at this point.
Earlier quoted context omitted.
I think you may be overestimating the pace of change. C++ is quite entrenched for industrial-strength game projects. The network effect is strong, the tooling is mature, and the projects are largely driven by C++ experts. Even if we see Rust 1.0 by the end of the year, it will take a lot of time for that kind of change to occur in the industry, if it ever does. I think you're much more likely to see 51% of new game c…
In addition to your point, I'd like to stress that it is the game engines that are C++. Many engines provide a higher level interface for developers actually make games. You probably won't hook the game developers on Rust. If you want to pitch Rust to the engine guys, you're going to be battling against their toolchains that have been developed for decades and have some of the best static analysis tools under the sun…
If Rust succeeds as a language suitable for games and gains traction there (and that is of course an if), I think the truth will be in the middle: there will be a huge amount of code still written in C++, and that will continue to be maintained and work. But new code might be written in Rust. Rust is designed to integrate well with C and C++ code, so mixed projects are quite feasible: in fact, both rustc (because of LLVM) and Servo (because of SpiderMonkey) are such mixed projects.
Earlier quoted context omitted.
I wouldn't say impossible, but yes, there are reasons this is difficult to fix in Go compared to Java and C#, and intentionally so. Quoting from http://talks.golang.org/2012/splash.article (emphasis mine): "To give the programmer this flexibility, Go must support what we call interior pointers to objects allocated in the heap. The X.buf field in the example above lives within the struct but it is legal to capture the…
To be fair I don't think this is a blocker for Go to implement GGC and CGC. .NET supports interior pointers too, for example. You just have to design your allocator right to allow the card marking to work. In practice I think that the biggest problems are compiler related and affect both Go and Rust. Go and Rust both use conservative GC on the stack and as a result they take a lot of shortcuts. For example, LLVM (and…
That said: Aren't the equivalent pointers in .Net _only_ allowed/usable if you pin your object? If you tell the GC explicitly 'please don't move that, I'm pointing to that thing here'?
That's hard to bolt on to Go, imho. For Go it seems to be implicitly allowed, in .Net you have to ask explicitly?