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.
Also isn't the issue of not finding the correct single instance when there is only 1 only valid for runtime /jit compilation ? Here is what I was thinking more explicitly -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 . - You can create rust crates which other people (as source ) can use in case 1 . - You can use c (and C++ with a c wrapper) as first class libs - a massive win in getting such a language used.. - While you can build in house apps loosely I meant you also produce "shared services " , I see this as a binary distributed services like a dll . eg compression.svc these are dynamically loaded by the framework and used by the app . Communication is loose but typing is checked via say compression.idl which is embedded in the compression .svc or gui.svc file. Each such service has no access to the host apps global space ( and could be a different process) and has its own thread. Such services could be shared between apps. So the language would evolve something like this Basic Rust standard lib , lots of c libs used.. lots of embedded code people start producing rust crates and services Gradual improvements in GC . Services replace most rust crates and jit use becomes viable more common "Libs" used are 50% services , 25% crates , 25% C.. "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 My comments was related to open source IOC apps which use 3rd party libs/ add ons as having huge security issues. Ben From: [email protected] [mailto:[email protected]] On Behalf Of Jonathan S. Shapiro Sent: Friday, 19 July 2013 6:38 PM To: Discussions about the BitC language Subject: Re: [bitc-dev] Rust was Re: Improvements on library allocation On Thu, Jul 18, 2013 at 8:51 PM, Bennie Kloosteman <[email protected] <mailto:[email protected]> > wrote: Is there are another way to think about this in terms of changing the way we develop .. eg All large apps are a pain .. and hard to maintain , it may be valid to say that applications should be 1) A single statically compiled crate .. In which case you can import all impl into the crate and fault duplicates ( or explicitly indicate which impl to import) etc . Great for emnbeded systems , drivers etc . 2) A collection of loosely coupled crates ( including the above ) with mostly pass by value messages and some tools to manage sharing. Is the problem space this doesnt cover that large ? Yes. It is that large. To first order, it is the entire space of production applications in the world. The idea of a language that supports loosely coupled application construction seems like a fine thing. But a language that cannot address the need to support large-scale applications has no future as a general-purpose language. Perhaps I should be clearer what I mean by "large scale". While I could point to many examples that happen to involve millions of lines of code, the real measure of a large scale application is an application built from components that are supplied by different organizations and are not developed on a synchronized or even cooperative basis. The identifying characteristic of these applications is that human coordination cannot be used successfully to resolve failures of modularity - or even bugs. Scale isn't primarily a technical challenge (though those can be huge). It's a social challenge that can be exacerbated by poorly designed technology. By this definition, for example, Gtk hello world is a large scale application, because it pulls in countless libraries from innumerable parties that you are effectively stuck with. Open source is not a cure for this. While open source means that you can hypothetically patch a bad library or subsystem, in practice your customers are not going to deploy custom-updated libraries for the sake of your fix, because doing so would break a bunch of other applications. That sort of fix can be deployed in extremis by cloning the library or component with a new name, but doing so creates long-term support burdens. Would I like a different approach to application structure? Sure. Right now that's not the problem I'm trying to solve. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
