Microsoft and Xamarin partner
blog.xamarin.com
blog.xamarin.com
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
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.
I predict Xamarin Build Cloud.
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.
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.
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.
EDIT: Apparently they haven't updated their nuget packages and some of these components truly are licensed under FOSS, per: http://weblogs.asp.net/scottgu/archive/2012/03/27/asp-net-mv... and https://news.ycombinator.com/user?id=adolfojp
The license that used to cover all of these, and that may still cover some of the components is this:
http://www.microsoft.com/web/webpi/eula/aspnetcomponent_rtw_...
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.
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.
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.
It takes away from your main arguments and distracts.
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.
Which I commented on here: https://news.ycombinator.com/item?id=6727423
At best, they are under a free commercial license. They are not available under FOSS licenses.
http://aspnetwebstack.codeplex.com/license
http://entityframework.codeplex.com/license
http://weblogs.asp.net/scottgu/archive/2012/03/27/asp-net-mv...
I suggest updating your comment.
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.
EDIT: actually, the last paragraph is not true anymore, thanks to this: http://blogs.msdn.com/b/dotnet/archive/2013/11/13/pcl-and-ne...
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.
[1] http://ceklog.kindel.com/2013/02/21/james-gosling-screwed-us...
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.
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.
Saying that the apps generated don't look "native" doesn't support the assertion that WORA is a "failure". Doubly so considering the ubiquity of Java.
Otherwise it sucks.
Well the web doesn't have a native UI. But iOS and Android DO have one.
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.
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.
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.
Xamarin's Android interface builder is actually remarkably decent.
I couldn't easily associate .xml with the designer in VS since everyone uses .xml.
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
You mean QML?
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.
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.
I like how you give a citation then cite yourself
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.
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.
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.
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#.
So in a head to head on tools + community + buyin from multiple vendors, the JVM wins, hard.
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."
Edit: Fixed errors.
That said, I still think Amazon will buy Xamarin.
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.
Like Jobs vs. Ritchie? Yeap, mainstream world is a popularity contest and popularity contests are not famous for being fair.
I have no first hand knowledge on that, I just don't imagine this is a very fair comment.
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.
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.
...an extended 90-day trial (enough time to write the next
Instagram or billion-dollar Enterprise app from scratch!)...
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.
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.
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.
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 definitely do agree with you on many points. It is largely very much location dependent as you've pointed out.
For example, a $90/hr rate in Canada (where I am) is a decent rate, and goes far, considering the low overhead.
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...
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.
If you could share details on Mono tuning for server workloads, It'd be very interested.
But it's down at the moment http://downforeveryoneorjustme.com/shootout.alioth.debian.or...
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.
By the way, did you test with the new garbage collector? (Enabled by default in Mono 3.2.x)
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.
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.
This is just a very very sad sellout tactic. Way to kill off the Linux ecosystem.
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?
I see this as win/win.
I might even consider buying MSFT stock after 12 years of ignoring it... :)
Same goes for Java libs: docs.xamarin.com/guides/android/advanced_topics/java_integration_overview/binding_a_java_library_(.jar)/
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.
I'm not getting a Mac to try it out, and in Windows I have VS.
It has that name because in Linux the Xamarin offerings don't work, therefore they're not included in MonoDevelop.
Dec 11 Buenos Aires Argentina - https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=...
Dec 3 'Online New Zealand' (webinar) - https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=...
Nov 28 Auckland New Zealand - https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=...
Nov 27 Santiago Chile - https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=...
Nov 26 Wellington New Zealand - https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=...
Nov 21 Brno Czech Republic - https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=...
Nov 19 Praha Czech Republic - https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=...
Search: https://msevents.microsoft.com/cui/AdvancedSearch.aspx?cultu...