Xamarin makes me sad, here is my message to them
gist.github.com
gist.github.com
Having said that, I gave Mono for Android a try as a hobby again this year and it was light years better than when I left. (Congrats guys!) However there were definitely still bugs that were mildly annoying as a hobbyist that I can see would be infuriating if I had to rely on it for my job.
They make fantastic tools, but they really do only target Windows.
I can't even think of a way to do it safely in Java without "BufferedBuffer" hell
Even setting aside advancement and research, it's hard to really create a real competitors to Microsoft's existing solutions even when they're terrible. NHibernate is the "best" one I can think of and it's kind of trainwreckish. Outside of that--like, NancyFx has been around a long time at this point but hasn't really made a dent, whereas the JVM application server is rapidly losing ground--and it literally cannot come soon enough for my liking--to frameworks like Dropwizard or Play. You can fight the Man on the JVM and win; I'm not sure you can do so on .NET.
That isn't to say .NET doesn't have some significant pluses. If you stay in the sandbox and can stomach having to deal with non-Unix command line tools or Cygwin (haaaa ha ha ha), it is really really nice. But the second you go off-roading, bring a helmet.
Overall I like Java quite a bit, it's the first thing I reached for when I migrated away from .NET development, but Eclipse/Java dev still doesn't feel as snappy on my Macbook Air with 4Gs of ram as dev with VSExpress 2005 was on my old Dell. Le Sigh.
(edit: JDK8 and the G1 collector have made my life a lot easier when I have to tune the JVM. I think you gotta cut it a little more slack these days.)
(I like WPF. But I'm weird.)
We even get to have the "J2EE" version of .NET with all those model view patterns.
Some builtin features that Sun/Oracle leave for third parties.
- It always JITs. Either at runtime (JIT on load) or at installation time (NGEN).
- Windows Phone 8 .NET applications are compiled to native code, to an executable format called MDIL. Native code with symbols left for linking.
- A new JIT in the works that offers SIMD instructions
- A native compiler for static binaries based on the Visual C++ backend (.NET Native)
- Value types (In discussion for Java 9)
- Flat arrays
- Native interop (JNI sucks, Oracle also recognized this)
- Real generics.
Regarding the first issues, Java also offers them, but you have to buy a commercial JVM as the standard Oracle tooling doesn't offer such features. There is the Graal/Substracte VM at Oracle Research, but who knows when integration will happen.
Regarding the last issues, they were discussed at JVM Language Summit 2014. Some of them might be fixed in Java 9 timeframe.
http://www.oracle.com/technetwork/java/javase/community/jlss...
what is a flat array?
By value type, you mean assignment causes deep copy instead of reference copy?
What is the advantage of a static binary over just shipping the jvm (which you are certainly allowed to do)? I guess I could see it if you are writing end-user software, but the jvm is pretty much server-software and devtools at this point.
What do you mean it always jits? So does the jvm unless I misunderstand what you mean by jit.
simd is beginning to make its way into java, but numerics are not the jvm's strong spot. I didn't think they where for c# either. Is this incorrect?
And yeah, jni is fucking awful.
Real generics would be nice.
Thanks for your answer.
In multidimensional arrays you do one single allocation instead of n times m time k times ... allocations.
You can fake this in Java by allocating one major block and doing the math for the respective cell yourself but it is cumbersome.
> What is the advantage of a static binary over just shipping the jvm
The same as doing coding in C and similar languages. Guess one of the reasons why Java lost the desktop.
> What do you mean it always jits?
There isn't any interpretation going on. On most JVMs you need to set execution threshold to zero to achieve similar behavior.
On most JVMs, it is a two step process as they start interpreting and only hot methods (this is customizable on most) get JITted.
> simd is beginning to make its way into java
It is still not clear if it will make it into Java 9 timeframe.
> Is this incorrect?
Yes, as C# as managed to place itself as "good enough C++" on the Windows world, for many use cases.
I've shipped single jar programs -- it's pretty simple to repack everything -- and I believe (but am not 100%) that we included the jvm in there, so it can be done. At the expense of a 100+m download, but for our use case, that was not an issue.
Have you seen performance improvements from forcing always jit? I've played with similar settings and only really found them useful for benchmarking.
I'm surprised you're seeing c# for numerics on windows; I thought there wasn't much besides games that needs to be local and isn't written in c++ these days, either for performance or because the codebase is old. I work on ml programs, mostly c++ and java.
Bioinformatics
(I know, I should be using D, you say)
EDIT: Should have mentioned Zing instead of Azul.
It is a bit hard to search while on the move.
Doing what Xamarin does is VERY hard and Xamarin hasn't had big-time funding until recently. And they can't stop and just fix bugs, like the article author would like. Xamarin is on the treadmill and has to keep up with two platforms that are in competition with each other. The only good news in that is that they will probably converge in terms of capabilities. But, damn, I wouldn't want that job.
3rd party dev tools are a thankless and usually VC-less pursuit. The investors are probably hoping for an exit in the form of Satya Nadella taking C# and VS cross-platform and using it for Microsoft's own apps.
https://www.ibm.com/developerworks/community/blogs/mobileblo...
Weird.
Have you considered Ruby? With Ruboto for Android and RubyMotion for iOS, I'd think you could get a pretty good single-codebase solution. I ask because as a Ruby dev who may one day branch out, I'd like to know what I'd be getting myself into, and it sounds like you might have gone down that road.
http://blog.rubymotion.com/post/97668474211/announcing-the-p...
If the client's demanding a single-codebase solution for both Android and iOS and you are better at Ruby than you are with either Java or Objective C, then it might make sense to sell the client on using the beta.
I think RubyMotion could be a good idea, even today, for someone that knows and use Ruby for his own projects.
Except this is not possible, as you have to recode the UI for each device anyway.
So just go C++, or any other language with compilers that can target C, and do as little as possible in the UI part.
Companies like Dropbox are following this approach.
All that said, I would normally advise a client not only to have native code, but also large amounts of native design for their main platform targets. Lots of Android apps suffer from port-itis. Transliterating an iOS implementation inevitably makes for a lackluster Android app that underutilizes Android modularity features among other things Android does well.
I can definitely see how chasing Apple, Microsoft, and Google's yearly mobile API revisions can be a task. I don't think that necessarily justifies throwing the entire project out (maybe just some careful evaluation of their mobile oriented offerings). It's akin to throwing all of Java out due to your displeasure with Android development (of which I have a long list of grievances).
My experience has become that TypeScript is really only suitable for classic OO domain programming, with many nice little classes and mutable state. I work on a project where our model layer (MVC) is made like that, and it works like a charm.
Interfacing with other libraries tends to work ok, but you'll have to forget about using --noImplicitAny (and hand in a whole bunch of safety guarantees with that). Doing non-classical-OO stuff quickly becomes a pain. I recently spent many days making a nice Om-style immutable model layer with TypeScript and Immutable.js, and it just doesn't work. The generics simply aren't powerful enough, and I spent days (and many worthless lines of code) fighting it. This saddens me.
General rule of thumb; if you're building "content" apps you can get away with Titanium. If you're trying to build awesome experiences you'd have to go native and Xamarin is currently the best cross-platform suite out there.
BTW, the OP's original rant reminds me of a similar rant for Titanium: http://usingimho.wordpress.com/2011/06/14/why-you-should-sta... That rant is a few years old and Titanium has made a lot of progress since then. However, some of the points still hold true.
I just lost a few days of development researching Qt for mobile. With the outcome that it still has a lot of catching up to do.
First issue that was found. The common file dialogs present a desktop file selector on mobile devices! Apparently this is being fixed for 5.4, but it requires the UIs to be written in QML. No such luck for those using pure C++ Widgets.
Then the documentation about Qt Quick versions, how to integrate with C++ Widgets and the various ways the deployment to mobile devices can be customised requires a bit o hunting and asking questions on the forum.
On my case we had deployment working without issues in the emulator, only to be greeted with a blank screen on some mobile devices.
Since a good UX requires using the expected platform behaviours, the best approach is to use C or C++ for logic with a thin shim for the UI and device sensors.
Way more productive than hunting third party integration issues, without any guarantee of having them fixed.
As an equally (un)valuable counter-anecdote: I spent about 9 months developing a set of apps for Android and iOS with Xamarin and didn't encounter many of these problems.
We did find one bug in the toolchain. We reported it, Xamarin responded with a workaround in 1 day and a fix in 7.
From what I can tell it isn't that great for the end user either. I recall once trying to install a mono based tool on OSX. It was... unpleasant and I ended up simply choosing not to use it.
I recently tried downloading MonoDevelop on OSX, and poked at an ASP.NET MVC 3 web app. Straight out of the box I couldn't run it without an error popping up I couldn't get rid of, so I ditched it.
Except they don't offer a multi-platform UI toolkit. Xamarin.Forms is quite recent and the amount of bugs shows it still has lot to improve.
I liked Miguel de Icaza's measured, helpful way of saying 'get bent':
Exception stack traces are the easiest problems
for us to fix. But we need to get a copy of the
exception.
Would you be so kind of filing a bug every when
you get those exceptions? Whatever settings you
have or environment you are using is different
than mine, and I have not experienced those
problems personally.Expecting people to go sign up for your bug tracker and blah blah blah about a bug in your basically-commercial software is such a fundamental failure to understand people that to me it's pretty much a statement that no, you don't care. If you're seriously interested in fixing bugs people kvetch about on Twitter, get your developer relations people (you have developer relations people, right? (if not, why not?)) to send an email and do the legwork around a bug.
And frankly, I feel like "file a bug with an exception trace" is a method of symptomatic treatment rather than the fairly core auditing and testing that most of the Xamarin software I run into on a semi-regular basis really needs. From the outside, a lot of it feels rotten. Picking off an exception here or there doesn't seem likely to cure the disease, it just lances a boil or two.
Nice updates to Xamarin Studio. Too bad they can't fix that pesky "indenting pukes on itself" or "lines disappearing in the editor".
And all I did was ask you for information about this, purely because I had not experienced it myself: @edropple bug report please
But for the record, you do not need to sign up for our bug tracking system. You can email your concerns, complains to support@xamarin.com who will be happy to shepherd your problem through our developers.As for filing the bug with the exception: I am merely trying to prioritize someone with a bug right then. We do get crash reports with the exceptions, and we go through those and fix those.
The only reason to ask for the exception is to provide you with better support and address your fix faster.
Series A: $12MM Series B: $16MM Series C: $54MM
$82MM and they still haven't fixed the fundamental issues that have existed from day 1. Stability and support should always come first.
I just stumbled upon this https://gist.github.com/anonymous/38850edf6b9105ee1f8a and decided to write one too. I don't have affiliation with the OP, but I like his idea and really understand his points.
I used Xamarin for the past year or something, not givin real date to keep this anonymous so they dont block my account ;) All the information here is subjective, I'm just expressing my rage in a very emotional way, take it with a grain of salt. Xamarin, if you're reading this, PLEASE TAKE SOMETHING POSITIVE FROM THIS AND GO FIX SOME BUGS.
TL;DR: I love C# more than any other language, but Xamarin is HORRIBLE. I wish it and mono were never invented. It's a disgrace, completely broken and buggy and just the most broken thing in the entire universe, but I still use it.
Why? Because I can write for 2 platforms as if it was one. haha, not really ... but because I work on small apps, I don't have to write all the business crap twice. That is good about Xamarin, that is the only thing. They can actually compile plain C# ... hooray. If only the rest of the crap expensive broken Xamarin crap library actually worked as advertised.
I'm sorry for being so dramatic, but really if something costs a thousand dollars a year per platform, you kind of expect the damn company to put some love into the thing. You would expect bugs to get fixed, and for things to work. But no, that is not the case.
Look at Xamarin Forms. Oh a shiney new thing that builds real cross platform UI, so nice. EXCEPT THAT THERE ARE MILLION BUGS IN IT. Fundamental bugs, crashes, memory leaks and other memory issues, broken resource handling ... just serious things that normal company would never release to public, but Xamarin debugs on paying customers, on customers who pay thousands of dollars.
If you don't believe me, go to https://bugzilla.xamarin.com/ and look at the bugs, or look at mono release notes. Just look at the list of shiny features of Mono (http://www.mono-project.com/docs/). Well half of that crap is either broken, or was never implemented, or just doesn't work as documented. Everything is just a lie that should make it look good. Xamarin does thousand things, they release new iOS SDK the same day Apple releases it ... wow ... if only they waited a year and then released a working version instead. They make thousand cool features, but they're all broken.
All developers make mistakes, we all create bugs ... but software that costs a thousand dollars should work. It shouldn't leak memory like a total noob, it shouldn't crash the compiler when you compile, and it should work the same way when you compile once and when you compile twice, really the compiler is sometimes just so broken.
PLEASE STOP ADDING NEW THINGS, STOP MAKING INTERFACE BUILDERS AND SHIT THAT WILL NEVER WORK, AND JUST FIX SOME BUGS. I want to say something positive, but really I just want to scream and cry and I don't know what to say.
I wish I could use something else, I wish I could go back to doing things native, but the things I work on are too invested in Xamarin that there is no way back ... I guess I'll just have to run away.
Oh btw, in case you're writing something important, like something working with money, or human lives, or just moving around pictures of cats, pick some other technology, maybe go with native C++ if you want to share your biz logic. Maybe write it as a native things, just please, be careful. There are dragons here.
A closing thought. Xamarin is trying to do something amazing. Xamarin.Forms is an amazing technology and makes me really happy at times ... but then I try to do something special and find 50000 completely stupid bugs on each platform, and I start raging again.
Please Xamarin, I'm begging you, allocate more humans to fix the bugs, stability is important. And if you manage to accidentaly fix something, please don't break it. I'm always shitting my pants whenever there's a new update, because almost always things get broken.
P.S. I'm writing this anonymous because I'm trying to say what is really in my heart. I wouldn't be able to do this in any ot her way, because if certain people found out, I could lose my job, and I value it too much. But still I think this is the right thing to do. I'm not trying to put a bad light on Xamarin, I just want to express my feelings.
Xamarin requires anyway an UI implementation per device.
The time spent fighting integration bugs can be used in productive coding instead.
My little Qt review, which I posted in a sibling thread, reminded me why using the platform tooling is always the best approach.