The future of .NET(haacked.com)

54 pointsby cek14 anni fa79 comments

http://haacked.com/archive/2012/10/21/monkeyspace-dotnet-oss.aspx

11 comments

There seems to be some discussion about Mono's performance, and I wanted to address that.

The default configuration for Mono is a blend of fast startup, and decent code speed. You can tune these parameters depending on your use profile which can range all the way from: startup is the most important factor to high performing code at any cost.

In general the language Shootout compares the default configuration of Mono vs all kinds of other configurations.

Those interested in Mono for High Performance Computing will be interested in some options:

* LLVM: passing the --llvm flag to Mono instructs Mono to pass the code to the LLVM optimizing compiler, and will run your program through every heavy weight optimization that LLVM supports. This comes at the price of slow startup times (much slower), but for HPC or server loads, the extra time it takes to JIT is worth it.

* Unsafe mode. If you have battle tested your application and you never get an IndexOutOfRange exception, you can instruct Mono to never perform array-bounds checking. Arrays bounds checking basically ensures that every time you do array [i] that the value of "i" is within the range 0..array.Length. This can be expensive, but makes your program safe.

Passing -O=unsafe basically gives you the same semantics of C or C++: you know what you are doing, and you really are not too much into safety.

With LLVM + unsafe access, as far as the LLVM optimizer is concerned, there is really no difference between C# and C++ code, and you will get the same performance for compute intensive tasks. The only case where the dynamic of performance would come into play is when the garbage collector kicks-in, vs manual memory management. That in general depends a lot on the kind of app you are building. Many HPC applications preallocate all of their memory before large computations anyways, so in those apps the GC makes no difference.

The third optimization is to use Mono's new garbage collector, which gives in general a nice 2x performance boost to memory intensive applications. In general, the new GC is great for memory intensive applications, while the old one is better for pure computational applications that are not memory allocation bound.

With Mono 3.0, we also have implemented the inlining attribute (new in NET 4.5), which developers can use to force a function to be inlined, something that before was entirely based on JIT heuristics.

And of course, you can tune the individual Mono or LLVM optimization options.

igouy14 anni fa

lucajona14 anni fa

“But even if Microsoft started to deemphasize .NET, I believe .NET would endure because the community will continue to fill in the gaps so that the ecosystem abides.”

Is .NET really that great a platform that these OSS devs will continue to support and improve it after it's been abandoned by Microsoft?

Not saying that's going to happen—but as a .NET dev myself, I'm curious. If it did go that way, I think my only motivation to continue using .NET would be that I don't want to rewrite years worth of code.

ido14 anni fa

C# the language itself is quite nice, probably one of the best mainstream languages out there. I don't really care tho if it would run on the JVM or native (or something else) instead of the CLR.

Right now tho probably the only popular use of non-ms .net (mono) is Unity (which is btw a pretty big deal in the games industry).

fijal14 anni fa

I find it somehow sarcastic that as you say "the only popular use of mono" is a platform that does not support linux.

gebe14 anni fa

It's in the pipeline though for Unity 4 which will be out soon (I think there is already a preview available).

ryankask14 anni fa

