

“C#, it’s just not portable” - DonnyV
http://www.fastchicken.co.nz/2011/09/15/c-its-just-not-portable/

======
evilduck
You _can_ use C# everywhere, but in practice it just seems like a huge effort
to avoid learning a new language to me.

I have nothing against the language (writing C# is half of my day job), but
all of these bridges are second-class citizens and built and maintained at the
mercy of third parties just to interface with your target platform. Apple will
never release updates for MonoMac or MonoTouch. Google isn't going to release
C# Android SDKs or documentation. Mono for Linux always trails the Windows
version and has significant community resistance, and Microsoft isn't going to
integrate and maintain these bridges.

You're also always losing something in the translation too, be it idiomatic
style of the target API or C#, or being totally cut off from new native
features, or severely restricting what community support or documentation is
available to you. Any way you cut it, it's a second class experience. Worse,
some of the bridges aren't free. You get to pay $400 for the privilege of not
learning a little bit of Java or ObjC to get MonoTouch for Android or iOS.

C# is good, but it's not so good that I refuse to learn other tools.

~~~
stonemetal
While I fully agree with the losing something in translation. I don't agree
that people are trying to skip learning things. It is a do I want to do 100%
of my software development 3 times because I need a java version for one
platform, Objective-C for the second and C# for the third.

Oddly enough it seems like C++ is the only language all three platforms
support natively.

~~~
evilduck
Mono for iOS and Android and MonoMac for OSX all have different API calls for
their respective platforms. GTK# is its own thing too. You might avoid a total
rewrite from scratch, but the UI is going to need significant tailoring to
each platform still. And it's not like Java, ObjC, and C# are radically
different from one another.

Does keeping C# as a constant really solve this problem? (I honestly don't
know, I've never done a multiplatform product like this)

~~~
eropple
Welp, here's an example. My project Flatland[1] is intended to be a 2D games
library, providing graphics, audio, input, content loading, and a few other
bits. My target platforms are Windows, Mac, Linux, iOS, Android, and WP7.

With a properly architected solution (and I like to think mine comes close)
with sufficient abstraction, I literally _can_ write a game once--with
allowances for fundamental platform differences, i.e. "is this a touch device?
then show on-screen controls, but wire them to the same backend logic"--and
deploy it everywhere. I can't do that with a Java engine on Android and an
Obj-C (ugh) engine on iOS, because there is no reasonable lingua franca. C#,
on the other hand, works fairly well everywhere. The platform-specific bits
are small, clearly delineated, and shouldn't take long to do (it's Windows-
only for now).

[1] - <http://bitbucket.org/eropple/flatland>

~~~
evilduck
You also get the luxury of ignoring many of the native UI paradigms with
games.

