I have no issue with going with the CLR first but What do you offer over C# - with the existing CLR ? ( I will adress the long term later) Safe Pointers to Non boxed value types. A more modern style type classes modules .. Lower GC work and pauses and in some cases the GC could be unused .. note for me this wouild lead to small services which have a higher chance of being GC free ( and i would given time develop a small service lib to destribute services not assemblies with its own thread which could be loaded and distributed)
If you can use still use pinvoke , use the standard lib , LINQ type collection expressions than you would have a usefull product and it would be stable fast because the runtime is stable. I do see a corner case here on handhelds eg Windows Mobile ( note via WinRT ) , CLR not supported) and via mono Android and ios .. it would be easy to get much faster than Java on Android . So where does this go in the future I would say most of it would be improvements in the GC AOT is no big deal . ( CLR a few apps just run ngen as part of the install) You mentioned you cant use the standard lib due to inheritance , very little of the standard lib uses inheritance its mainly interfaces which im sure could be made to work .. Please take carefull note here that Winrt does not support inheritance either with 1 exception ,some WPF GUI objects ( and they have a clunky implimentation which sort of maps interfaces to inheritance) . This leaves the possability of using the Windows 8 WInrt .NET libs , which by the way was the main purpose of openwinrt ... to move these libs to mono . That said its a huge amount of work looking at mono probably 90% of the code is standard lib , the jit is probably less than 3% ..so i would qualify the work a jit needs to a very good jit is not cheap . ( the one in Android JVM is pretty poor as well IMHO , more memory efficient but slow ) re what we want with a traditional dynamic library ? Well Java , C# , php etc can do a pretty good job for most apps what they cant do is write a runtime , a GC , kernel module or lib useable from other languages... We want a bitc open gl dll we can use from JVM or CLR . here are some important things that we really want to rewrite in a better language than C they are stuck using C because there is no better alternative. openGL / DirectX , Xfree , Wayland, kernels , device drivers , OCR libs , GCs, mono and other runtime , comms libs ( zeromq , msmq etc) , Fast alogirithms with SIMD. The real problem for many of these is native code calling GCs / managed libs , large scale pinning is not workable . I think this is why microsoft went with Winrt native COM reboot as a super structure when they relized that .NET could not be that super structure they did try ( eg improved the GC , Longhorn , managed DirectX etc which never really took of) . Note on windows a bitc on winrt via COM you could write these libs as components in bitc but linux is a much bigger issue you would need to create the same mechanism . Writing these types of libs is a huge untapped market waiting for the right product and what Rust is squarly aimed at . A Bitc vs C#/Java is still useful for lower GC pauses and maybe as a Haskel replacement on bigger projects or with more complex logic but its a huge ask ..they already have type and memory safety and can call c libs when needed for performance. Also native is growing its now more common on Android , Windows mobile 8 does not even have the .NET std libs ( it has the completely different C# winrt lib - no inheritance ) and winrt distributable components ( on mobile) can only be written in native . If you give people great native interop / SIMD and less GC issues i think you can get the merchant banks who would try to get all their development happening in less languages ( most have C# /Xaml front end , Java back and libs in C++) but there would need to be interop with the existing C++ and UI stack ( I think java wouild be ok via tcp) . Ben On Fri, Aug 23, 2013 at 2:12 AM, Jonathan S. Shapiro <[email protected]>wrote: > On Thu, Aug 22, 2013 at 2:34 AM, William ML Leslie < > [email protected]> wrote: > >> >> So what is it, exactly, that we're really trying to accomplish with the > traditional style of dynamic library? What's the use case? > > I think it's mainly to do with kernels, and with things that sit very low > in the system runtime - notably those things that need to exist to support > the post-install AOT implementation. For loadable kernel modules we > certainly have an issue, but even *those* can be handled with this kind > of post-install AOT. > > > I'm sure there are things I'm not considering here, but what do people > think about this? > > > shap >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