They are adding Linux publishing but according to this post (http://blogs.unity3d.com/2012/07/03/linux-publishing-preview...), the editor won't be available for Linux.

Still though, this means that Mono is being used with Unity on Linux. Unfortunately not the development part.

fijal14 anni fa

thanks that's actually cool news. Last time I checked (half a year ago or more) I couldn't find a single hint about that.

CodeCube14 anni fa

This is the real story here. C#, as a language is fantastic, especially with the most recent versions which have added things like the Task Parallel Library, dynamic keyword, and the new async/await stuff. It's very easy to write a great performing app with C#.

tonyedgecombe14 anni fa

If Microsoft were to abandon .Net then I'm pretty sure the motives for maintaining Mono would slip as well.

However I think that is extremely unlikely, no doubt it will be evolved in that annoying Microsoft way but completely abandoning it would make no sense at all.

quonn14 anni fa

They won't abandon it. Most of their server software is written in .NET: ASP.NET, Exchange server, etc. Most of their administration tools have been rewritten and now all use Powershell (which also has become the primary interface for server management by admins) under the hood.

drhowarddrfine14 anni fa

frozenport14 anni fa

When I evaluated .Net for my database client I saw a nonportable Java. When I was working on a structural mechanics code I had performance considerations that were not met. The former niche of .Net was that it could painlessness interface with Microsoft technologies, without MS's love, support and their technology why would anybody use .Net?

lmm14 anni fa

C# gives you a better Java. Not all improvements have to be revolutionary; downthread you mention Scala but I think its implicits are too powerful for it to be a safe language. (Generally I find the only appropriate use for implicits is extension methods, which C# supports directly and more naturally).

The big promise of .net, though, is better cross-language integration. Scala is in some sense compatible with Java, but a lot of the library is different (e.g. collections); in practice interop is full of awkward edge cases. F#/C# should behave better, though I haven't used them enough to say how true this is in practice.

quonn14 anni fa

First, it's very portable. Second, performance is as good or better than pretty much anything else that is not optimized C or C++. Finally, there are many reasons to love C# beyond interfacing with MS technology. It's a very beautiful language, much nicer than Java used to be and in many respects better than even the latest Java language. And innovation continues: If you've worked with node.js for some time, you will see how ugly code becomes where everything is done using callbacks. C# just now introduced new syntax where you can basically write code in a linear way and the nesting of callbacks is done by the compiler.

codewright14 anni fa

>it's very portable

Mono, I'm guessing you mean. Mono's not great for server applications, it's best used for desktop apps. If you want to write server apps, you need to be using the official Microsoft implementation. (Which is becoming the red-headed stepchild platform in Microsoft's strategy apparently?)

> Second, performance is as good or better than pretty much anything else that is not optimized C or C++

Lets find out:

http://shootout.alioth.debian.org/u64q/which-programs-are-fa...

List of things that are faster than C#:

Fortran, Ada C, C++, ATS, Java, Scala, Common Lisp (SBCL), and Go.

List of things that aren't faster than C#, but are close enough to call it a wash:

Haskell, Ocaml, Clojure, Pascal, Racket

I'd say you have some choices if performance is an issue yet C#'s is acceptable.

>It's a very beautiful language, much nicer than Java used to be

No, yes. It's nicer than Java, it's not "very beautiful". Try working through the Little Schemer to see a beautiful language.

>And innovation continues: If you've worked with node.js for some time, you will see how ugly code becomes where everything is done using callbacks.

Bizarre strawman? What? I don't like Node.js either, but what's your point? A lot of languages that aren't C# have better concurrency idioms than Node. You know, like all of them that aren't C#.

> C# just now introduced new syntax where you can basically write code in a linear way and the nesting of callbacks is done by the compiler.

Yeah, uh, Scala has had this since forever. And Lisp. And Scheme. And Clojure. And C++. And Node.js (ugh).

For a C++ example, look at Tame/Tamer, SFSLite, etc.

For anything else, google "promises".

There is nil that is special about C#, it's a slightly nicer Java without a home or a stable implementation. If neither of those things matter to you and you wanted a Java++ that wasn't as ambitious or intellectually challenging as Scala, then you've found your language. Godspeed.

skrebbel14 anni fa

Your post is full of FUD, taste mixed with fact, and little incorrectnesses. Most notably, your post seems to imply that for C# to be worth something, it has to be the best at something. Yet, Scheme is a prettier language (taste, not fact), a whole bunch of languages already had continuations, a whole bunch of other languages are faster, and so on. C# is great because it's above-average good at all of these areas.

C# has one of the best standard libraries out there (well documented, rather well designed, batteries-included, etc)

C# has a decent set of relatively modern language constructs, yet is easy enough to learn for a very large group of programmers.

C# is faster than most (but not all) languages sporting a comparable set of high-level features.

C# has excellent tool support, and was designed for enabling such tool support, making refactoring and code navigating easier than in any other language except Java.

C# has a large ecosystem and user-base, making it easy to find answers to problems and components that solve problems not covered by its standard library.

None of these items, in isolation, are special. Java arguably has a stronger ecosystem, but is a less powerful language. C++ is faster, Scheme is more elegant (according to many), and so on. But I know of no other language that has all these areas covered so well simultaneously. Scala comes close, but is arguably more difficult to learn, and lacks on the ecosystem area (not in terms of library support, but in terms of best practices and large user base). This might change, which would be lovely.

