The scenario I keep hoping for is: ms buys xamarin, MIT licenses the entire xamarin cross platform ecosystem (while charging for build services like phonegap does), adds a "compile to html/css/js" feature so you can write your web frontend in c#.
This scenario leads to the following: C# wins as the "cross platform mobile language," window phone is the default first environment for cross platform apps, and as developers we get an elegant "write once* run everywhere" that's based on c#.
The asterisk: once plus ui customizations on each platform, so more like write (1 + (.1 * num_non_wp8_platforms)) times
Unfortunately, though I think these moves would make ms a dominating player in mobile and web for decades, I doubt they'll do this.
Much more likely; Xamarin is acquired, monodevelop development halts and the Xamarin offerings become VS pro features, giving Microsoft a foot hold in the mobile space (which they desperately need) and maintain VS revenue.
It's arguably not a terrible direction for things to go... If, unlike me, you dont passionately despise VS. :p
What about iOS where you definitely need OSX? Xamarin has some integration with VS (I've never used it myself), but it still needs a mac with OSX installed to work (even if it's just a macmini somewhere.
If Microsoft does buy Xamarin, I'd like the following to happen:
Xamarin and TestCloud become much cheaper.
More attention given to the IDE - fix the hell out of it
Better documentation
I also think it's a fantastic way of encouraging developers to work on WP 8. The less code you need to port from Objective-C/Java to .net, the better.
Devs who want to make WP apps on Mac or Linux have exactly thr same problem, just the other way around. A well integrated, "it just works" cross-platform build solution, straight from the IDE, has a lot of market value and fits perfectly in Xamarin's portfolio, Microsoft or not.
I actually ask Miquel about this very thing at Evolve last April and he said they would love to do something like that but Apple TOS forbid it. That is your impediment.
Sadly, I agree with you. I think Ms will continue to play the short game and wonder why they struggle to win the web and mobile.
The irony is, they'll give you $200 of swag at every event to grow their ecosystem 1 dev at a time, but they won't open source to grow their ecosystem 10x.
They have open-sourced quite a lot (aspnet webstack, reactive extensions, etc). The problem is that a lot of their compiled binaries, delivered via nuget packages have been restricted to windows. This is slowly being undone ( http://blogs.msdn.com/b/dotnet/archive/2013/11/13/pcl-and-ne... ).
Another problem is that they don't run their open source projects in an open manner. Contributing requires a CLA and a signature from your boss. Issues and planning are often behind closed doors, but that seems to be slowing changing too (see KatanaProject / signalr).
If they really wanted to grow their ecosystem 10x, and give windows phone the possibility of a fighting chance, making VS Pro free would be the required.
I like to think of things as copyright, copyleft and copy middle. This looks like an entirely new beast: copyquagmire
A few pieces of the license:
* For any Distributable Code you distribute, you must
· add significant primary functionality to it in your programs;
...
· indemnify, defend, and hold harmless Microsoft from any claims, including attorneys’ fees, related to the distribution or use of your programs.
*
So, if you redistribute these libraries, you agree to be on the hook for MS legal bills.
*
Distribution Restrictions. You may not
· modify or distribute the source code of any Distributable Code so that any part of it becomes subject to an Excluded License. An Excluded License is one that requires, as a condition of use, modification or distribution, that
· the code be disclosed or distributed in source code form; or
· others have the right to modify it.
*
So it is anti-GPL. I personally think this is a good thing, I hate the copy-virus in the GPL. Maybe this is even a poison pill that invalidates GPL code in a project, thereby protecting you from inadvertently letting your code fall under GPL (which I would consider to be a good thing). Whichever clause wins, this is a quagmire.
Lets continue.
*
you must comply with any technical limitations in the software that only allow you to use it in certain ways. You may not
· work around any technical limitations in the software;
· reverse engineer, decompile or disassemble the software, except and only to the extent that applicable law expressly permits, despite this limitation;
· publish the software for others to copy;
· rent, lease or lend the software;
· transfer the software or this agreement to any third party; or
· use the software for commercial software hosting services.
*
So, basically you can't modify it or change it.
*
BACKUP COPY. You may make one backup copy of the software. You may use it only to reinstall the software.
*
Why the hell is this in an "open source" license?
This isn't an open source license, this is a free commercial license with a bit of lipstick, a wink, and a head-fake towards openness.
Thankfully, it seems other divisions of msft (F# for instance) use the Apache License V2 which is in fact a copy-middle free as in beer and freedom open source license.
>I've never had to work so hard to find out _what_ license they're releasing things under. I followed about seven links and finally got it.
Microsoft's open source software repository is codeplex. If you go to codeplex you'll find out that the projects that you mention are Apache 2 licensed too.
I don't think it is unreasonable to believe that the license in the package manager operated by the company who is granting the license would be accurate.
I agree with you 100%. I don't know why they're releasing the source code and the binaries under different licenses so hopefully someone who knows this will reply to these comments. If I find out I'll let you know.
Congratulations, you clearly found your perfect license. Since you clearly hate being given the right to copy, modify and redistribute (as in the GPL), have fun using a license that forbids modification, and only give you max 1 backup copy.
Oh wait, you want to make modifications, and then sue people who then dare to copy, modify or redistribute your version? Pity you can't use that GPL compatible Apache 2 licensed code. Better use that non-compliant free commercial license instead.
To me, perfect licences are: BSD, MIT, Apache2, WTFPL
I like copy middle far far better than copy right or copy left.
My entire comment was about how bad the MS free commercial license was and how I wished it was a real FOSS license. There was a tangent in there about hating the copy-virus of the GPL, but that was an aside.
If you want to comment about how bad the MS free commercial license is, you should not bundle it with your desire to redistribute other peoples software and then sue your users if they dare to do the same by copy, modify or redistribute your version.
It takes away from your main arguments and distracts.
They have open sourced a bunch of their dev products including ASP.NET MVC, the Entity Framework, Web API, Web Pages, the Razor view engine, and SignalR.
And instead of reinventing libraries like they used to they started to embrace some open source libraries like modernizr, jQuery, Bootstrap, and Json.NET.
And to promote their Windows Azure initiative they released a platform installer that allows you to install open source products like PHP, MySQL, and Wordpress on your Windows box with just a few clicks.
Microsoft is a big company with many different clashing cultures. As a result some divisions shower you with software goodness and others with patents and lawyers.
I'm glad to see they're moving more of these technologies over to truly FOSS.
Which pieces are on which license if you get it from which place?
I'll update the linked comment with that blog post -- I seriously scoured the other press release and couldn't find which license these were released under.
The licences of the projects (EntityFramework, ASP.NET) are opensource, but the licence only applies to the sources.
Nuget packages, however, are binary. And they might have a different licence. So to avoid the latter, you just need to compile the sources yourself instead of using the Nuget packages.
If they came up with a unified, cross platform, UI format, it would make it so much easier. As it is now, you have to write your own view for each platform, instead of being able to use generic objects (buttons, cells, text, images, etc.) which wrap the native ones.
If they did that, they would very likely, as you say, dominate mobile for a long time. Nothing is more frustrating than jumping between android XML, Java, and eclipse (or whatever) and XCode, OBJ-C, and the iOS UI, while trying to not go insane.
Because of continued platform fragmentation WORA has been, is, and always will be a pipe-dream. People have been attempting to create WORA technologies since the beginning of time and they have all failed.
The nice thing about Xamarin's model is your UI code uses native constructs, allowing for the best possible, most natural (to the user) experience. But you get to stick with one language (if you want) and your core code is very portable.
> People have been attempting to create WORA technologies since the beginning of time and they have all failed.
Nice straw-man. Unity 3D does WORA very, very well. It's been used successfully for cross-platform development by many shipped products. To my initial astonishment, all built on Mono/C#.
This doesn't absolve the developer from QA for the targeted platforms, and this is where fragmentation is the killer IMO. That said, Unity provides a huge amount of leverage and tooling in support of seamless cross-platform deployment.
It's not a straw man at all as products with Unity aren't making any effort to appear native to the platform they're running on.
Unity is also notoriously painful when it comes to 2D UI style work as well, which is why there's a tools ecosystem around it just to deal with that problem.
Games are way different segment. In a game you would like to impress person with non standard interface. In fact a game running on standard UI looks cheap and is a signal of design failure / low budget.
While the applications are other way around. New customers do not want to spend more than a minute to get familized with the interface. Moreover, your custom UI interface will be competing with Apple/Google designer's budget.
"Nice straw-man. Unity 3D does WORA very, very well. It's been used successfully for cross-platform development by many shipped products. To my initial astonishment, all built on Mono/C#."
Not true. Unity engine is made using c/c++. You control those components using Mono/c#, which is totally different.
If Unity was made in Mono, it would be 1 frame per second. We made lots of experiments using mono for doing 3d and animation in our company as it is fast to program with, but with all the market machine of MS, c# is not designed for some things, but some people just can't stop trying to use the only hammer they have.
On top of that the proportion of code/development time involved with the UI or OS integration on a mobile client tends to dwarf the rest of the project, meaning reusing the guts is nothing like as big a net gain as it would appear.
I think XAML is that format, but it isn't without its pain points. You pretty much can't do animation without a tool like Blend unless you're a sadist.
It looks like Xamarin uses .AXML for Android (maybe a XAML flavor) but has to adhere to Interface Builder for iOS (http://docs.xamarin.com/guides/cross-platform/application_fu..., specifically the Visual Designer section). XAML likely won't gain any traction on those platforms though due to NiH on all sides. HTML/CSS is likely as close as we get for now but that isn't a "native view" in any of the platforms mentioned.
.AXML has no relation to XAML at all. It's just plain Android layouts: when doing plain Java Android dev, they're just .xml files. I believe that Xamarin made up a new extension for them because it allows them to easily associate the file extension with a special editor in the IDE (Visual Studio and Xamarin Studio/MonoDevelop).
Xamarin's Android interface builder is actually remarkably decent.
I think the key to a unified cross platform ui format is going to be another layer of separation of concerns, similar to HTML/CSS.
I think this because I believe that platform-level ui look and feel differences are going to be with us for a long time.
I think you can standardize "what it does" and "how it does it", but you'll have to keep platform specific "how to invoke" and "how it looks" for a long time.
Maybe a MVCP paradigm is what we need, where the controller is split into common controller and platform controller
C# is a pretty weak language[1], and .NET is layers of bad design choices (both of these problems stem from a aggressive OO design methodology combined with poor API taste + a policy of "never break".
Not only that, Microsoft is a monopolist by character, and an unpleasant competitor. It would be a disaster for the world if they regained dominance (much like other companies, but MS brings a particularly domineering flavor).
[1] It's adequate. It gets the job done, adequately. It doesn't shine except in being adequate. I would rather use pretty much any open source language than a .NET one.
Well, I think MS has been drifting away from their monopolistic character. Look at Azure, for example. They give you documentation even to develop and deploy with Java. That's not something I'd expect from the old MS.
Apart from that, why is C# a weak language? I think it shines in features: dynamic typing, code by contracts, runtime code generation (you can generate assemblies in execution time with System.Reflection.Emit), LINQ... you can even use it as a functional programming language. I wouldn't say C# is pretty weak.
Of Java, C#, and ObjectiveC the language I most want as the common language is Python.
That not being an option, C# is decently close to python in expressiveness, certainly better than the other two, and in my appraisal actually a pretty nice language.
Supports both kinds of typing and most functional features. Let's just see what happens when Roslyn finally gets done (something that keeps them busy from keeping innovating on language side)!
My tone was meant to be gently humorous, not seriously precise. I was reminded of a guy on another site who was backing up his arguments with quotes from a book -- that he wrote. When someone called him on it he didn't miss a beat; he said it was a good book four years ago when he wrote it and still a good book worth quoting.
CLR does seem much better than the JVM, but my dislike of it comes from what I see of it in the wild. Any randomly chosen JVM program in the real world has a much greater chance of running on my platform of choice than anything that was developed for the CLR. The JVM has a culture of writing things that turn out to actually be cross platform, the CLR does not seem to.
I can count on one hand the programs written in C# that I use in Linux, and those projects have to explicitly support Linux. Compared to JVM targeting projects where the experience is typically "Linux? Well shit, I don't know. Here's the jar, try it out. Oh, it works? Great!"
If I were writing a new language and had to pick one to target, from a technical perspective the CLR would seem to be the clear choice. But I don't think that is the perspective most people are coming from.
I see people say this but I've never seen an actual reason. I know the CLR was built with this in mind with things like CLS but that doesn't seem like that huge of a deal. There are also some naughties in the JVM like how generics are handled, but that seems more like knocks against the JVM as a whole rather than its cross langauge support.
So legitimate question, is the CLR better than the JVM at cross language support and if so what makes it better?
> So legitimate question, is the CLR better than the JVM at cross language support and if so what makes it better?
Yes in the early days, because JVM was initially designed just for Java and many bytecodes are directly related to Java semantics.
Meaning any language that targets the JVM has to adapt their semantics to Java semantics at the bytecode level, hence the tricks mapping closures to anonymous classes as one example from many.
This got better with the introduction of new bytecodes in Java 7 and the upcoming Java 8, but it is still a Java VM at heart.
The CLR was designed as language agnostic, meaning its design had to support a good implementation of VB, C# and C++ on day one, alongside other languages from Microsoft partners like Eiffel and COBOL as two possible examples.
There is inclusive a .NET ABI for interoperability between languages, CLS (Common Language Specification).
So the bytecode is much more generic and more low level than the JVM bytecode is.
Then thanks to the work done on IronPython and IronRuby, it got the DLR part with allows for better performance of dynamic languages implementations. Since initially CLR was mostly targeted for strong typed languages.
Nowadays both platforms are quite similar in terms of language support.
1) On top of the JVM we've got Scala, Clojure, JRuby, Jython, Groovy, Fantom, very successful, very active, with big communities.
2) On top of the CLR, we've got IronRuby dead, IronPython dead, Clojure.NET almost dead, Scala.NET dead. VB is C# with a different syntax. The only partial success story is F#, executed by Microsoft and I say partial because its impact is less than Clojure, Scala or JRuby, in spite of Microsoft promoting it.
So you see, something is wrong with your assessment and you've been listening too much to marketing pamphlets.
That's not a technical argument. Nobody wants to build on the CLR because its closed source and Microsoft tightly controls it. But the person I replies to claimed it was full of design mistakes, which is different.
The CLR is definitely not full of design mistakes, it's actually quite awesome. But in terms of technical arguments, the JVM is better for dynamic languages, as it can do all sorts of optimizations at runtime that the CLR is not capable of. It's not that Microsoft couldn't improve it, but C# would have nothing to gain as it was designed to not need runtime optimizations (e.g. on the JVM, AOT compiler optimizations can actually get in the way, whereas the C# engineers focus on optimizing the compiler). And the new InvokeDynamic from JDK 7 is amazing. Starting with Java 8, it will even have benefits for static languages, like Scala. Scala for example has the notion of "lazy val", which are final references initialized on first access. In the current implementation, lazy vals have a performance penalty on access, as the generated code implies synchronization on the underlying reference, however Java 8 will make it possible to declare the generated values as being effectively constants.
The JVM also has a more capable garbage collector(s) for more wasteful languages. It makes a world of difference for languages like Scala or Clojure (e.g. functional languages use a lot of persistent immutable data-structures which generate a lot more junk than their imperative counterparts).
On the community side, for the JVM there are more capable libraries for generating bytecode. Also the ECMA standard has been kind of incomplete. For example Mono had to use for a long time their own format for the debugging symbols, while slowly reverse-engineering Microsoft's format. The debugging symbols on the JVM are documented and directly a part of the generated bytecode. Sun made many good choices here too. A JAR is just a zip containing .class files and other resources. It's definitely easier to generate JARs than it is to generate DLLs. I think language developers have a much easier time generating code for the JVM.
There is one feature of the CLR that stands in the way of dynamic languages and that is the reified generics support. The JVM has fewer restrictions, although in truth both suck for languages that are not Java or C#.
Technically, I dunno. But I can pick up JVMs and JVM apps for pretty much any OS I want, can't say the same for Mono/.NET. I'd rather use the JVM for cross-platform JIT language work because of this. Further, the JVM has a broad base of development and support; many companies build products around it & there are multiple JVMs. That isn't really the case for .NET.
So in a head to head on tools + community + buyin from multiple vendors, the JVM wins, hard.
Some people prefer C# over Java and VS over Eclipse, and the Xamarin team will probably do a better job of making cross-platform work than most others.
I suspect it will still lead to many lowest common denominator apps, but it's not like Android doesn't suffer from iOS-portitis and hordes of shoddy apps for other reasons, anyway.
So, they are collaborating, writing blog posts and sharing stages. Of course, Xamarin is also shipping more code, which is what impresses me about these guys.
Miguel has already said Xamarin has had some links (maybe more information sharing than collaboration) with engineers at Microsoft. How is this much different?
This seems like a weak thread. The sort of thing which could quickly cool down or die altogether. There doesn't seem to be any solid commitments here. Of course, we still have the assurance that Xamarin will continue to be impressive.
I just think it's a pretty big leap from this blog post to "maybe Microsoft will buy Xamarin."
I have told people in the past that for every hyped up Mark Zuckerberg - guys who are thought of as programming geniuses by the masses but in reality are just kid hackers - there are guys like Miguel de Icaza who are the real deal and the mainstream world has no idea exist.
Besides his skills as a software developer, I am impressed with the fact that he has held on to his vision and led his company from Ximian, through Novell, then Attachmate and onto Xamarin.
I credit Nat and Miguel for making Linux on the desktop a possibility. (I believe it was Ximian desktop on RedHat that made people finally stop and think, "Hey, there might be something to this after all.") That being said, I wish they had continued down that vein, instead of switching gears to try to make a Microsoft technology "cross platform," and basically failing at the ideal. I tried several times to run a Windows program under Mono, and never could get one to work. For all the talk about how C# is an "open standard," there was always some library that wasn't open-source and hadn't been compiled for Linux which would prevent the program from working.
I think you missed the point of Mono. Windows compatibility is one thing, but being able to use a really nice language that is C# and a really nice stdlib that comes with the CLR on non-Windows OS-es for development is something completely different.
The BCL is such a great tool that I am sometimes baffled by other languages heavy reliance on package managers like npm or gems to get basic functionality.
It is consistent, well behaved and while not complete, it is very solid. The only complaint I have are that it has some dark corners (System.Diagnostics come to mind) and the fact that non of the classes are easily used for testing and that I have to wrap a lot of basic functionality like file system access or the TcpClient to be avle to test my classes.
I don't think that Mono gives you much more in terms of cross-platform compatibility out of the box than say qt or wx do.. It comes to planning, and practice. What it does give you is a really nice language (C#) and platform (Base Class Library) and more for software development. The platform makes it very easy to reference/utilize system libraries (even cross platform ones) to build apps faster on any targeted platform. Being able to utilize code cross platform is a bonus.
Also, in my world (Java) the stack trace is valuable as a software engineering tool. I don't know how folks develop in C, C++, ${other_non_scripting} day in and day out without access to that kind of information. Good debuggers and a ton of printf statements, I guess.
To all those wondering why Microsoft doesn't buy Xamarin, it's probably because Miguel de Icaza and crew don't want to sell. Why should they? There's more to life than getting rich, such as implementing your vision with a family of friends and co-workers. Besides, he'll probably get rich anyway.
Microsoft isn't buying them because devdiv is not a profit driver for Microsoft. Enabling devs to build for other platforms is not a profit driver for them.
They will only buy Xamarin defensively. If they feel like someone else might gobble them up and they will lose access to dev mindshare around c# and mobile.
Xamarin took a lot of VC money. There's little precedent in language and tool vendors becoming big and influential firms. So, they must have had an exit strategy or two. I can't see how selling to MS is not one of those options.
I don't know how to feel about this partnership. As someone whom likes C#, it makes sense. As someone that likes OSS, it brings to mind all the old accusations from the some of the OSS community about the purpose of Mono.
Let's face it, being bought by Microsoft isn't what it used to be and has some downsides, like preventing Google from promoting Xamarin like they should.
This is better than buying Nokia! Finally some smart move from Microsoft. Because C# is a fantastic language, it has powerful tools which other languages lack and Xamarin gave developers a great opportunity(price is high though). I really can't understand some people that are in doubt with Microsoft support to C#. It is the best thing they have done and Visual Studio is the second in my opinion. And Microsoft is well aware of this, everyday we can see Microsoft making a move about C#, .Net and Azure ecosystem. Nowadays, Google is more popular for stopping services and no one bats an eye. Give Microsoft some credits guys, at least for things they are doing great.
...an extended 90-day trial (enough time to write the next
Instagram or billion-dollar Enterprise app from scratch!)...
Seems a tad hyperbolic to me.
I wish Microsoft would just buy Xamarin and freely license the runtime to all under liberal (e.g. MIT/BSD) terms. That would surely be a big win for C# from a mindshare / platform growth standpoint.
Great idea, hard to execute in the real world. I know, I've done it. I built an app with Xamarin about 3.5 years ago. Released it as an MVP to the App Store. I wrote the Android version as well and released it (but went native android because I knew it).I eventually wanted to upgrade some features on my iOS app (Xamarin). I tried finding contractors to do it, and the lowest I could find at the time were around 90/hr. While I could find great iOS devs for half of that. I ended up having an iOS dev re-write the app in Obj-C for much cheaper than it would have been to add new features to the old Xamarin app.
Moral of the story - The idea is great. But the problem is that no one knows how to use Xamarin and those that do charge a premium. If the app is native you can find many more qualified devs that know how to code for the platform at a much more affordable price. All my apps are native now. No more Xamarin.
I loved the product, but from the business side it didnt make sense financially for me to continue to go down that road. Worked great to prove the MVP though.
3.5 years ago is the key. Xamarin has come a long way in the past 12 months, not to mention the past 42.
Developers who know this have grown considerably in that period as well.
On an aside, 90/hr for a competent dev is cheap. I know most people on HN don't make a salary that equates to that but freelancers have an entirely different set of concerns and 90 is low.
I've seen a lot of talk about how far Mono has gone in recent times but not much in writing. Do you have anything about the progress that was made? Blog posts, announcements, anecdotal evedence? I'm looking for stuff to show to the team so we could consider expanding our C# development to linux too.
> I tried finding contractors to do it, and the lowest I could find at the time were around 90/hr. While I could find great iOS devs for half of that. I ended up having an iOS dev re-write the app in Obj-C for much cheaper than it would have been to add new features to the old Xamarin app.
An employee working 40 hours per week clocks in around 2K hours annually. Lets assume a freelance developer wants to have a life and largely stick to the same 2K hours. Within that time frame, the developer has to subtract time for running the business, overhead, sick days, vacation days, gaps between projects, non paying clients and the list goes on. By time time the year is up, a freelancer might be hard pressed to bill out 1600 hours.
At 1600 hours at $90 / hour, a freelancer is looking at $144,000. In most of the top cities of the world (New York, Los Angeles, San Francisco, Singapore, Sydney) this doesn't get you far. This probably doesn't even get you the salary + benefits of a typical engineer with a decent company in San Francisco. And if you have to deal with the stress of running a business, then you should be looking at making a bit more than you would as an employee, otherwise it isn't worth the stress.
At half that rate, you are talking about the same scenario, except for in much cheaper cities. Sure, you're making quit a bit more than the people stocking shelves at Walmart, but you probably aren't even making enough to be worth the added stress of running your own business. You would be better off just by signing on with another company as a salaried engineer.
I think we take for granted that we can pick up a developer from anywhere at any time to work on our idea. We don't have to open a business and go through a bunch of red tape to hire an employee. We need to remember that while that hourly rate seems high, we are still saving a bundle of money over the traditional route.
So, $90 / hour is cheap. I know junior Wordpress! freelancers who charge that because they have to due to their location. In this case, the premium isn't in what they know, it's in where they live. Those same iOS devs wouldn't be charging $45 / hour if they lived in the above mentioned cities. Not unless they are living in Mom's basement.
Keep in mind the above numbers are for someone who can actually run a business. A lot of freelancers are hopeless on the business side and don't last long.
The bottom line is that you were able to get iOS developer to do work at half the rate of Xamarin developers and you were happy with the work. But don't say that $90 / hour is expensive.
I was excited to see the MSDN discount, realized it was double business licenses (Android and iOS bundled together) and doesn't apply to BizSpark or DreamSpark. The discount makes both not much more than a single business license. I can suspect not including the "free" MSDN tiers was done on purpose as well, likely on MS' side. No discount, no benefit of the extended 90-day trial. I can't help but feel my puppy is kicked yet again.
The normal trial is likely not that bad but I consider more than my cost of Visual Studio (yes, free but still) is too big of an investment, at least to pull the trigger. The price to stay in my IDE of choice is pretty steep but there is extreme merit to that over say MonoDevelop.
I'm happy for the partnership but I shouldn't have expected any more than what I'm being given. That's my problem, but one I felt the need to lament about in case someone else tries to do their own digging to come to the same conclusion...
> If this results in a useable, performant (e.g. NOT mono) C#/CLR implementation on *nix, that makes a lot of things very interesting.
I'm not sure what yiou mean by this.
Do you mean you want a new implementation that inst' mono?
or that you don't believe that mono is fast?
if its the later then I'd have to disagree with you. We use mono for a real time trading system and find it to be more than capable of handling our needs.
After many of its iterations have been posted to HN with little improvement in quality, it's clear that the point of the benchmark is to tout certain languages like Java, so this is not surprising
My 2 cents: I recently needed to run some .NET code which (1) relies heavily on floating point math and (2) constantly creates and destroys lots of objects in the course of said number crunching. A typical run would take from several hours to more than a day.
Doing this on Linux with the latest Mono proved painful: it kept crashing at random points, with native errors suggesting the problem was in Mono's memory management. The same code never crashes on Windows/.NET, and it runs 3-4 times faster (same hardware booting off a Windows partition instead of Linux).
This is not what I would like to report, because I really like both Linux and .NET, and I would love for Mono to be competitive. Maybe today's news will contribute to that happening.
Nothing in this press release points towards such an implementation. Mono and Linux aren't even mentioned in the entire article. This is all about C# -> Android/iOS. In fact, it weakens the future of Mono by making Xamarin stronger in MS's ecosystem with the whole VS 2013 integration and MSDN subscriptions.
It's hard to see this as anything except Microsoft playing 'me too' with app developers as people flock away from their CLR for mono.
It's good for c# developers, there's no doubt, but I'm suddenly wary now; I can well imagine a future where Xamarin is bought by Microsoft and their tools become Microsoft lock in. That's not a future I'm enthusiastic about.
I knew it could (with Xamarin's thing they did rewriting Android in C# to test performance) but I didn't know that's how it worked for the stuff you build with their tools. That's awesome.
I can only offer anecdotal evidence, but mono runs quite well on FreeBSD; it may not be 100% as fast as the CLR on Windows, but it's still plenty quick.
In fact, it ran so well, I later wrote up an installation guide on the F# Foundation website (http://fsharp.org/use/freebsd/) and I've heard other users have had similarly good experiences with this combination.
Can you give specific examples? As far as I know, every improvement to MonoDevelop and Mono has been contributed back to the open source projects, which benefits Linux users as well.
My team is currently working on a project targeting Linux using Mono and MonoDevelop, with heavy use of OpenGL and the like. The recent improvements have been great.
So, I'm very curious, what is your actual complaint?
If open source projects like that can't stand without constant corporate attention, should they stand? It sounds like they're trying to get stuff in to the hands of people who are actually interested.
Is there a way to toe dip into this? I've got a a bunch of Objective C code and I'd like to try some C#, which I could then use for my Android app. My hesitation with any non-blessed solution is that you can get 90% of the way, then you're screwed by some limitation.
To me this seems mostly about Microsoft Phone(and perhaps in the future tablets). It will help to get more WP apps out there if all it takes is a rebuild of a Xamarin iOS or Android project. Makes sense. I'm guessing Xamarin gets a cash infusion in return.
It's possible to start to see an internal problem for MS breaking out between this and any development of VS to being web based: their tools division and the Windows division appear to be heading in different directions.
For example, the tools people might succeed in making non-Windows clients far too attractive and easy to deploy to, while simultaneously making sure you don't even need to be on Windows to be using the tools.
Not saying this is without merit as plenty of people would love proper C# tooling off Windows, and arguably the real use of Windows remains in hosting Exchange servers, but it really looks like even MS don't believe Windows is the end user system any more.
