Comment by aroman
11 years ago
Am I the only one bothered that they didn't include the space between the "OS" and the "X"?
More importantly, this is huge, but as a Linux developer/user I still have no desire to use .NET on my platform. Maybe Mono has scarred my permanently.
Also linux developer/user and I'd crawl over broken glass to have a reliable C# runtime on Linux, it's my absolute favorite language.
Just out of curiosity why? I personally can't imagine why someone would choose it as a favorite. Not because I think it is bad, but because I feel its kind of a kitchen sink language that doesn't really have any clear advantages or features.
In short: because it doesn't make me think about it, freeing me up to think about the problem, and gets out of my way. You're right in that it's a kitchen-sink language, but IMO it's a well-curated one, and I don't find myself having to think about patterns or other crap as I do when using Java (which I've used professionally) or wrestling with poor tooling and spooky-action-at-a-distance language design in Scala (ditto--and I like Scala, but for a lot of things it just won't get out of my way).
Reasonable people can disagree, of course.
I'm really looking forward to F# being really easily used cross-platform. I'm happy for C#, but I'll swoon for F#.
No need to wait - xplat F# is available right now via MonoDevelop/Xamarin Studio. You can use it to develop iOS/Android/Desktop/Web applications.
I have been using C# on Mono for a back-end and so far so good.
For code I am editing on MonoDevelop or on VS and then compiled and ran on Linux.
Nothing wrong with Microsoft bringing OSX and Linux to parity with Windows. In fact, there's a lot right with it. I like this new Microsoft, and I've been using Linux for years. Keep up the good work Redmond!
Excited to see that interesting tech like C#, F#, CLR, LINQ and friends is heading our way. If anything it'll give Java a run for its money and that's no bad thing.
I don't think anything is giving the JVM a run for its money. There are millions of man hours that have gone into performance tuning the JVM. The CLR has substantially less. Possibly for mid-size projects the CLR _could_ be an alternative but for the foreseeable future any administrator who is comfortable with Linux is likely also comfortable with the JVM tools necessary to troubleshoot and improve JVM performance.