On Mon, Jul 22, 2013 at 10:47 PM, Ben Kloosterman <[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. > **** > > Also isn’t the issue of not finding the correct single instance when there > is only 1 only valid for runtime /jit compilation ? > I don't believe so. > -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 . > This is a discussion that we have had on the BitC list before. The BitC whole-program compile was always a temporary expedient. It was *always* my belief (and remains my belief) that we need to be able to support versioned dynamic libraries or their equivalent. For an operating system kernel, whole-program compilation is an option (indeed, a necessity). For general applications it is not. In consequence, there is no way at static compile time to determine instance uniqueness *unless* instances obey lexical scoping rules. > “Would I like a different approach to application structure? Sure. Right > now that's not the problem I'm trying to solve.” > > ** > > ** ** > > Is it a problem that can be addressed well in isolation ? Why not a roll > in the language that makes it better , many languages encourage different > architectural styles which leave other styles weak. Rust Tasks encourage a > certain style of architecture > I don't think it can be solved in isolation, but that's not really the point. It isn't the problem I'm trying to solve with BitC. **** > > 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*. Jonathan
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
