Thanks dor your time Jonathan ., I follow ( C# has no such issues with interfaces/ inheritance as the implimentation and when to use it is explicit) . I wish i had the time to spend 3 months learning Haskell pref on a production system.. but maybe rust or bitc will give me that opportunity.
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 ? Obviously you cant translate large C++ apps into case 2 but with completely different libs ( and different templates !) conversion will be a big job anyway. Small VB apps to a DB , javascript in pages , unix shell commands grep . find etc are all successful in creating a combined large systems which IMHO is easier to maintain than a large app. Large VB apps were horrible ... but lots of small apps worked well ( thats not from working on it im not a vb dev , but seeing and using those teams at various organizations) Is this too much of a leap that most dlls for large apps are either merged into the crate or becomes independent task like services (deeply asynch even!) ( and note here this is much more reliable , a fault in the service will not have to kill your app or compromise your security , this is a huge issue for add ins ) ? It can certainly benefit parralelism - im a bit disgusted with many of the parralel libs these days which i tend to think of as "convenience" parralelism which have nice language wrappers but often the cost of the contention and language features are so high that it is only worth it for work say > 100ms and in most cases your better of with a single thread ( with IO on other threads) It may not be what all devs want but it may be better for them , which is certainly a role for a language - i like how C# pushes junior devs in certain directions that improve them .. like i said i have found SOA and DDD/CQRS quite attractive after spending 18 months on such a project.. certainly much better than the IOC based systems i have worked on. Not just for maintenance but also security , i have noticed on a number of open source IOC apps you can have your 3rd party DLL go .. Container.GetService<CreditProvider>() or Container.GetSecurity>() and then upload such information to the net with the developers completely unaware of the issue ( this is exactly what Mark Millers paper talked about and its becoming a bigger issue !) . Sure you can sandbox such dlls but then your much better of having service like tasks. Anyway it seems a natural fit for a language like rust with a task like concept. Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
