On Mon, Jul 22, 2013 at 10:47 PM, Ben Kloosterman <[email protected] <mailto:[email protected]> > wrote: Jonathan you mentioned the cost of unsafe as a tax on the user but there are many apps where the introduction of a 3rd party lib/dll is a significant problem possibly as significant as memory / type safety . Look at unsafe language browsers that work well but grow unstable with add ins. Sure, but the main source of that instability is the lack of safety and isolation of the add-in. This is only really the case for really crappy add ins .. flash apps have some safety ( though the runtime is almost in the crappy app category) , most C++ libs use safe_ptr and const and are much safer than before but the issues seem to me not core dump / seg fault type issues but more either slowing the browser down to the point of being useless or getting an invalid logic state and / or going zombie ( infinite loops , multi-threading issues etc) which are not easily solved with any form of lib or dll extensions. -You can merge all those types from multiple crates into an single crate and statically compile them ( isn't that what bitc did ) than remove what is not needed . This is expensive but it doesn't matter for binary distro and LLVM is slow to compile anyway . That is the case 1 I mentioned , and when needed ( eg public duplicates) explicitly state the implementation ( that is not a huge burden IMHO) . This covers many apps . My comments was related to open source IOC apps which use 3rd party libs/ add ons as having huge security issues. I have every confidence that this is a major issue. And it may even be an issue that BitC can solve - or at least strongly mitigate. But the solution is going to require re-architecture of libraries and add-ins, and that takes time. Even if there is a better ultimate solution, we need to be able to migrate programs today. True but I think using existing C libs with the best possible support is the best way to migrate today , this is a pain with GCs and is a huge bonus in the + column for Rust ( not to mention waiting for a decent gc which without funding is a huge obstacle , I mean even with large backing go hasn't done very much , it doesn't do much more than java ). Add to that rust Crates ( with explicit / statically scoped exported implementations of types ) and static whole program compilation as well as glorified service like independent libs and you can solve nearly all problems . And if you come out with a better solution for type coherence ( eg so you don't need explicit / lexical scope ) that's great but can be done in version 2 . I mean if we are talking green field apps where do you use C++ ? - Anywhere where pauses are unacceptable and you have a significant heap 3D games . - Where every ms counts eg frequent trading . - Embedded systems , kernels and drivers - Soft / Skill set issue To me whole program static compilation , Rusts explicit / lexical scope crates and some c libs goes a long way in those scenarios as long as someone can come up with new smart libs / services later. That said Rust can really do with some of the things BitC wanted to do .. and if Rust succeeds of which I think there is a reasonable chance ( especially with some of the changes ) , then I certainly think a Rust+ with services , optional pause less GC and some of the things in Bitc is something people will pay for .. I know merchant banks would be interested ( provided you had a tcp and FIX lib , service comms and hosting ( SOA / REST) , hibernate and a few other things but these can start as c++ or wrappers) Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
