"Am I correct that this discussion is about whether orphan instances are important? If so, banning orphan instances makes a language substantially worse than C++, in ways that will certainly damage even medium scale software."
Yes this is correct .. but im not convinced the problem is that big ( compare to no type/ memory safety we live with now)... Note there is no issue referencing types in 3 assemblies ..its generic/ template higher order style types that are an issue. ( Correct me if im worng as im not a huge user of type classes) . Shap has also pointed out issues with them in BitC and non static compiled programs - he did have some solutions .. Firstly i did do some work with the Cosmos C# compiler to try to get over some performance issues and a hit a problem relate to this exact problem .. Basicially i found that these 2+ order generic types covering 3 assemblies were not common. yet they caused huge issues for the compiler ( try inlining them !) . We had to create dummy assemblies then do a dependency analysis and load them in order. (Cosmos is statically compiled) Now there is always an alternative ... there is nothing stopping you using a small holder class or factory in your assembly that holds a type to assembly C and then its back to a 2 assembly case for the generic with full inlining etc . .. There are other ways . Also such code will be very rare for small runtimes or embeded code as these will tend to be monolithic apps. For larger business apps you will certainly have no issues with more loosely coupled systems such as SOA , DDD / CQRS or disconnected domains and those systems have a lot going for them at scale .. So the main problem case is large apps with lots of types , 3D games , compilers , large runtimes , however these things use a large amount of c libs for the next 10 years at least ..and if your using just functions from libs you will never hit the issue.. You wont be able to translate template heavy C++ aps easily since these will be difficult to port as the standard libs that use the templates use wont be available. Designing libs except for the standard lib ( which has the base types) will be a bit more tricky .. but .NET 1 and Java didn't even have generics . Dont get me wrong i would like to see it ( and a large number of other things in rust which is way too c like ) but id rather have a system that is production ready now so i dont need to deal with Cs faults (which are a far bigger issue) than something with all the bells and whistles in 10 years. If you have a crowd of people using it then you can put in money and expect a return and can re address things , javascript is a great example that a design does not need to be perfect but does need to be used. On Wed, Jul 17, 2013 at 1:14 PM, Geoffrey Irving <[email protected]> wrote: > On Tue, Jul 16, 2013 at 9:55 PM, Bennie Kloosteman <[email protected]> > wrote: > > "You really can't have this both ways. Either features like traits and > > implementations matter, in which case my programming in the large > concerns > > come into play, or those features don't matter, in which case Rust isn't > an > > enhancement of C. Pick one." > > > > Why cant i have a large standard lib ...with traits and use a lot of c > style > > modules in my code "modules" ? Together they form a large app... > > > > By "module" i wasnt thinking a rust crate , more say a WCF service .. > with > > loosely coupled message style async communication via pipe / shared > memory. > > C# can do it but C# cant do it pauseless ... nor can i build such a > > framework in C#.. > > > > "App architecture is unquestionably important. No argument. Nonetheless, > > mistakes in the language design - in this case the absence of lexical > > scoping for impls (aka type class instances) - can destroy any hope of > > success for the best imaginable architecture." > > > > I dont think it stopped Haskell ... and for the system programming core > it > > will be even less important ... Im quite sure you can write s decent > kernel > > or service with rust .. Im not convinced you can do a 3D app ( in non c > > style) due to the large amount of concpets embeded in the types . That > said > > it imay still better than C++. > > Am I correct that this discussion is about whether orphan instances > are important? If so, banning orphan instances makes a language > substantially worse than C++, in ways that will certainly damage even > medium scale software. > > One easy example from our code is an overloaded "to_python" function > that converts certain C++ objects into Python objects. Say the > to_python trait/type class is declared in library A, there's an > unrelated library B written by someone who doesn't care about Python, > and library C depends on both A and B. As soon as C wants the ability > to convert B's types to Python, we have orphan instances. > > C++ solves this by making namespaces open, so that C can inject > to_python overloads into B's namespace to be found via Koenig lookup. > This may be a hack, but it's an extremely useful one that I would not > want to lose. > > Geoffrey > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
