Announcement

Collapse
No announcement yet.

Microsoft's .NET Team Open-Sources CoreCLR

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Microsoft's .NET Team Open-Sources CoreCLR

    Phoronix: Microsoft's .NET Team Open-Sources CoreCLR

    Microsoft's .NET team has announced the open-sourcing of CoreCLR, the execution engine of .NET core...

    http://www.phoronix.com/scan.php?pag...Source-CoreCLR

  • #2
    I hope they open source and port everything, including WinForms. GTK# doesn't have as much features and having another "compile once, run everywhere" platform beside java would be nice.

    Comment


    • #3
      Originally posted by eydee View Post
      I hope they open source and port everything, including WinForms. GTK# doesn't have as much features and having another "compile once, run everywhere" platform beside java would be nice.
      Neither Java nor NET give you the "compile once run everywhere" solution, because if something is written in Java it doesn't yet mean it's crossplatform or that the Java APIs/features you use are bug-free across all platforms, so in real life you still have to test your app on every platform.

      Comment


      • #4
        Originally posted by mark45 View Post
        Neither Java nor NET give you the "compile once run everywhere" solution, because if something is written in Java it doesn't yet mean it's crossplatform or that the Java APIs/features you use are bug-free across all platforms, so in real life you still have to test your app on every platform.
        Depends on what I'm using, doesn't it? Core features are usually enough for me, I only make small utilities for myself, not commercial applications.

        Comment


        • #5
          Originally posted by mark45 View Post
          Neither Java nor NET give you the "compile once run everywhere" solution, because if something is written in Java it doesn't yet mean it's crossplatform or that the Java APIs/features you use are bug-free across all platforms, so in real life you still have to test your app on every platform.
          Exactly. Not to mention a lot of times you end up needing to interface with a C/C++ library.

          Comment


          • #6
            Originally posted by eydee View Post
            I hope they open source and port everything, including WinForms. GTK# doesn't have as much features and having another "compile once, run everywhere" platform beside java would be nice.
            A very nice idea, and one I wish they'd do, but the problem is that a lot of stuff is tied very heavily into Win32 (even to the extent of simply being a wrapper around the Win32 control, e.g. text boxes) and therefore wouldn't be much use to Mono or anyone.

            Comment


            • #7
              Originally posted by eydee View Post
              I hope they open source and port everything, including WinForms. GTK# doesn't have as much features and having another "compile once, run everywhere" platform beside java would be nice.
              WinForms is unlikely, not only is it too tied into Windows itself, but as things currently stand Microsoft considers it a legacy platform. On the other hand WPF is likely in the long run.

              In this interview http://blog.jerrynixon.com/2014/11/h...re-of-wpf.html they indicated while they aren't ready to commit to it yet, they are seriously looking at how they would do so, now this would be a "maybe they will, maybe they wont" except for one thing... Visual Studio. Nadella is trying to shift Microsoft away from Ballmers strategy of everything relying on Windows to making the applications and services cross platform. Visual Studio is an obvious target for making cross platform, particularly with their current moves (The creation of the .NET Foundation, and the opensourcing of most of .NET...). Further Build 2015 is likely to be a watershed moment where the teams who are currently on the wall finally decide "yes, we're going to".

              Now, even if WPF doesn't get ported, Qt# is being developed https://github.com/ddobrev/QtSharp and well underway, and so in the (near?) future that can still be achieved.

              Regardless .NET is about to become a significantly more interesting platform over the next year or so.

              Comment


              • #8
                I am actually really curious. Why doesn't Microsoft just fork LLVM and use a closed-source internal version? Is CLR offering some advantage to them that LLVM IR cannot beat? Is this entirely an issue of trying to monopolize the market? Am I not understanding something? My guess is that maybe LLVM IR has to be optimized too closely for the target architecture, but Google seems to be using it for PNaCl, so I feel like perhaps this issue can be resolved by optimizing the bitcode, though I am not sure how they do it. Perhaps it is because LLVM IR is not as good for JIT compilation. Really, I am not sure, but there must be some obvious reason.

                Comment


                • #9
                  Originally posted by vadix View Post
                  I am actually really curious. Why doesn't Microsoft just fork LLVM and use a closed-source internal version? Is CLR offering some advantage to them that LLVM IR cannot beat? Is this entirely an issue of trying to monopolize the market? Am I not understanding something? My guess is that maybe LLVM IR has to be optimized too closely for the target architecture, but Google seems to be using it for PNaCl, so I feel like perhaps this issue can be resolved by optimizing the bitcode, though I am not sure how they do it. Perhaps it is because LLVM IR is not as good for JIT compilation. Really, I am not sure, but there must be some obvious reason.
                  Are you generally asking why doesn't Microsoft just use LLVM?

                  On your comment about LLVM IR, at least support gc safepoints has been recent or somewhat lacking. CLR's IR representation has knowledge of the GC, etc. that I'm guessing they thought was good enough for their case. I think the mindset may have been .. who will write hundreds of GCs? Also you're missing the JIT latency which is a significant hurdle for adopting LLVM for JIT purposes. And finally, the library size of LLVM all up is just humongous.

                  That said, I'm sure we'll soon see a LLVM-based JIT now that it's open source.

                  Comment


                  • #10
                    Originally posted by mjsabby View Post
                    Are you generally asking why doesn't Microsoft just use LLVM?

                    On your comment about LLVM IR, at least support gc safepoints has been recent or somewhat lacking. CLR's IR representation has knowledge of the GC, etc. that I'm guessing they thought was good enough for their case. I think the mindset may have been .. who will write hundreds of GCs? Also you're missing the JIT latency which is a significant hurdle for adopting LLVM for JIT purposes. And finally, the library size of LLVM all up is just humongous.

                    That said, I'm sure we'll soon see a LLVM-based JIT now that it's open source.
                    Well, CLR existed before LLVM IR, but I am sure they could write the GC code and use their existing .NET libraries with LLVM. Then they could potentially get the AoT compilation benefits and people would start publishing games and compute-intensive software on Microsoft's new platform.

                    Comment

                    Working...
                    X