Slashdot Mirror
Microsoft Open Sources CoreCLR, the .NET Execution Engine
An anonymous reader writes: As part of Microsoft's continuing project to open source the .NET framework, the company has announced that CoreCLR, the execution engine for .NET Core, is now available on GitHub. CoreCLR handles things like garbage collection, compilation to machine code, and IL byte code loading. The .NET team said, "We have released the complete and up-to-date CoreCLR implementation, which includes RyuJIT, the .NET GC, native interop and many other .NET runtime components. ... We will be adding Linux and Mac implementations of platform-specific components over the next few months. We already have some Linux-specific code in .NET Core, but we're really just getting started on our ports. We wanted to open up the code first, so that we could all enjoy the cross-platform journey from the outset."
Aren't guys like you tired of bitching about Microsoft... for fucks sake, they are in the process of releasing their entire toolchain (from the bottom up) under the MIT licence.
If it's MIT licensed it's probably a bit too open for him.
Or they stop trying to license patents they hold on technologies that Linux uses. That would be a great gift for FOSS.
Harrison's Postulate - "For every action there is an equal and opposite criticism"
Seriously, that guy has been shouting at the pigeons for years. And I speak as an open source user and advocate.
This is why I don't like developing for Microsoft's stack. They seem to want to throw everything out every few years and start over.
Then again, it seems like the web business is like that, too. Damn. Doesn't anyone write non-disposable code any more?
People are never as simple as their stereotypes. This applies equally to Christians, Muslims, and Emacs-lovers.
Okay, I'll bite: how many entities has MS sued for .net patent violations on the subsequent versions, as you referenced? It's been the better part of a decade now, right? No doubt they have sprung their trap...?
Also, how many cases have there been where a copyright license like MIT has been retroactively revoked (I mean, that would be the textbook application of promissory estoppel).
Keep in mind that, even with new APIs introduced, the old stacks still continue working just fine. WinForms or WPF apps will still run on Windows desktop machines decades from now, just like native Windows applications are still using Windows API calls written decades ago.
Also, despite rumors to the contrary, WPF is still being actively developed, although it's probably fair to say it's "peaked" as a technology, and is now transitioning into a maintenance mode. I'd have no qualms about creating a new WPF project tomorrow - so long as you know you're only targeting the Windows desktop. There are benefits to using a mature technology, and WPF is pretty mature at this point.
You really only need to use the new stack (WinRT) if you're planning to do cross-platform stuff across the entire Windows ecosystem (Metro/Surface/Mobile).
Irony: Agile development has too much intertia to be abandoned now.
Now make the whole Visual Studio suite available for free to home users.
You might want to check out Visual Studio 2013 Community Edition... It's the same thing as VS2013 Professional; it's free until your "hobby" has 5 employees or $1 million in revenue
If it had been GPL i might have cared.
Because the only "free" license options that matter are the ones you care about. Yes Comrade Commissar, we will comply with your thought police party line or whatever #fileitunderomfgurdumb
WinForms is not "deprecated". They merely introduced what they thought would be its replacement (WPF). The replacement was inadequate because:
- It was only marginally compatible with existing WinForms code
- It was radically different and required scaling a very steep learning curve, which is detrimental to development deadlines. This slowed its adoption drastically.
- It didn't offer anything truly useful that couldn't be done with WinForms and a lot of glue code (developed decades ago, and is now battle-hardened production code)
Then they backpedaled on the replacement, and introduced the replacement's replacement (HTML5 and JS). The replacement's replacement was inadequate because:
- When you're used to working with strongly-typed languages, Javascript is a step backwards. This is even more true when you're working on a non-web app.
- HTML5 is a pain to work with in a non-browser situation. This is likely because HTML5 is purpose built to work within a browser window. Ditto for Javascript, really.
- There's no way in hell you can interface with years of tried-and-true libraries because they don't publish endpoints that Javascript can use. This is not a viable option for LoB development, which is what most MS-stack programmers are.
Now they've backpedaled on the replacement's replacement. And they've introduced the replacement's replacement's replacement ("Universal" apps). The jury is out on this one. Unless it allows something similar to WinForms-style event-driven programming techniques, it's likely to fail. That's really the big sticking-point for most MS-stack developers. There's nothing that comes close to being as useful with as easy a learning curve as the hassle-free, automatic callbacks ("events") built in to WinForms.
To be honest, WinForms works just fine and will continue to do so for a long time. Universal apps will have their niche, and may even be an adequate replacement for WinForms, but that remains to be seen. I'm actually hoping for it at this point. I want some successes and some progress out of Redmond instead of another failure or another not-ready-for-primetime research project.
They're just trying to help you. Every time you use $ in Microsoft's name, your argument loses credibility. You look childish, and therefore your argument looks childish, and people will simply ignore you. We know Microsoft has a lot of money, and like nearly every other company on the face of the planet, they are trying to make more. This should not be a surprise to you...