On Thu, Nov 14, 2013 at 11:40 PM, Paul Nathan <[email protected]> wrote: > > * 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).
Is being able to handle dynamic resource exhaustion failures important, or are the resources (memory, threads, file descriptors) usually allocated up-front? > * 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. Adding a backend to LLVM will be much easier than porting Rust to another compiler and maintaining it. > * 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. An alternative library is a far better situation than not having good real-time/embedded/freestanding support. I'll have a rejected pull request or RFC to point at for any divergence taken by rust-core, and it won't make any pointless bikeshed changes like renaming an API. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
