

C# and .NET's Sudden Ubiquity - numo16
http://www.drdobbs.com/windows/c-and-nets-sudden-ubiquity/240169282

======
untog
Good post. It's funny, because C# has been ubiquitous for a long, long time -
just not in cool areas like the startup scene. I was a C# web dev for years
before moving onto using Node or Ruby as a backend in order to be able to work
on more interesting projects.

I look forward to a future where C# is more ubiquitous, because, as the post
states, this will largely come at the expense of Java, which has always felt
like C# Only Not Quite So Good. Cross-platform these days means a lot of
mobile work, and if we can write our server backends, iOS Apps and Android
apps in one language that's a big win.

~~~
serve_yay
I used C# for a long time before moving on as well. Mostly web stuff, but also
desktop software and services (Windows equivalent of a daemon). I always
really liked the language, and the libraries are mostly pretty good, but it
being tied to Windows and especially IIS was always a real problem.

But I think .NET has also long suffered from a more anemic ecosystem than
other platforms have. Things like a package manager have just recently come
around. Things like tooling and educational resources seem more spotty than
for other platforms. (Although some of the for-pay .NET tools are really,
really nice.)

So, I too would like to see it used in more interesting ways than line-of-
business desktop/web apps. But I wonder how the above things will play out.
I'm really glad it's not so tied down to Windows anymore. But maybe there are
other issues to resolve, now.

------
andyhnj
I'm not sure about this statement: "Of these platforms, Linux is clearly the
most important. Today, Microsoft earns much of its (record) profits from
enterprise software packages (SQL Server, SharePoint, Exchange, etc.). By
running .NET on Linux, it now has the ability to run those apps on a
significant majority of server platforms."

Are significant portions of SQL Server, SharePoint, and Exchange written in
.NET managed code? I would have thought most of the code base for that stuff
would still be in non-managed C++. Will having .NET on Linux make it
significantly easier for them to release SQL Server on Linux?

~~~
custardcream
Virtually none of SQL server is. Most of SharePoint is. Exchange is all c++
still.

So we might see SharePoint for Linux yet.

The other two I suspect are very tied to win32.

~~~
tracker1
I know that a lot of SQL is likely still C/C++, but MS does put a bit of
effort into being able to be cross-platform. I don't know how much of SQL is
tightly coupled to windows, but it wouldn't surprise me if MS wanted to they
could do a linux, or OSX release.

Just look at SQL's installer for tools, it really seems to be a gui on top of
some cli tools. Its' origins are in Sybase, which IIRC supported a few
platforms early on. MS-SQL is a pretty good value compared to say Oracle. The
management interface as well as scaling (replication) support is very well
integrated. I've wished PostgreSQL could get to this level in the box for
years now.

I think this has more to do with developer mindshare than anything, especially
with Azure as a platform. If you can write .Net apps and run wherever it's
very appealing. Even with Mono it was a nice story to have. Integration with
system libraries to .Net is much easier than Java's JNI and the like. If I can
write C# in VS and deploy to Linux as easily as with windows, it will likely
return as my back-end of choice.

------
pm90
" .NET has a key advantage over Java in its support for clients. Despite the
significant improvement JavaFX delivers over Swing, Java is no one's first
choice for writing desktop UIs, whereas .NET is standard for business
applications. "

This will be interesting. Obviously, .NET is the best way to make desktop GUI
in Windows; I wonder what they will do to support GUI creation on Linux and
OSX.

~~~
gagege
A WPF like framework for each platform would be very nice. Code the interface
three times and share back end code between them.

I also like Xamarin.Forms' way. Describe, in general terms, what you want the
interface to look like, and it generates native GUIs for Windows Phone,
Android, and iOS that follow each of their different UI conventions (tabs at
the top, tabs at the bottom, menu button, etc. depending on the OS).

------
megaman821
It's weird the C#, CIL, and the CLR are more open than Java, Java Bytecode,
and the JVM.

Java has many more high-quality open-source libraries than C#, but hopefully
over time C# will catch up.

------
palindrone
"Java is no one's first choice for writing desktop UIs, whereas .NET is
standard for business applications"

From my PoV neither Java nor .NET is the first choice for UI. HTML and JS is.
Especially for large multi-million dollar software. I know what I'm talking
about here. Yes, HTML&JS are bad and crap, but may times better than applets
or desktop apps. Nobody likes vendor lock-in.

When it comes to server side .NET is much worse than JVM.

So now, you got the picture why Mincro$oft made this desperate move.
Developers, developers, developers...

~~~
chrisbro
Could you elaborate on why server-side .NET is much worse than JVM?

~~~
custardcream
I'll add something here. The CLR is a PITA when it goes wrong. Its a total
bastard to debug. JVM on the other hand has wonderful instrumentation
capabilities at runtime.

At best you get a minidump out of a CLR process that is misbehaving and take
it to bits inside VS. You may or may not catch it doing bad things. Most
likely you'll find yourself with half the threads inside win32 and an 20 mins
wait for symbol server to snag the symbols.

~~~
UK-AL
Perfmon? Performance Counters? Tons of instrumentation for .net

~~~
custardcream
That's of absolutely no use when the box is under heavy load. Perf counters
just stop working.

We had a system wide thrashing problem with ReaderWriterLockSlim which doesn't
work properly under load. Took 15 mins to log into the box to blast the
process. Couldn't even get any performance info out of it. Happens on a JVM on
Unix; no problem.

For ref the concurrent collections should not be trusted under heavy load in
processes with more threads than CPUs. Its to be honest piss poor quality.

