> My main concern is that we have to keep costs and priorities in mind. > > Yesterday you described C/C++ as crazy/insane. It so happens that that > insanity is used to implement all the kernels that we are targeting. It is > used by every program I use (sometimes with an extra interpreter on top) and > is used by the compiler framework we selected. If all those are crazy, I > would say that that is not sufficient market for sanity.
C is a low-level programming language that was invented for a specific purpose: more quickly implement an OS on a machine with a few dozen kilobytes of RAM. C++ is an abomination that was built on this shaky foundation to increase the (almost non-existant) abstraction level of C. It adds some nice capabilities and better abstractions, but is at heard still an unsafe and unsound language. I am saying this despite the fact that I have been programming in C++ since the cfront days. I am not dissing C++ because I am some Haskell purist. I am dissing C++ because I have written exactly the kind of programs you talked about in C/C++ (Linux, VMs, SpiderMonkey) and it totally blows. C/C++ are an almost guaranteed way to get exploited. I strongly believe that for the future of the Mozilla project dependability and security are the key factors, and performance is a third factor only (and I am saying that as a beancounter/compiler guy who loves optimization and performance). > > Programmers like to complain about the hard to reason about semantics of C++, > but they do get the job done. Look at the cost we are proposing to get > something a bit better: every loop will have a check to know if it should > yield or not. Is this really worth it? What is basically doing is trying to > give task a similar semantics to what threads already have. C++ does not get the job done. Not at all. It is simply the least evil choice. Java is huge and still pretty dog slow. C# is proprietary Microsoft secret sauce. And then there is obscure stuff like Haskell and Ocaml and Fortran and Forth and Pascal, none of which have grownup tools. People don't chose C++ because they want to. They chose it because there is no alternative. Thats why we started rust. Do have an alternative. > > About datapoits. No, I don't have them. It is too early for that. We don't > need tasks right now. C, C++ and Java have come a *long* way without them and > they have a significant market share. Yes, they came a long way, until parallelism finally happened. Writing efficient and safe parallel code in C/C++/Java is simply not feasible. You are trying to built a fighter jet out of matchsticks. > > With the changes on how channel work, tasks are not a fundamentally new > concept. You even acknowledge that they could be implemented at 1:1. Given > that we must also provide access to raw threads, lets start with that. My > proposal is > > * Implement OS threads > * Have a notion of a task, which is a language abstraction that provides a > subset of the features that are common to all operating systems. You could > not, for example, send a signal to a task. > * Implement them now with a 1:1 mapping. I think this is the completely wrong way to go. Threads don't offer any decent resource management functionality at the OS-level if we allow arbitrary termination. For that we would have to go with processes, which are very heavyweight. A simple check in a loop can be highly optimized and is well worth it. Every Java VM uses safepoints like this in loops. You can dereference a dummy page and invalidate the TLB/page table entry to make the loop yield. The cost is almost zero in a modern pipelined CPU. Lets make rust as fast as possible, without giving up an inch of safety. The world doesn't need another C/C++. It really needs a C/C++ alternative. > > Once the language is more mature, we can consider what is next. It might be > another "insanity" that is known to work, like thread pools and continuation > style code or it might be user space tasks. > > The important point is that once we have web servers, GUI toolkits, image > decoders, audio APIs, etc available in rust, we will have data points. It > might be that, like what happened to java, using 1:1 is the best. If not, we > can then implement M:N as an optimization. We will not be able to build a system as complex as a web server in a parallel and dependable way if we have to use bare metal abstractions like pthreads and signals and shared memory and what not. That simply won't happen. We have proof of that (Gecko is almost exclusively single threaded, not by choice, but simply because the complexity cost is unbearable to change that). Andreas > >> -Graydon > > Cheers, > Rafael > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