~~~
eropple
That's true. I don't have to deal with native UI libraries. Instead, I also
have to deal with disparate interfaces to graphics, audio, sound, the file
system (if it's accessible at all), the content loading paradigm for the
platform (relevant esp. for Windows Phone 7), timing differences between the
platforms, and a number of other issues. I have to develop and code to lowest-
common-denominator interfaces that contain a lot of hidden gotchas and
limitations, and make the presented interface work _identically_ on all
platforms.

I'd take re-coding my UI layer over having to write near-identical code for
XNA and OpenGL, then writing near-identical code for OpenAL, XNA, and Core
Audio, then writing widely divergent input code for XNA and whatever not-well-
standardized gamepad layers I can repurpose or build for Linux and OS X and
the different touch frameworks...

Having to write all of this stuff is arguably on par, if not more complex and
difficult, than reimplementing a UI layer. It's not a "luxury" at all.

------
jcromartie
Just like most languages, you can take some subset of C# and run it in many
places. And, like most languages, there is some corner of the language that
doesn't work on one platform or another. And most importantly, just like most
languages, you end up depending on various libraries which may or may not be
tied to hardware which makes significant parts of non-trivial applications
non-portable.

People don't make games in C# because it's C#. They make games using C# and
XNA, or Unity, or some other framework. They don't make web apps in C#, but
rather in (whatever flavor of) ASP.NET. And it turns out that these frameworks
are the important bits.

So when you choose to write something in C#, you are probably going to be
choosing a framework that ties you down to a platform, and that's where the
cross-platform nature of the language kind of becomes irrelevant.

That's my experience, at least.

If Clojure takes off on other runtimes, it will have this issue too. The JVM
is it's "home" platform, and most Clojure software depends on JVM libraries,
like how the vast majority of the C# software written thus far depends on
Microsoft (and therefore Windows) libraries.

~~~
berntb
>>If Clojure takes off on other runtimes, it will have this issue too. The JVM
is it's "home" platform, and most Clojure software depends on JVM libraries,
like how the vast majority of the C# software written thus far depends on
Microsoft (and therefore Windows) libraries.

There is a small difference.

The Clojure/JVM runtime is ported to _quite_ a lot of operating systems, where
it runs quite well.

------
sreque
C# is a good production language. It lets twiddle you your bits almost as well
as C when you need to, provides a decent OO model, and has been piling on more
functional and dynamic features as the years go by. However, as someone who
has had to port a .Net C# app from windows to Linux, I can witness with
sincerity that C# is NOT very portable.

First of all, a lot of the C# APIs are written with windows in mind. An
example is system mutexes. These just don't exist on Linux, and the mono
implementation to emulate them is very buggy. Another example is the process
counter API. Although much of this same information is available on Linux via
the Proc table, Mono provides no equivalent API because it would be a lot of
work to make one that works on all the Unix variants. There are many such
examples of C#'s windows-centric API not being ported well in Mono.

A bigger problem with Mono is that it just wasn't stable for us. The more
standard library features we used, the more it would core dump on Linux even
though it would never crash on windows. We ended up re-implementing a lot of
functionality available in the standard library ourselves before the program
stabilized on mono, which further incriminates the Mono stack. As a final
note, we tried multiple versions of Mono, including 2.4, 2.6, and 2.10, and
none of them worked well for us.

If you want to write a fairly performant cross-platform app, the JVM is still
a much better place to play in right now than .Net, even though I like C# the
language a lot more than I do Java. You can also go the route of combining
your favorite scripting language with C for the CPU-intensive parts.

------
nathanb
These days it seems like much of a language's benefit to developers comes from
its libraries rather than from the elegance of its syntax or the ease of
implementing an algorithm. The big question is, how much of the "standard"
libraries are supported on these devices? I remember writing a C# application
using Winforms back mid-last-decade and assuming that portability would be a
cinch...right up until I realized that Winforms weren't supported by Mono yet
and I was supposed to use Glade# or some such nonsense. C#'s mindshare mostly
comes from Windows GUI developers, and telling these folks that they can use
their pet language only if they relearn all the libraries isn't going to be
much of a win, I don't think.

------
peterknego
You could make the same argument about C, which exists on much more platforms
than C#.

But writing in C does not make a program portable. Neither does writing it in
C#.

So yes, C# compiler might be portable, but programs written in C# are not.

So yes, C# compiler might be portable, but C# programs are not.

------
qusiba
C# as a system language running on Mono is actually usable. But the thing is,
I've never seen an IDE worse than MonoDevelop. Writing C# without Visual
Studio, a large part of the benefit of the language just disappears.

I would only use C# for window jobs, although I sincerely think it's a
beautiful language.

------
sgt
I am currently writing an "enterprise" style application and backend framework
(WCF, Fluent NHibernate, Castle, json-emitting webservices, etc) based on C#
and Mono. I'd like to hear more stories of others doing the same. Mono has all
the functionality I need, the only possible worry that I have is that of the
default GC (and I don't know if the newer GC is stable enough).

------
knotty66
Is anybody using Mono on Linux for ASP.NET MVC3 apps in production?

If so, is it stable, fast?

I wonder how it compares speed and stability wise to the Java Play Framework.

I am currently using Play (and it's great!) but I much prefer C# as a language
to Java ...

------
jinushaun
Interesting. I always thought the Vita was running Android since it supports
Android apps.

~~~
seanalltogether
Are you sure about this. Reading their press release leads me to believe it's
the other way around, that by developing for the Vita SDK, you can cross
compile to Android if you choose.

 _Supporting C# as the programming language, PS Suite SDK can run programs
developed in C# on virtual machine equipped on both PS Certified devices and
PS Vita. By supporting development for multiple devices and by adopting
libraries to create a variety of content not only limited to games, PS Suite
SDK will not only help developers save their cost in creating new content but
also allow them to efficiently create their content on one SDK and without
having to create on several different SDKs.

Through PS Suite SDK, SCE will provide to game developers and publishers the
potential to further expand their business opportunities to Android based
portable devices._

[http://www.prnewswire.com/news-releases/sony-computer-
entert...](http://www.prnewswire.com/news-releases/sony-computer-
entertainment-to-offer-software-development-kit-for-playstationsuite-starting-
this-november-129854503.html)

------
funkah
I feel like there is too much attention paid these days to who badmouthed your
precious programming language, or whether your language has the appropriate
amount of respect, or whatever. I'm a C# dev, sometimes. People have been
hating on it (and its devs) for years, but it just doesn't matter. Get over it
and use whatever language or other dev tool you want.

~~~
mattgreenrocks
Usually, hate-ons are perpetuated by those who lack the skills to make shit
happen. Or, at least, that's been my experience. They're usually more
concerned with Being Right On The Internet than anything else.

------
drivebyacct2
You might be able to write C# and target different platforms, but I've yet to
be convinced that a codebase can be shared across platforms as easily as some
other languages/platforms.

~~~
DrJokepu
We run non-trivial, large, unmodified .NET 4 C# ASP.NET MVC web apps (compiled
on Windows) on Mac Mini Servers on OS X with Mono and Apache. Never had a
single problem. It's almost creepy how well it works.

~~~
zwp
That's interesting. Why do you do this?

~~~
DrJokepu
Well, it's complicated, but the main reason is that since our premises are
just around the corner from one of the biggest Apple Stores in the world, we
can replace any of our servers literally within minutes if they fail. This
makes me sleep a lot easier at night.

Also the savings on the electricity bill are not negligeable either.

~~~
traskjd
>> our premises are just around the corner from one of the biggest Apple
Stores in the world, we can replace any of our servers literally within
minutes if they fail

I sure hope you don't have a server failure outside of business hours :-)

~~~
DrJokepu
I think we're prepared for that too. First, we have a few currently unused
previous generation Mac Minis lying around that could be used temporarily.
Second, since everything we need (Apache and PostgreSQL, minus Mono) comes
preinstalled with OS X Server, these machines can easily take over each
other's tasks temporarily, e.g. the database server can become a web server
too until we can get a replacement. It's not ideal but it'd do during off-peak
hours. Fortunately, the Apple Store is open even on Sundays so even in the
worst case scenario we could get a replacement within 12 hours max, which is
not necessarily the case with, say for example, Dell servers.