All other languages you mentioned strongly lack on at least one of the above-mentioned aspects.

I'm not saying that C# is god's gift to mankind and the only good thing out there. I'm only saying that you're dismissing it too easily.

There are sufficient people out there who really like this combination of features to support a vibrant open source community. Which is why this community exists. Why dismiss something that exists and works well?

pdubs14 anni fa

I know you mention tool support I think it's worth mentioning that if you're using the MS stack Visual Studio is really, really good.

skrebbel14 anni fa

It is, unless you come from Java (using IDEs like NetBeans or Eclipse), in which case it's kind of comparable (but different). IMHO.

In fact, if MS were ever to make .NET/C# legacy like some people seem to believe "WinRT allows horribly HTML5 apps" implies, I bet JetBrains would just bolt ReSharper onto IDEA and off we all go.

NateDad14 anni fa

if you've ever actually used Visual Studio 2010 or above, and compared it to Eclipse, you'd realize how sad Eclipse looks in comparison. I use both at work all the time. Nothing compares to VS.

skrebbel14 anni fa

I use both at work all the time, too. I tend to prefer VS, too, but there's some points where Eclipse really shines. Eclipse's continuous build, for example, is excellent. Your tests start immediately when so requested, where VS 2010 decides to first build all of the projects in the solution. Especially once the solution gets fairly sizeable, this becomes unproductive very fast. There's workarounds, but I don't want workarounds. I just want it to work immediately.

ygra14 anni fa

NCrunch [1] is a great help in that regard – auto-build and auto-test in the background while you work. I just wish I had codebases that were well-tested so that I could actually use it.

[1] http://www.ncrunch.net/

codewright14 anni fa

That non-Windows machines are a comparable ghetto for C# programmers really only reinforces my point.

eitland14 anni fa

Why does resharper exist then?

throwAway793614 anni fa

Mono certainly works on the server.

Your comment just tries to derail the discussion by bringing up Scheme or Lisp in a context where only languages are considered that are widely used in the industry. Otherwise, how could the word "abandon" possibly apply?

