On 11/14/13 4:31 PM, Nathan Myers wrote: > On 11/11/2013 03:52 PM, Gaetan wrote: >> Can we have Two rust? >> >> The first one would be easy to learn, easy to read, and do most of ones >> would expect: on demand garbage collector, traits, Owned pointers,... >> >> The second one would include all advanced feature we actually don t >> need everyday > > This is a special case of the general design principle: push policy > choices up, implementation details down. > > There's no need to choose between M:N vs. 1:1 threading, or contiguous > vs. segmented stacks, at the language design level. It just takes > different kinds of spawn(). The default chosen is whatever works most > transparently. Similarly, a thread with a tiny or segmented stack is > not what we usually want, but when we (as users) determine we can live > with its limitations and costs -- including expensive call/return > across segment boundaries, and special ffi protocol -- there's no > fundamental reason not to support it. > > There are practical reasons, though. Each choice offered adds to the > complexity of the implementation, and multiplies the testing needed. > We don't want it to be very expensive to port the rust runtime to a > new platform, so these special modes should be limited in number, and > optional. Ideally a program could try to use one and, when it fails, > fall back to the default mode. There is no need to make this falling- > back invisible, but there are good reasons not to. > > Making the choice of default mode depend on the platform (1:1 here, M:N > there) might force complexity on users not necessarily equipped to cope > with it, so it is best to make the defaults the same in all > environments, wherever practical. > > (Graydon et al. understand all this, but it might not be obvious to all > of the rapidly growing readership here.) > > Nathan Myers > n...@cantrip.org > _______________________________________________
At the risk of increasing the current noise on the list, I want to make a few points about the current arguments, based on my education & experience in the embedded & critical infrastructure space. Understand, I don't want to call anyone out; I'm not a threading expert, and I'm not a core developer or committer, but I have watched Rust & the mailing list and I have plans to use it in the future. I want these thoughts to be heard, weighed, and incorporated in the decision making process. * Linux is not the only platform that matters. I would actually argue that other operating systems, in particular the embedded & RTOS space, are the OS platforms that need to be held up as platforms to be careful to map against. Names of such operating systems include QNX, VxWorks, ThreadX, L4, etc. These systems are designed very carefully to be fault tolerant, deterministic and reliable; failure in design is often literally "not an option" with the software systems that build on them. These are design goals that Rust, in part, shares. Being able to carefully manage memory, tasks, etc, and have strong type safety is something I believe that will be very attractive to the safety critical space (obviously after Rust proves itself). * Not only is Linux not the only platform, assuming that *LLVM* is the only platform is a bad idea as well. Designing for only LLVM's capabilities ignores the possibility of a Rust compiler targeting (say) Atmel chips. Making sufficient assumptions about a run-time model that prevents retargeting (of course, retargeting by a funded group of full-time engineers is what I mean, not hackable in a weekend by, say me, a n00b) to a different non-LLVM-supported chip will also be a major problem. * One of the BIG problems with D uptake is the split library problem referred to before. They could not get a comfortable standard library for a long time, despite some extremely bright and decently famous engineers working on D. My understanding is that it's mostly been solved now (after what, 10 years?). That'd be a disaster for Rust if things split badly at the interface level. My perspective is that the future of Rust's place is in systems that need reliability by achieving the following characteristics: low defects, controllable memory usage, and controllable time usage. In short, replacing C in ten - twenty years time. I am also taking the *corporate* perspective, which is partially driven by risk mitigation and caution; seeing core contributors arguing about runtime implementation *without* talking about systems much beyond Linux/LLVM is concerning. In summary, please remember the embedded & "hidden" world of computing in your discussions. -- Best Regards, Paul Nathan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