This language shootout has been criticized before. Except for optimized C and C++ there is no popular language (I'm talking about the performance that is due to the design of the language, _not_ a particular implementation. For example dynamic typing is necessarily slower.) that is faster than C#. Try unsafe C# and you know what I mean.

Bringing up Scheme here is entirely inappropriate. It's common wisdom that Lisp and Scheme are more beautiful, but this article is about a language that is supposedly "abandoned", because it may not be mainstream enough anymore at some point. If C# is abandoned, then what can you say about Scheme?

As far as node.js is concerned, it's not a strawman: In fact, the people who claim that MS abandoned C# think that they want to replace it by Javascript. MS even supports node.js in Azure.

"concurrency" is not the same as asynchronicity, which is what I was talking about. And promises are not even close what C# 5.0 tries to achieve. In fact, promises have been present since .NET 4.0.

Finally, please explain how Scala is "intellectually challenging". This is not my experience.

(throwaway account due to procrastination setting)

snogglethorpe14 anni fa

> Except for optimized C and C++ there is no popular language (I'm talking about the performance that is due to the design of the language, _not_ a particular implementation. For example dynamic typing is necessarily slower.) that is faster than C#.

Er, but you can't just completely disregard implementation, because it really matters in practice. You're not going to get a lot of adoption simply because your language is theoretically better/faster/...

In these language shootouts, Lua, a dynamically-typed language aimed at small size and simplicity, regularly beats out C#, because Lua has LuaJIT[+], which is a really good implementation, whereas C# for many people means Mono, which is at best an "OK" implementation.

It's the same as with algorithms: big-O complexity is obviously important, but it isn't everything; for real-world uses, the constant factors may make all the difference...

[+] The standard Lua implementation is also very good, but it's a more typical VM, and while very fast for a non-JIT VM, can't match LuaJIT in many cases.

igouy14 anni fa

>> This language shootout has been criticized before. <<

Criticism can be uninformed, out-of-date, self-serving, mistaken... ;-)

jules14 anni fa

In addition to skrebbel's excellent points, C# on the CLR is faster than Mono, and C# supports value types so in real world code that often gives it an advantage over Java. For example a List<int> in C# is a tightly packed array of integers, in Java it's a list of pointers to integers. In Java, you can in theory rewrite each collection class (hash map, hash set, tree map, tree set, list, etc.) for all primitive types (and pairs, and triples, etc. of primitive types), or write everything directly on top of primitive arrays (as is done on the shootout). In the real world for most code that's not practical and leads to unreadable/unmaintainable code.

igouy14 anni fa

>> or write everything directly on top of primitive arrays (as is done on the shootout) <<

Please tell us specifically which Java programs in the benchmarks game, you say, are written directly on top of primitive arrays.

jules14 anni fa

Basically all the programs that use collections at all? Of the first 7 programs that I checked, 6 use primitive arrays, and N-body uses an array but that array contains a pointer type. Fannkuch-redux, meteor contest, fasta, spectral-norm, reverse complement, mandelbrot ... all use primitive arrays. A better question would be: which programs do NOT use primitive arrays? I'm not saying that these should be written using ArrayList or something, just that they are not very indicative of real world performance when people are more likely to use the collection classes.

igouy14 anni fa

You seem to have noticed the arrays of primitives, and not noticed the other collections:

fannkuch-redux is all about "Indexed-access to tiny integer-sequence" so it really is all int[]

meteor-contest int[] byte[] OkPieces[] SPiece[] Piece[]

fasta byte[] double[] frequency[]

spectral-norm double[] Approximate[]

reverse-complement byte[] int[] ArrayList<byte[]> LinkedList<Integer>

mandelbrot byte[][] double[] Thread[]

and then the ones you didn't mention:

binary-trees custom binary trees

chameneos-redux ArrayBlockingQueue<Creature> Creature[] Thread[]

knucleotide byte[] int[] LinkedBlockingQueue<AbstractCounter> ArrayList<LinkedBlockingQueue<WorkChunk>> AbstractCounter[] ArrayList<CountString> StringBuilder TreeMap<Integer, Map<Byte, AbstractCounter>> HashSet<AbstractCounter> ByteBuffer ArrayBlockingQueue<Runnable>

pidigits long[] Semaphore[] exec[]

regexdna Thread[] StringBuffer HashMap<String, String>

thread-ring custom ring (also Node[] LinkedList<Node>)

igouy14 anni fa

>> not very indicative of real world performance when people are more likely to use the collection classes <<

That doesn't seem much more than a big fat assumption - aren't there also going to be many situations when the right thing to do is use an array?

jules14 anni fa

That people use standard collection classes more often than in these benchmarks where they little used (if at all) is a big fat assumption?! There are going to be many situations where using a primitive array is not the right choice. When you need a hash table, a set or an expandable array, for example. If you are claiming that these benchmarks are indicative of the real world, you are claiming that collection classes are not used in the real world, since hardly any (if any) use the built in collections.

igouy14 anni fa

>> If you are claiming that... <<

What I'm doing is responding to your claim -- write everything directly on top of primitive arrays (as is done on the shootout).

>> When you need a hash table <<

Task description from the home page -- "Repeatedly update hashtables and k-nucleotide strings"

thomasz14 anni fa

> aren't there also going to be many situations when the right thing to do is use an array?

Sure, with a language that has super slow boxing semantics....

Just look at BinaryTree. The benchmark would show a very different picture if it would compare Tree<Integer> implementations instead of allowing a primitive int.

migueldeicaza14 anni fa

It does not seem like you understood the original poster, hence your set of incorrect statements that ends with "And C++. And Node.js".

Let me help you.

He is talking about C# async, you can read more about it here:

http://msdn.microsoft.com/en-us/library/hh156513.aspx

codewright14 anni fa

Let me help you.

https://github.com/okws/sfslite

http://www.read.cs.ucla.edu/tamer/

http://stackoverflow.com/questions/5579602/what-is-the-scala... You will note that it's a comparison between F# and Scala.

http://dispatch.databinder.net/Dispatch.html The standard HTTP client of choice is async, although the simple API wouldn't necessarily tell you as much.

https://github.com/ztellman/lamina From the clojure people. Agents bear mentioning too.

migueldeicaza14 anni fa

It looks like Tame is a pre-processo that outputs C++, hardly a C++ language feature. I mean, more power to you if you like to use those, but that is hardly C++.

The Scala question seems to have too many caveats, you should read the comments as there is no full translation of the F# async translation in the stackoverflow question. The answer with the most question states "with some important features lost". The comments on the question and answers should be read as well.

Cute Http Stack though.

The lamina code runs the code on a separate thread (https://github.com/ztellman/lamina/wiki/Introduction) hardly what C#'s async does. Not that I care that much, but that is what the docs say.

You forgot to show us how Node.js is supposed to support async-like programming without callbacks. I suspect in a rush to enumerate a bunch of languages, you merely listed everything you could think of and hoped some of it would stick?

prospero14 anni fa

With respect to Lamina, that's just an example of a task on a separate thread being treated as an asynchronous result. It's entirely possible to use it to represent network communication or pretty much anything else.

codewright14 anni fa

Nice no true scotsman.

https://gist.github.com/3889970

igouy14 anni fa

Shouldn't you extend that "close enough to call it a wash" on the "faster" side as-well-as on the "slower" side?

So add "ATS, Java, Scala, Lisp, Go" to "a wash" and we're left with "Fortran, Ada, C, C++" as "faster".

migueldeicaza14 anni fa

Language Shootout does not use Mono configured for HPC (--llvm, -O=unsafe).

It will also likely do poorly, because LLVM is slow to startup, but the resulting code is nothing short of God's own fine tuned code.

Alternatively, you can pre-compile the code with AOT:

mono --aot --llvm -O=unsafe sample.exe

But AOT code requires the sacrifice of a register to the gods of position independent code. Kind of the same perf hit you get from gcc -fPIC foo.c

igouy14 anni fa

Here's the command line for the spectral-norm C# programs shown on the benchmarks game website:

/usr/local/src/mono-2.11.4/bin/mono --gc=sgen --llvm spectralnorm.csharp-2.csharp_run 5500

As you can see --llvm is used.

(Since June 27, 2012)

migueldeicaza14 anni fa

Lovely!

This sample shows the startup cost of LLVM. It is not ideal for short-running tasks, as just JITing this code with LLVM increases the overhead for this test by 0.42 seconds on my machine (iMac, 2010).

Might be worth running this for a longer period of time, they will basically converge.

LLVM is great for HPC, when this startup cost is not a problem.

igouy14 anni fa

Sadly not lovely, because when I installed Mono 2.11.4 a couple of weeks ago, I forgot about "Compiling with stock LLVM is not supported, please use the Mono LLVM repo..."; and I guess when --llvm is used without LLVM being enabled, Mono does not give a warning message.

The Mono 3.0.0 measurements are made with LLVM enabled.

devb0x14 anni fa

Scala easily can become unreadable.

c# is easy to learn, easy to implement, and easy to handover, to a team, a junior etc.

It is easy to wrap up dev of an application in .net. Super easy. I've done some awesome things in c#, and love the language. Why, cause when it is easy to ship working software, what's better than that.

malkia14 anni fa

To be fair the shootout uses open source language implementations and runtimes. It could be that .NET is more performant than Mono (which is used in the tests), so that's not very objective view of what is possible with a C# implementation.

igouy14 anni fa

http://shootout.alioth.debian.org/demo/compare.php?lang=csc

It is a "very objective view of what is possible" now on Ubuntu.

migueldeicaza14 anni fa

Raphael_Amiard14 anni fa

> Second, performance is as good or better than pretty much anything else that is not optimized C or C++

You are kind of overlooking the JVM here.

Also Mono is kind of portable, and .Net on windows is fast, but you can't really have both (even if Mono performance is decent)

migueldeicaza14 anni fa

In Mono we cheat.

We cheat, because we are able to use the work of the brilliant hackers over at LLVM.

So in addition to Mono's code gen, you can opt into using LLVM, like this:

mono --llvm myBenchmark.exe

It take a lot longer to start, compared to Mono's fast-JIT, but for any long-running HPC, financial simulation or physics simulation, you can not get better than this.

The speed of LLVM, the safety and productivity of C# (or F#)

qznc14 anni fa

Theoretically, the CLR-VM should be able to reach better performance than the JVM, since it has value-types. Within the JVM an array of some objects is really an array of references, which is bad for your hardware caches and requires an additional pointer dereference. The question is how significant that is for non-numerical applications.

Someone14 anni fa

Theoretically, your sufficiently advanced compiler and/or JVM will figure out where they can replace objects by value types. So, theoretically, that does not matter.

The difference should be visible in practice, though. AFAIK, it is not really visible, though. That probably is because the JVM has been tuned longer.

migueldeicaza14 anni fa

In practice, value types are a huge performance differentiator.

That is why even the simplest benchmarks involving value types tend to beat Java's optimized code gen.

azth14 anni fa

Isn't Scala 2.10 introducing value types that are beneficial for situations like this? I don't know about any potential limitations though.

codewright14 anni fa

>You are kind of overlooking the JVM here

I did criticize OP too, but you'll note that he made a point of saying that C# was nicer than Java. The fact that he isn't aware the JVM has more than just Java, is an issue I attempted to redress.

throwAway793614 anni fa

How can you claim that I'm not aware that the JVM is more than Java? I did not even mention the JVM.

mattchew14 anni fa

LINQ is very good. I would use it in a box, I would use it with a fox.

rocky113814 anni fa

Building a web app in ASP.NET is pretty rapid, with things like built-in login forms and account support.

If you need to get a prototype up and running quickly, you can do that with a minimum of fuss. Plus, C# is actually a pretty solid language.

Someone14 anni fa

"There’s also this perception that with Windows 8, the Windows team is trying its best to relegate .NET into the dustbin of legacy platforms"

I haven't heard that anywhere. They are tightening the APIs for security and there is the usual rebranding (Silverlight apparently is out) together with the addition of 'our new things are brilliant, unlike the things that we, lasy year, called our new brilliant things', but AFAIK, Microsoft bet and is still betting heavily on .NET.

Anybody know what this statement is based on?

cek14 anni fa

The Windows team made a huge investment in HTML & Javascript. You could even say they bet on developers using that over XAML/C#.

Looking at the apps in the Store though, and talking to insiders, and the picture is clear that over 80% of the apps in the Windows 8 Store now are XAML/C#. I've been tracking this for the last few months, and the trend is continuing.

CodeCube14 anni fa

I know I am but one data point, but I feel that was a poor investment choice for the windows team. They should have doubled down on XAML/C#, along with unmanaged code to bring in toolkits like unity and other developers that prefer working in C++.

cliffbean14 anni fa

People are looking at shifts and trying to find trends. It used to be that the trend was towards ever-growing prominence of .NET. With recent shifts, .NET is still present, but other technologies are now filling roles that .NET had been expected to fill, under the previous trend. This suggests a new trend.

edandersen14 anni fa

Xamarin appear to be pushing big time the cross platform abilities of C# now. It is possible to have your business logic shared between Windows desktop, WinRT, iOS, Android, web apps etc, with a thin native UI layer on top.

shadowmint14 anni fa

You need to add IF you're using visual studio to that sentence.

This is currently not possible using mono develop; the portable library support doesn't exist, which means your 'shared' libraries can't do things like use sqlite or linq; in fact, they can't have references to anything other than other portable libraries at all. Like, for example, system.collections.generic.

CodeCube14 anni fa

What!? this is entirely incorrect ... with MonoDevelop you can use the entire framework (linq, async/await, sqlite, entity framework, etc.).

It's possible to build applications without using visual studio at all (minus winrt apps, you need VS for that).

jmcqk614 anni fa

I thought it was possible to do all of this without using visual studio - or any other IDE - with the possible exception of the WinRT app submission process.

I know you're wrong about sqlite and linq as I've used them on both .net and mono. I think you're using the phrase "portable library" incorrectly. In the .net world, these are libraries created by microsoft that use the more limited version of the framework on their other platforms. For example, windows phone 7 and win rt use different portable libraries (a pain to manage, admittedly).

shadowmint14 anni fa

I'm referring specifically to portable class libraries (PCL) (http://stackoverflow.com/questions/5238955/what-is-a-portabl...) that allow you to write code that is 'cross platform'.

(ie. PCL --> One code base that compiles and runs on multiple c# runtimes; a key feature of writing cross platform c# applications)

Support is currently limited, see: http://docs.xamarin.com/ios/tutorials/Cross_Platform/Buildin...

Of course you can copy and paste your code into different projects manually, and compile it for a specific runtime. Or... you can use visual studio.

migueldeicaza14 anni fa

It is easy to be confused, because PCL is confusing.

My personal preference is to just link source files and use partial classes (very much like the Linux kernel uses "pluggable" files to create a kernel) to create a product.

The problem is that there is no "Portable Class Library", there are dozens of profiles, and you need to pick the subset you want, for example: "Desktop and Windows8" is a much larger profile than "XBox and Silverlight", the subsets are different.

If you ignore Xbox and Silverlight, you pretty much have the whole stack everywhere.

migueldeicaza14 anni fa

You seem confused.

Because I use LINQ and Sqlite on my shared code between Android and iOS. And you can even use Sqlite on Windows Phone (using Sqlite-cs) and Win8.

Meai14 anni fa

What it would take for me to consider .NET/C# more often, is easier interop with C. I really like the way Golang does it, I know P/Invoke isn't terribly hard, but it's still messy and you have to muck around with attributes and annotations. In Golang I did some interop by simply pasting lines and names of header files around. That's a lot more convenient than having to decide how to layout a struct, at least that was my impression when I looked into it. Mono documentation is very sparse as well, they basically tell you to just look for the msdn docs, which splits your efforts up and makes you uneasy whether you'll run into Mono specific things. (which there are)

jstclair14 anni fa

You raise a good point: is there something like http://pinvoke.net/ for non-windows interop? I know that mono is wrapping things themselves, but on open wiki might help.

sparkie14 anni fa

Many open source libraries already have .Net bindings available, a quick search can discover them. They're also packaged into assemblies or made into higher level APIs, which sure beats copy-pasting from a webpage.

There's the [P/Invoke interop assistant](http://clrinterop.codeplex.com/) which can help you create a wrapper for C APIs, and the mono team have created [Cxxi](https://github.com/mono/cxxi), a binding generator for C++ APIs.

lucajona14 anni fa

If Go already does C interop easily, what other factors make you want to consider using .NET instead?

migueldeicaza14 anni fa

Generics, iterators, functional-style programming, LINQ, asynchronous programming, dynamic, Reflection.Emit are the things that I would miss.

Meai14 anni fa

Existing API support, frameworks, libraries and IDE support.

rocky113814 anni fa

This is one of the areas that open-source shines: when a core technology that has a passionate following is no longer supported, that passionate following can take on the project themselves and continue.

jiupai14 anni fa

.Net not equals C#. C# is great, but .Net sucks. limited ecosystem, no one want to implement good open soure project on .net stack. no similar level project like JBoss.

migueldeicaza14 anni fa

I would say that not having J2EE and JBoss is a plus for .NET or any other platform :-)

There is a whole new set of framrworks for building web applications. My favorite frameworks include:

* ServiceStack: everything you need to build sophisticated web apps with a clean, beautiful API.

* WebAPI: if you want to get a more "Enterprisey" set of APIs

* ASP.NET MVC: .NET's approach to Ruby-on-Rails-esque development.

* SignalR: real-time web applications.

awaretek14 anni fa

Anyone who bought into Microsoft's Proprietary .Net platform deserves what's happening to them now. Anyone who buys into Microsoft's Windows 8, Windows RT, Windows Phone 8 ninsense is just plain braindead.

But some people never learn :-)

CodeCube14 anni fa

I'm not sure how you got this from that post, if anything the future has never looked brighter for .NET/C# developers. The ability to target all mainstream platforms, a burgeoning open source community, and fantastic tools. Of course, other technologies have had these in one way or another ... but that doesn't invalidate the C# communities advancements.

The fact is that as a C# developer currently focusing on mobile development, I am very happy these days.

[deleted]14 anni fa

f1f2f314 anni fa

Windows 8 is being released soon. Got it.