There was no discussion of async/await in here which is one of the best things C# has going for it.
When I meet other devs and tell them I work in lots of languages and platforms but prefer c# they usually look at me like I have 3 heads.
I like to show them LINQ and Async as some things I really like about C#, then I get into how rich the BCL itself is.
Devs are also pretty shocked when I tell them I can write truly 100% native iOS and Android apps in C# (thank you Xamarin) and that one of the most popular mobile game engines (Unity) uses C# and a version of the .NET Framework under the hood.
It's funny when you tell hipsters about .NET. They get really shocked at just how good it is. A lot of people dismiss .NET because it's backed by Microsoft. It really sucks that these people can't just look at the technology for what it is rather than dismiss it based upon who created it.
As an aside... whilst C# takes a lot of the public .NET praise, F# is the real hero in the making. When I show F# to some hipsters they get very unsettled very quickly as suddenly they realise all that shitty Ruby and JavaScript they've been writing for years is probably not going to be anywhere near as employable in another 10 years, maybe, hopefully.
Interesting times indeed. And yes, Xamarin is awesome and Microsoft seriously needs to bring that great firm under their wing. Writing your mobile apps per platform is a major violation of DRY principles and is utterly ridiculous.
> A lot of people dismiss .NET because it's backed by Microsoft. It really sucks that these people can't just look at the technology for what it is rather than dismiss it based upon who created it.
Since .NET isn't open-source, it doesn't come with the same guarantees as something like Java, C++, OCaml, Haskell, etc... Microsoft could discontinue it, make the terms of use more restrictive, etc...
Further, .NET applications only run (officially) on MS platforms, Mono isn't the same, and due to legalities many people are hesitant to base their business on Mono.
As far as hipsters and Javascript or Ruby, MS has fully embraced Javascript. It's a first class language on VS, Windows 8 'modern' interface, etc... Ruby is great within its domain, and even has a .NET implementation (though I don't know how well supported IronRuby is anymore).
And funny you praise F#, because it's just a MS implementation of OCaml, with a few small differences. Speaking of which, OCaml is pretty awesome, it compiles down to pretty much anything, and is fast as hell...
F# isn't "just a[n] MS implementation of OCaml, with a few small differences". F# did start out as an OCaml port for .NET, but the language has grown organically from there, especially since the first public, supported release (v2.0, in VS2010).
The foremost difference is the ability to easily and closely interoperate with existing .NET code; this sounds very simple, but it's very tricky to get it right, and in fact this is widely considered to be a major strength of F#.
F# also has computation expressions (like monads in Haskell), sequence/list/array comprehensions, type providers (for strongly-typed data access), and built-in async support. Not to mention, since F# runs on the CLR, it has a well-tuned, high-quality, multicore garbage collector at it's disposal.
I know some of the folks from OCaml Labs, and I have nothing against OCaml. I just want to dispel the notion that there are no differences between OCaml and F#.
".NET applications only run (officially)" -- what's that even mean? I can rephrase it: "Mono applications only run (unofficially) on Microsoft's CLR".
The actual runtime is an ECMA spec (which has been unchanged since v2, as all MS has added since are implementation changes and more libraries). C# and the core parts of the runtime are under Microsoft's Community promise[1]. But you're right that MS could try to assert copyright over parts of the extended APIs, and some companies might be worried about that. OTOH the Oracle versus Google thing should alleviate a lot of concerns.
As far as F#, it's quite a bit more than a few small changes.
> ".NET applications only run (officially)" -- what's that even mean?
If MS feels threatened by Mono, it changes its runtime and kills interoperability. From that point on, Mono is playing catch-up and who knows what happens to the users caught in the middle.
That's one of the least-plausible Microsoft trickery ideas I've heard of. Anything that makes Mono play catch-up also hurts every existing .NET program.
Even if they had some magical changes that kills interop (like, what, I don't know), Mono still works with all current apps at that point, and only developers adopting the new, not-compatible system (and thus discarding all their old libraries) would be affected.
Microsoft sorta has done this, with Silverlight and WinRT. They required different stdlibs and a bit of runtime tweaking, as I understand. Silverlight was handled by Mono, and WinRT - not sure if anyone is interested, as it's really for Windows Metro applications.
What kind of change could Microsoft make to their runtime to "kill interoperability" with Mono without affecting backwards compatibility for everyone else using .NET?
There are enough people (especially enterprises, their most important customers) using .NET now that Microsoft has to be very careful about any changes they do make to avoid breaking existing applications and upsetting their paying customers.
There's a lot more to F# than its OCaml origins. It's obviously heavily based on OCaml, but the directions have diverged.
One of the most powerful features I've found is part of the LINQ framework - the expression tree output. You can specify parts of code to be 'half-compiled', it leaves an AST fragment in the output in addition to the regular code.
This means you can do runtime transformations, for example to JavaScript or HTML.
The pattern matching extensions also make these transformations easier than you'd expect.
Don't knock the practical value of seamless interop with the .NET ecosystem.
A few years ago I tried to introduce OCaml to a company I was working at, an Oracle shop, and immediately hit a snag - the Oracle bindings hadn't been maintained in years and wouldn't compile with the current GCC or OCCI. ISTR there were also 32/64 bit issues. Anyway, I actually went ahead and wrote my own, styled to look a bit more like the classic OraTcl to make adoption easier. I say this not to blow my own trumpet but to illustrate that there is more to a language then the language. And not to knock the OCaml guys, just that their research priorities are different than my corporate data processing priorities.
Anyway, the OCaml world is playing much more nicely with others now, the book Real World OCaml is almost out, OCamlPro are doing some good work. But in F#, you can "hit the ground running".
> Microsoft could discontinue it, make the terms of use more restrictive, etc...
> .NET applications only run (officially) on MS platforms,
Not only that - non-Microsoft platforms have a huge choice of languages, platforms, runtimes and other tools Windows can't match. With all that going on, it would be surprising if someone decided for .NET to run on non-Windows boxes.
The only reason to target .NET is to build Windows-compatible software. It's an important requirement, sure, but there is a lot more happening these days on spaces Windows simply can't reach.
Also, Microsoft have patents not just on .NET itself, but also on fairly broad ways of using particular .NET functionality. Needless to say, patent infringement by your code isn't covered by any of their patent promises or licenses. I'm pretty sure at least Gtk# infringes on at least one such patent I found some time ago; since essentially every graphical C# application uses either that or WinForms which is also covered by multiple patents, running any C# GUI app anywhere other than Windows is legally risky.
Microsoft, Oracle, HP, IBM, and others also hold a variety of patents related to garbage collection algorithms. The legal risk isn't limited to C# on non-Windows platforms; I'd guess that any garbage-collected language is potentially open to litigation: C#, Java, Python, Ruby, Haskell, OCaml, etc.
> And yes, Xamarin is awesome and Microsoft seriously needs to bring that great firm under their wing.
I'm a Microsoft fanboy, but a thousand times no. So they can do what with it exactly, pull another Skype? Xamarin caters to areas MS rarely do and bringing them in would push people out of the windows ecosystem, not inward. MS's catering to ios and android is to push people to windows phones and that isn't likely to change anytime soon.
I'm definitely glad Xamarin exists, especially after Novell kicked them to the curb. They could've kept their ball too but they decided to play fair and let Mono live on. I would never in a million years think MS could be that generous, and again I love MS for better or worse. Could they be? Sure but in spite of Bill Gates charitable contributions to humanity, those notions rarely took root in the company that enabled him to become that person in the first place.
I really wish F# was as approachable as Scala is. Every time I consider it I see no strong selling point. Loosing ReSharper + a steep learning curve make it too much for me.
If you know C# and you want to learn F#, consider reading Real-World Functional Programming: With Examples in C# and F# (http://www.amazon.com/Real-World-Functional-Programming-With...). It's been well-received by C# developers, IMO because it does a great job of explaining the purpose of certain F# features, and how they can be used to simplify some common C# coding patterns.
As an active contributor to the F# open-source community, I can tell you that there is a lot of effort -- both from Microsoft and the wider community of developers -- to build out the F# ecosystem of tools and libraries. For example, Deedle (https://github.com/BlueMountainCapital/Deedle), a data frame library for F# and C# was released a few days ago; this gives you the kind of data-manipulation functionality as you'd get with Pandas or R. JetBrains even started an open-source project to bring F# support to ReSharper: https://github.com/jetbrains/fsharper
I hate to be a negative guy. I have actually read some chapters of that book - thanks for links, I do appreciate. Maybe the problem is that my job is DB + GUI + simple business logic type of projects. Which is probably similar to most other jobs these days. I would love to work for Blue Mountain Capital but I don't. I am the only one in the team who thinks F# could be useful and had to defend using Maybe monad in C#! The only strong use case I have found so far for F# is building DSLs. Even then I would personally prefer an external DSL built with ANTLR or other proper language work-bench.
PS: that F# ReSharper project is actually dead, last update was months ago. I don't understand why Microsoft won't pay JetBrains to add support. I don't understand why Microsoft won't make a Roslyn for F#. No, instead poor F# team guys have to talk to community to build some basic OOS IDE.
On the contrary: Even for these boring apps, using F# means you'll have a lot less code. C# only really wins if you're using the GUI designers.
I converted a C# application to F# manually, preserving the C# style. I needed 1/20th the number of type annotations. I've done ASP.NET MVC apps using F# and find it far lighter-weight to write controllers.
And the neat thing is that while using F#, even as a lightweight C#, you'll start using better abstractions because they're so easy.
If you can, write some projects in F#. I've found the best way to convert people is just to enjoy how little code's required to get things done, which makes them jealous and they'll switch.
Do you use WPF for your GUI programming? GUI isn't one of F#'s strengths -- it doesn't have all of the fancy codegen tools C# does -- but Dmitry Morozov has built some excellent tools for working with WPF in F#: https://github.com/dmitry-a-morozov/fsharp-wpf-mvc-series/wi...
Database-oriented programming in F# is pretty good from F# 3.0 onwards, thanks to a few minor language improvements and the major addition of Type Providers. F# 3.0 ships with a type provider which interops with the standard classes in System.Data.SqlClient and another which interops with Entity Framework. See: http://msdn.microsoft.com/en-us/library/vstudio/hh361035.asp...
Dmitry (whose WPF framework I mentioned) has also written another type provider which provides strongly-typed access to all kinds of stuff (e.g., stored procedures) if you happen to use SQL Server as your database: https://github.com/dmitry-a-morozov/FSharp.Data.SqlCommandTy...
C# and it's related tools are very solid and have much momentum and marketing muscle behind them, so it's understandable that some developers (e.g., your co-workers) might feel uncomfortable learning something new. I've found the best way to convince people is to start writing little bits and pieces of your work, like small tools or minor libraries, in F#; when it turns out they have few, if any, bugs that usually does a good job of convincing people F# is worth taking another look at.
I actually like how meaningful white-space forces formatting. I want more inference in C#. What I don't like is that language "feels" too "big" for me to approach. Things like "The DefaultValue attribute is required on explicit fields in class types that have a primary constructor" make me think WTF, why use OCaml with "patches" instead of starting from scratch? Don't get me wrong, I will learn F# the day it will be paid properly by the market (London). But today it doesn't give me enough to abandon C#. PS: Microsoft says F# is not meant to replace C# and I don't do scientific calculations or big data.
I'd be surprised if F#, all-in-all, has more complexity than C#. For instance, C# has crazy duck-typing rules, but they only apply when using certain keywords (like new Whatever{} or foreach). Or all of C#'s type-coercion stuff, like C. Floats, integers, even strings - let's implicitly convert them galore!
F# has a fairly coherent model, which makes most of the design principles deducible. For instance, that quote about DefaultValue. You're using a keyword to introduce a field without initialization. Since F# avoids uninitialized fields, so you don't end up with nulls, it forces you to be explicit here, noting that you're requesting the compiler to allow an uninitialized field, which is not something you often want.
Microsoft's marketing is shit as far as F# goes. They've invested a lot in C#, and it's embarrassing for some people to admit that MSR came up with a far superior language. So instead they mumble about how F# is great... if you're like a rocket scientist or quant or like, really super-duper smart. The implication being that C#/VB are the only practical languages for normal get-stuff-done programmers. In truth, the only real advantage C# has is the tooling. There are drag-n-drop designers, and codegen tools that F# doesn't have. Some libraries make implicit assumptions about C# compiler implementation details. But that's hardly a language problem, and something MS could fix if they cared to put resources on it.
As a side note, the F# team has some of the same people responsible for actually designing and getting proper generics into the CLR. Without that team, the CLR wouldn't have proper generics, but probably eventually would have gotten a lame model like Java's.
The biggest problem F# faces(or faced) is it looks very foreign to a journeyman c#/java/c++ developer. Significant whitespace and lack of curly braces does not look quite odd now, with the proliferation of Python, Ruby etc. Prior to 2005 or thereabouts, it was a huge challenge.
Part of it is a community problem as well - the leading lights of the Alt .NET community pretty much cold-shouldered F#. Don Syme & team waged a lonely battle to bring mindshare. Till f# 2.0 shipped, I can't remember more than 2 or 3 significant developers who were actively developing F#. Things are looking up now though.
@profquail: First of all those links are meaningless given the scarcity of F# positions. You just can't compare them statistically. Second of all if you look closely at actual positions then it turns out they are not F#-centric at all, more like "Scala, F#, Erlang, Haskell knowledge is a plus". I mean people who use F# were hired not because they knew F# well but for other skills - e.g. deep knowledge of finance, distributed computing etc. Why not focus on learning that instead? Nobody pays 100k for F# alone. I might be wrong but I just don't see it as a skill that sets you apart that much. People are more interested in HTML5 :(.
With languages like C#, Java, Python, C++, etc., job postings often ask for experience with that specific language. Sometimes you'll see postings which allow developers to jump back and forth between C# and Java, but that's about it.
With functional languages, the specific language is much less important, because the languages share many features, and the real key is that you understand how to design and structure functional programs. Along with the fact that functional languages -- even the popular ones -- have much smaller developer bases than your mainstream imperative languages, many job postings for functional programmers list multiple languages just as you described.
And you're right, no one's going to pay you 100k just for knowing F#. That's true for any language at any salary point though. What companies are looking for are those other skills; F# developers generally command higher salaries because they're often highly skilled senior developers, not because of their language preferences.
Many F# developers work in the financial sector (myself included). Working in the financial sector isn't some magic ticket to a higher salary though, i.e., given an engineer who makes $X in some other industry, they're not automatically going to make 2 * $X just because they switch to finance. The reason salaries are higher in finance is because it's really worth the investment for financial companies to spend extra money to hire the most highly-skilled engineers (and other staff) they can find. Some other industries (e.g., aerospace) have similar requirements, so salaries are higher than normal there as well.
I have an ongoing bet with a few friends on when and who will buy Xamarin. In April my bet was 18 months they would be bought by Microsoft or Amazon. I still lean Amazon.
I hold out hope that the next Microsoft CEO won't be as blind as Ballmer was and that the first thing on his hit list will be to buy Xamarin or at least "secure" it to prevent anyone else buying it; a suitably large investment could do that.
Xamarin would provide the perfect solution to getting a major foothold on mobile app developers, which is what Microsoft so desperately needs for their Windows Phone aspirations. Once you have developer mindshare, you have cracked half the problem.
Microsoft should buy Xamarin, but they'll also need to open-source all of .NET. That would improve Mono on non-Windows platforms. That would be the best thing they can do to really get a foothold in the mobile space and also win back some part of the startup community.
P/Invoke and stuff like that is unopensourcable. The run time is way too deeply embedded in COM and the registry for its own good.
This move could have outright killed java in 2006 when the .NET 2.0 was way ahead of java in everything. Right now - I am not so sure it will be such a big thing.
(Disclaimer - haven't touched serious project in 4-5 years in .NET but I loved C# and the libraries)
Funny, but P/Invoke seems to work great on Linux with Mono... it's probably the single biggest reason I started out with it, as JNI by comparison is an ugly beast.
I love a lot of what C# and .Net have to offer, even though half of my server-side dev time is in node.js for the past couple years, I still like a lot of .Net ... It will be really interesting to see where things go in the next couple of years. I think unchaining VS and Office from Windows would be the best move MS could make right now. Web Matrix (with an extension) is imho second best dev environment for node.js out there, and that they haven't integrated this into VS really surprises me.
MS put a lot of effort into libuv, so not sure why they wouldn't get the runtime system that uses it up to speed better.
The BCL in .Net are second to none in terms of breadth and comprehensiveness. I feel that if MS really opened up most of .Net in MS-PL or something similar, it could really gain ground outside of windows... Again, this would mean getting VS and Office away from the windows anchor.
Unfortunately, the .Net Framework source is available under a 'reference license'.. You are allowed to look at the source, but not modify or redistribute it. Mono specifically has to be very careful about these problems, so if you have ever looked at Microsoft's 'shared source' code you are not eligible to contribute to Mono.
I think that keeping Xamarin out of MS's hands is actually better for the ecosystem. It is very healthy that there are multiple independent but compatible implementations of the CLR and other tools so that everything is not tied to Microsoft.
> In summer of 1997, he [Miguel de Icaza] was interviewed by Microsoft for a job in the Internet Explorer Unix team (to work on a SPARC port), but lacked the university degree required to obtain a work H-1B visa. He declared in an interview that he tried to persuade his interviewers to free the IE code even before Netscape did so with their own browser.
Yeah, I am really curious why someone would hate the ecosystem. Very strong word for something like that, surely you have some reason beyond something as superficial as style or your personal experience with a person or project...? Do tell.
Excuse the rant nature of this but I'll give you some reasons as a software/devops guy who does 50/50 UNIX/Windows and has written more C# than I care to remember, daily for 12 years...
The ecosystem is horrible. Why?
1. It's full of little cargo cults powered by Greg Young, Udi Dahan and Oren Eini in particular. Each of these sells snake oil that costs you piles of cash and screws up your architecture or heavily couples it into a product which has a recurring cost.
2. Rip off merchants such as Telerik producing buggy components that rarely work.
3. Abandonware galore. There is no inertia. Everything tails off and dies after a bit. You can't drag something off NuGet without the inevitable result of it dying miserably after a year or so. At least we have NuGet now so ancient versions don't just disappear. We have to maintain our own forks of various things now.
4. Framework circle-jerking. Microsoft literally suck up to every framework that appears that gets traction resulting in much friction for those who adopted other frameworks before the circle-jerk began because it's not the one true framework (MVC validation I'm looking at you).
5. Everyone you get off the street is rubbish, at least in the UK. I mean really rubbish. So rubbish even though we offer a damn high salary, we have a 1 in 20 hit rate for staff. Perhaps 1 in 50 people actually give a crap past getting a pay cheque. It seriously attracts the wrong people.
6. Blindness. Not a single person I know has even managed to take a look at other platforms past perhaps owning an iOS or Android phone. There is literally no variation of knowledge or alternative viewpoint to pit the status quo against.
It's just a career programming market if you ask me and to be honest it's the only reason I do it. It pays better and I can work locally.
Fortunately I have a number of UNIX boxes I can dissolve into (much like some people drink after work).
I've been doing C# development for a few years now, and did 100% Solaris/Linux for the decade prior to that.
1. Never heard of them. They certainly haven't impacted anything I've done.
2. I've been ignoring Telerik for twice as long as I've been working in C#, because of their HTML/JS stuff. I'm not surprised their C# stuff is equally bad.
3. You could say the same about OSS projects on SourceForge, GitHub, or other repositories. Whenever you choose a third-party library (vendor-supplied or not) you have to consider how widely deployed it is, how big and active the community around it is, and what it's longevity will be. If you're not doing that (or doing it poorly) and getting burned by abandoned libraries, then you need to learn to judge better.
4. See #3. It's true though, Microsoft does tend to try to include everything; I suspect that comes from trying to develop general libraries/frameworks for use by Enterprise developers. Each Enterprise needs something specific, and most of them need different specific things, so a general-purpose all-inclusive framework winds up trying to have everything.
5. I think that's Enterprise thing again, and it's probably just as true for Java developers. When the vast majority of developers familiar with a technology are doing internal IT development for companies where software development is a cost center rather than an investment, the hiring pool is going to be full of mediocre developers. The best developers will be working for software companies and companies whose business advantage is based on their software, and that's true regardless of the platform they use.
6. See #5. This certainly applies to lots of Java devs too, and also most less experienced devs who started learning the trade in college rather than on their own.
Rant excused. While some of your points are more or less correct, would you care to elucidate on a few of the others?
1. You mentioned Oren Eini, who is the author of Rhino Mocks and contributed heavily to Castle and NHibernate. Apart from the usual TDD zealotry, how exactly do any of these screw up architecture? Or cost anything? -- they're free. Are you referring to RavenDB? Also, can you seriously name a platform that doesn't have celebrity developers slinging trash ware to line their wallets? Is this strictly a Windows/Dot Net phenomena?
5. & 6. While I agree that there are tons of clueless/mediocre Dot Net devs, I've met many that are exceptionally sharp and just as capable as any hardcore, passionate Java/Python/whatever developer. Passion outside of the Microsoft ecosphere? Are you at all familiar with the entire Alt.Net "movement"? Is your sampling based on the type of "talent" your company attracts? Or maybe the UK?
1. Oren is the least bad of the three mentioned, but his "Ayende" blog at times is a little vicious when it comes to slating other people's work [1] especially when the sheer number of bugs we've tripped over in NH, Castle dynamic proxy and NH profiler is as high as it is. I'm not a TDD zealot (I write tests for critical sections only, usually after the code writing event) but from an architectural point of view, unlike J2EE etc, there are no standard abstractions so once you've integrated something, you're stuck with it unless you fancy rewriting everything. This is hard work when your codebase is around the 2 million lines of C# and 150,000 lines of NH mapping XML (yes it's that big). Cost isn't just for the product - it's an ongoing concern. We've got to the point where we are becoming "that conservative enterprise" that someone else mentioned above.
Platform that doesn't have celebrity developers: C/POSIX. Even C++11 possibly now (I haven't evaluated it fully yet). Why? It's a set of standards, not a product. You're free to move around in it. I'd argue J2EE is fairly close to that but to be honest it's a pain to work with unless you're using Java EE 6. Go is pretty celebrity-free i.e. the authors with their heritage don't do it for the fame (which in itself sounds ridiculous).
5/6. Yes we've met them as well but to be honest they want lots of money (£100k+) or are contractors. I'm quite happy to take 3 people on that basis in myself and lose 6 members of our team as there would be a net gain but unfortunately employment law in the UK doesn't allow it and PHBs think more bums on seats is a good metric for measuring productivity. This is unfortunately a universal FAIL in the UK which concentrates on unemployment figures only - it's almost programmed into the minds of all business folk.
I'm not saying the last point is specific to .Net as for example the Perl developer community in the UK is even worse (I worked for an outfit where use strict was laughed at) but it's a hell of a lot easier to get a decent C expert than it is to get a C# expert just from the sheer amount of noise from low quality developers expecting miracle salaries. Recruitment agents are a joke as well (although they're easy to get a free lunch out of ;-) but that's another story.
> I'd argue J2EE is fairly close to that but to be honest it's a pain to work with unless you're using Java EE 6
The thing with Java is that the community is freaking huge. Actually, with Java you're not talking about one community, but of several huge communities.
If you don't like J2EE, that's OK, as there are plenty of well-supported and awesome alternatives. Alternatives like Dropwizard and Play Framework. If you don't like Java, the language, that's OK too, as there are awesome alternatives, like Scala, Clojure, Groovy or JRuby, all of them widely supported with big communities behind them.
Also, people should really acquire better taste in what technologies to pick. (N)Hibernate sucks so badly that I've always been amazed of its popularity.
Agree with your point about hibernate and its derivatives. Unfortunately with .Net you're stuck with that or EF which is even worse or something off the shelf and even crappier. TBH I've actually used raw ADO.Net with provider abstraction and dapper.net recently as replacements.
Despite its inefficiency, the old CQRS pattern with commands that INSERT/UPDATE and queries as typed DataTables are actually the most scalable solution I've found (over several years, not just on small projects).
7. Most .NET shops are so technologically conservative they mandate their developers write "C# 2.5" because those C# 3, 4, 5 features are too scary and unproven. Which is part of what causes #5.
Also, low quality commercial .NET libraries are an epidemic.
There's no such thing as C# 2.5. You must be referring to 2.0. Anyhow this may be true of financial institutions, but to say that it's a norm... is not my experience at all. > 15 years of experience.
Sorry, 2.5 was me being sarcastic, so I put it in quotes. It basically means you code mostly in C# 2 with a few C# 3 features cherry-picked (Like null coalesce, maybe implicit typing with var) but avoid anything LINQ-related.
Most of the problems arise from people not understanding that linq queries return iterators, not collections and therefore writing O(n²) loops. But that's not too hard to learn.
Alas, if you are talking about Linq2Sql or Entity Framework, then of course you have to deal with all the typical ORM problems; but this has nothing to do with Linq.
I think the common sentiment is that we'd all hope to hell that we never have to work on a project so crappy that team members can't understand programming language basics.
Hate is as strong as Love. I don't see people complaining when other people use Love to describe their feelings.
(0) I don't care how great .NET/C# is on top of Windows, because Windows does not exist for me.
(1) Visual Studio does not run on my Ubuntu Linux workstation. It does not run on OS X either. In contrast with IntelliJ IDEA or other IDEs.
(2) Mono sucks for building and deploying web services on Linux. Last time I tried it, I had to restart the process constantly as it was leaking memory. Performance sucked too. Things should be better now, with that new generational garbage collector, but building web services was always an afterthought.
(3) Mono is always behind (while also being ahead in some areas). Async landed in Mono and it's finally usable. People did have to wait a lot of time to try it out. People that think Mono is some sort of .NET for Linux/OS X/iOS are wrong. Mono can be treated as a different platform.
Also, Xamarin has been treating Debian/Ubuntu as a second class citizen. The latest version is 3.2.3, but the version I have on my Ubuntu is 2.10.8, as packaging is done by the community. I understand that they have other priorities, but they are also the only company that packages software for Linux and that ignores Ubuntu/Debian.
(4) The ecosystem has no real open-source culture. Most third-party tools and frameworks worth bothering with are proprietary/commercial. Most open-source libraries and tools worth considering are either part of the (small) Mono community or are clones of projects running on top of the JVM. The whole ecosystem is actually very Microsoft-centric and Microsoft couldn't even be bothered to ensure that NuGet works on Linux.
(5) As a corollary to the above, almost everything you need is proprietary and costs a lot of money. Given that my job does not involve .NET/C#, it means I can only use C# in my personal projects (that's how people start). I don't like building projects on top of freeware and again, as example, for $299 per year, Xamarin doesn't even provide email support. And I could rant all day about how BizSpark / WebSpark suc
Yeah, if he had simply stated that he didn't use Windows, you would have saved yourself some time by immediately disregarding everything he had to say, such as his informative summary of the .NET's OSS ecosystem, which you simplemindedly equated to "don't like".
"People are always waiting for Microsoft to develop new software/tools/IDEs and it results in a delay and in a dependency when talking about adopting new technologies like SASS, LESS and CoffeeScript, even when a non-Microsoft tool is developed, people tend to wait until a Microsoft solution is released to start to use these new technologies.
When good non-Microsoft tools are released (Resharper, CodeRush, RedGate Tools, NCrunch and others), they are usually paid, looks like the community culture is, if people pay for new software, people will sell new software. IMHO, it breaks a little bit the concept of community, that is everybody helping each other to build better and better tools."
Mono kind of sucks full stop, which wouldn't matter so much if Miguel de Icaza didn't try and oversell it for tasks for which it was totally unsuitable. For example, for the longest time the Mono garbage collector was non-generational and certain kinds of objects couldn't even be garbage collected full stop. This meant that OpenSim, a long-running server app that ran fine under .NET proper, ran out of RAM and crashed within hours under Mono.
Miguel de Icaza's response was to run the server under both Mono and .NET without actually connecting to it so that it was totally idle, and use the results to claim that in fact Mono was more memory efficient and the developers of OpenSim were just spreading FUD. I am sadly not joking: http://opensimulator.org/wiki/Mono
The Mono GC has improved dramatically in the past year. It's still not as fast as the CLR's or the HotSpot JVM's, but it's miles better than the old GC.
F# ran okay under the old GC (Mono 2.x), but tended to be a little crashy because it put a lot of stress on the GC (as functional languages tend to do). I haven't had any problems with the new "sgen" GC though (it's now the default in Mono 3.2.x).
But look at C# - since after they shipped version 3, they practically stopped doing anything neat with it. They haven't cleaned up any of the v3 features introduced (like type inference or expression trees) - it's just sitting there. In fact, from some of the statements I've read, it sounds like MS has purposely stagnated C# to avoid alienating their enterprise customers.
They mismarket F#, preferring to say it's for scientists and financial programmers. Instead of marketing it as what it is, a much more capable language all-around, unless you need certain GUI/tooling support.
These kinda things don't help .NET's reputation. If a non-MS affiliated company marketed a language as lean as F#, with as good a runtime and editor/debugger, they'd be a huge amount of "hipster" cred and praise.
C# 4 added serious dynamic typing, so that you can make ruby/pthon/js-style dynamic objects;
// properties not declared anywhere; runtime property definitions
dynamic myObject = new JavaScriptStyleObject();
myObject.firstProperty = "hello";
myObject.secondProperty = 1;
C#5 added async/await, which I think is one of the most 'integrated' ways I've seen of doing async programming. Think node.js with a lot less syntactic cruft around the callback functions; in C#5 you could write, say;
// evented I/O using the 'await' keyword;
var fileContent = await ReadFile(@"c:\foo.txt");
Console.WriteLine(fileContent);
rather than;
fs.readFile('c:\\foo.txt', 'utf8', function (err,data) {
console.log(data);
});
This eliminates the need to write lambdas while retaining the evented I/O style.
Both of which have been in F# for years, and C# re-implemented them later, poorly. F#'s dynamic is extensible (and around since 2007? 2008? earlier?)). If you wanted to implement a "dynamo" object, go ahead. If you want loosely typed CSV-reader access, go ahead. (You get the ? and ?<- operators to define as you'd like.)
C#'s async comes from F#'s async (available since Oct 2007), which in F# is just a library. That's because F# supports workflows aka computation expressions aka warm fuzzy things. What F# does as a library feature, C# requires baking into the compiler.
So for 5 years now, MS has added these two features. They've still yet to deliver a REPL, or finish implementing type inference, or any such stuff. It looks like Anders Hejlsberg, the main C# designer, seems more interested in adding some basic features to JavaScript, lately. C# seems fairly abandoned, language-wise, to me. They seem to be content to have put Java in its place, and leave it at that.
P.S. C#'s a great language, and I'm not trying to insult the people that have done great work on it. As a popular language, it's one of the nicest ones out there IMO.
I would dearly love for the C# type system to get a bit stronger and less verbose. It's also confused, I think, because you have explicit classes, anonymous types, and dynamic, and they aren't always very well put together. I actually also like what Anders did in TypeScript around structural types, and wouldn't mind some of that mojo in C#.
I take your point about pace, though. I wonder how it compares over the same timeframe vs other languages? In the 5 years for C# to cover that distance, what have other languages achieved? The biggies are particularly interesting (JavaScript, Python, Ruby, Java, C++, etc) because users probably demand more in terms of support and compatibility. (For others contributing, I'm thinking language-specific, so not libraries, frameworks, or runtimes, just pure syntax.)
It's also worth throwing uptake into the mix here; it's not much use if there's a version of the language defined in a spec but everyone's using the compiler from 1999 (JavaScript, I'm looking at you) I'm not a pythonista but I understand Python 3 has struggled with uptake, too. Not too sure of the details; happy to be corrected.
> C# 4 added serious dynamic typing, so that you can make ruby/pthon/js-style dynamic objects;
So you can match the so-so performance of dynamic languages (which is debatable, BTW) with C#'s horrid (when compared to Python or Ruby, at least) syntax.
I fail to see the advantages here. If I'm doing something that demands dynamic types, I do it in Python. If I need static-types, I do it in C, C++, Objective-C, Go, Java- whatever better fits the problem.
The purpose of dynamic is not to turn C# into a dynamic language. It was added to make it easier to interface with certain other parties. Sometimes you just don't have the type information (practical example is handling JSON data) and dynamic can make the code cleaner in these cases.
Dynamic typing support helps in a pinch in C#, as you can avoid a lot of code in some cases where performance isn't paramount. I've personally used that in a few cases in the past.
Static typing helps generating very concise and fast native code. I'd go with C or C++ when speed and or very precise control are absolute requirements. It also doesn't hurt you when you have a clearly defined problem that will never change - when you know you'll never receive a float instead of a 64-bit integer.
But there are other reasons to pick static typing. Using Java is natural for writing Android apps, Go has a very natural syntax for expressing concurrency and C# is the best choice when you want to write a Windows app. A programmer should always pick the language that better fits the problem it has to solve.
C#5 added async/await, which I think is one of the most 'integrated' ways I've seen of doing async programming.
What's with the C# developers ans async/await? Almost every time I read their exhortations it feels like they're blissfully unaware that other languages have already had their own mechanisms for doing concurrency.
We're talking languages here; the way a grammar construct helps the programmer.
The C# async language effectively writes a whole batch of code that you'd need to write yourself in other languages; try/catch blocks, callback functions, thread synchronization code, code to wait for results, etc. In effect, it makes into a language feature something that has previously been considered a design pattern.
So something like this in C# 5;
01 var foo = await LongProcess1();
02 var bar = await LongProcess2(foo);
03 var baz = await LongProcess(bar);
does a significant amount of work. If I were to code it without the language support, I'd be writing a great deal of crufty code to handle errors, to make sure one thread completes before using the result in another thread (see foo set on line 01 and used on line 02 for an example) and it avoids the callback hell problem of languages like JavaScript, which become apparent in Node.js programming, for instance.
I'd be interested to know what other mainstream languages have as complete a solution for asynchronous programming -- afaik, JS, Python, Ruby, Java, and C++ don't have this. I'm guessing erlang probably has it built right in, but I'm not sure. Anyone care to share?
We're talking languages here; the way a grammar construct helps the programmer.
So do I. We've had CSP, Occam, Newsqueak, Alef, Limbo; now we have Erlang and Go. I'm just puzzled by the walled garden phenomenon present in such communities as that of the .NET programmers. The very fact that you're comparing C# to Node.js (!), of all things, just confirms it. It isn't very difficult to beat Node.js in terms of the language quality. Hardly seems like a fair fight to me.
It's hard for me to see how I'm living in a walled garden here. If there is a Microsoft walled garden, Hacker News is very much outside the wall, isn't it? I'm here, not on MSDN, trying to have a reasoned conversation with intelligent people from different backgrounds, showing code samples, and asking openly for information about other languages. What else should I be doing?
> The very fact that you're comparing C# to Node.js (!), of all things, just confirms it.
The node.js comparison is fair, I believe. We're talking about language support for asynchronous programming, particularly the evented I/O programming idiom. That's exemplified by C#/await, and the Node standard libraries, and python/twisted, and I'm sure a lot of others.
Node is a very popular, visible platform which takes evented I/O as a core concept, so it's reasonable to compare the implementation of the idiom in C# to the current poster child. Is there a better comparison I missed?
> We've had CSP, Occam, Newsqueak, Alef, Limbo; now we have Erlang and Go.
Agreed. That's fine, and I specifically called out Erlang and asked for more info. However, the others you list suffer from not being mainstream development languages -- TIOBE[1] doesn't list any of them in the top 50 languages. Occam may well do it better, but since I can't pay the bills writing Occam, I'm more interested in the languages I mentioned -- JavaScript, Python, Ruby, Java, and C++. Feel free to throw in C, PHP, Perl or Objective-C. Do any of these languages have better language or core library support for async programming? Do they result in shorter, more readable, or more reliable code for parallel and async operations?
Your original reply -- "Almost every time I read their exhortations it feels like they're blissfully unaware that other languages have already had their own mechanisms for doing concurrency." -- suggests I'm unaware of something. Can you please start telling me what it is.
They've admitted that progress has slowed but have also explained why and it's got nothing to do with enterprise customers.
The reason is that they're rewriting the C# compiler using, er, C#. It's as part of an initiative called "Roslyn" that aims to make the compiler a pluggable component with a public API for the compilation AST.
They did a blog post recently explaining that whilst this work is ongoing they are trying not to change the C# language too much to aid them with testing and verification. But that once Roslyn is released they will start a fresh wave of language enhancements for C#. I think we all have some ideas on what those will be to start off with... proper tuples support, and probably some form of pattern matching.
What?? Visual Studio 2013 just shipped a week ago. They have released 5 versions of the MVC framework in the last 3 years or so. The new async/await stuff is fantastic. EF6 is new. SignalR is new. We get new Windows Azure SDKs every 3 months or so. They are constantly improving everything.
None of that, except async, is a C# feature. And that was taken from a 6-year-old F# feature of the same name, except in F#, it was implemented as a library, not baked into the compiler.
MS is moving .NET ahead as a platform, but C# doesn't seem to be doing much. As another comment said, they're rewriting the compiler and then are supposed to make it take off again. Still, 5 years with minimal additions seems "stagnant" to me.
> it was implemented as a library, not baked into the compiler.
You keep saying this as if its a bad thing. Personally I consider it the exact opposite. I have no experience with F# but my experience with features that are baked into the language vs in a library is that having a feature be a first class citizen gives all sorts of benefits in terms of usability, consistency, tooling support, not to mention being able to justify introducing the fancy new feature into your project.
Nothing about having it be a library means there's anything less in terms of usability, consistency, or tool support. It's not like people avoid System.Text.RegularExpressions because it doesn't have a compiler-intrinsic ~= match operator.
The exception I see is if a certain pattern requires a drastically different compilation method, even if only as an implementation detail. That would perhaps break debugging support. But that's not much of an argument, because nothing stops you from special-casing your tooling support (which you'd presumably do anyways).
It just seems incredibly inelegant to have to special-case things in a language when the general case could be implemented.
case /\(.+)!(.+)@(.+)/
nick, user, host = $1, $2, $3
...
vs
if( (match=new Regex("(.+)!(.+)@(.+)").Match(caseInput)).Success )
{
var nick = match.Groups[1].Value;
var user = match.Groups[2].Value;
var host = match.Groups[3].Value;
...
}
If I'm using a ton of regexps, having domain specific language support can certainly help keep things simpler and clearer, aiding usability by aiding readability. This is important enough people can and will resort to implementing their own domain specific languages. While I'm all for erring on the side of general purpose language features for a general purpose language, if only to reduce the possible explosion of corner cases for language design mistakes, discounting language level support as "inelegant" and having no benefits is, to me, tantamount to discounting DSLs in general for the same.
And perhaps you do so, but the argument doesn't resonate with me.
F# active patterns allow you to do exactly this kind of thing, in a general and extensive way, without building support for regex into the compiler. That's what I'm talking about.
And it takes all of 4 lines to add the support:
let (|Regex|_|) pattern input =
let m = Regex.Match(input, pattern)
if m.Success then Some(List.tail [ for g in m.Groups -> g.Value ])
else None
Boom, done. I'd call that a far more elegant approach than hardcoding regex into the language. Edit: And nothing is stopping the core developers from including such patterns in the standard library. So you get the best of both worlds, a common well-known manner, and a useful general purpose feature that people can extend and use if they need so.
Usage looks like:
match phone with
| Regex @"\(([0-9]{3})\)[-. ]?([0-9]{3})[-. ]?([0-9]{4})" [ area; prefix; suffix ] -> ...
If you look at how much has been added to say, python or ruby or java in the same time frame it seems comparable. .NET 4 (released in 2010, so really only 3 years ago) added a ton of new features (dynamic, better generics, better expression trees, optional paramters, etc.).
NET 4.5 was comparatively a more quiet, but I think that's just a consequence of the language maturing.
C# 4 did bring forward the covariance/contravariance feature that's been in the CLR since v2, yes. And they did add dynamic, which was the big major feature of v4.
Better expression trees, as I understand, aren't accessible from C#. That is, the C# compiler doesn't allow you to write arbitrary code as an expression. What shipped was the DLR-based expression trees, which are more flexible, but require a cumbersome API. So that's not really a feature. (Correct me if I'm wrong; I haven't used C# extensively since 3.0 as I moved to F# for .NET tasks.)
Optional parameters were a mistake to leave out of the original spec. MS insisted that providing a ton of method overloads was a more elegant approach, for some insane reason. And at any rate, the C# implementation C# is the same, lame, VB/C-style callsite embedded optional parameters, which hampers their usefulness (but it's still much better than overloads!).
Perhaps I have unrealistic expectations from C#, as I certainly don't appreciate the effort required to design a language for such widespread use.
> If a non-MS affiliated company marketed a language as lean as F#, with as good a runtime and editor/debugger, they'd be a huge amount of "hipster" cred and praise.
OCaml? Which is what F# is based on, compiles to anything (including fast native code), and is open-source?
Are OCaml's main libraries even threadsafe yet? Is there a smooth editor/debugger like Visual Studio? Just a quick look says the Windows version of OCaml doesn't even have a debugger. OCaml is neat, and more advanced than F# in some aspects, but I'm not sure the dev experience is nearly as slick.
Another thing not mentioned: libraries. Anything half-well designed on JVM or .NET has access to a massive amount of libraries (and both stdlibs are pretty complete). Depending on the project, that's not a trivial consideration.
You can get a fairly complete stdlib on OCaml too, as long as you are willing to commit yourself to using Jane Street Core rather than the one that comes with the language.
Perhaps because you're being pedantic about .NET versus the CLI? The CLI spec is a standard and open source. Microsoft's own version isn't open source (well, they did release an "open" source version, Rotor). But Mono's is.
F# has a very strong following on Mono though. In fact, I suspect a higher percentage of F# developers develop and/or deploy on Mono than any other language does.
You may not know this, but F# ships with the Mono distribution for OS X, and it may well ship with the Linux packages before long.
BTW, I maintain the F# port for FreeBSD, and the combination of F#, Mono 3.2.x, FreeBSD 10, and emacs is extremely fast and stable. http://fsharp.org/use/freebsd
That's true. Mono is generally slower than the CLR, though it has been improving ever since Xamarin took over. There's also an option now to use LLVM as the JIT compilation engine in Mono; for server-based applications (where steady-state performance matters more than start-up time), this can greatly improve the performance thanks to LLVM's optimizer.
With the improvements in the latest 3.2.x branch, I think Mono's performance is at least "good enough" for many use cases.
FWIW, I do a bit of F# + Mono development on FreeBSD 9 (and now FreeBSD 10) and have found the performance to be quite good. I wrote an installation guide (http://fsharp.org/use/freebsd) if you want to give it a try, e.g., in a VirtualBox VM.
Whilst no, the Microsoft CLR is not open source. It doesn't need to be. Because the CLI is a ECMA standard and known-good third party implementations (Mono) already exist.
The only thing to be gained from open sourcing the Microsoft CLR would be to benefit Mono. As Mono is the defacto official cross-platform port of the CLR. Since the Microsoft CLR almost certainly contains IP and trade secrets that they wouldn't want their commercial rivals to see, it would be more beneficial if Microsoft merely gave a fairly open code sharing and IP license to the Mono / Xamarin team so that they could benefit in the exact same way as though it were OSS MIT.
I can make the same comment about C#/F# guys when I show them Scala. Scala is a better, more powerful language. I quite like C# and do it for my main contract I have, but I am always missing features that Scala has, while I never have the inverse.
It's nice that F# has better type inference, but I feel like it really isn't that different than C#. If C# got rid of boilerplate, made brackets optional, and fixed type inference, what does F# buy you?
Workflows. Tuples. Immutable types. Inline functions. First-class functions. Definable operators. Pattern matching. Active patterns. Type providers (although full hygienic macros would be even better). Everything-as-an-expression. Lack of nulls. Nested functions. Discriminated unions. Quotations (expression trees are a weak hack just for LINQ-to-SQL). Object expressions. Concise function definition and application syntax (which naturally creates the illusion called partial application).
I make the inverse argument: At a minimum, you can use F# as C# but with better syntax. So what does C# buy you, if you're not using some of the VS designers?
Without workflows, you can't achieve e.g. async without building it into the compiler. You can abuse the LINQ syntax to simulate part of it, but you don't get proper exception handling, and it reads terrible as well.
Versus Scala, F# seems far more concise. Scala seems to be very Java/OO oriented, and comparatively verbose. I understand the type system is more advanced in Scala. But I've not written anything in Scala so this is sorta speculation. I'd be surprised to find that the tooling for Scala surpasses F#'s though.
You mean apart from discriminated unions, pattern matching, computation expressions, units of measure, partial function application, immutability by default and general lack of null reference exceptions?
I'll throw in my 2 cents about Xamarin: I'm amazed at how well it really works. I'm involved in a project right now developing a mobile app for Android that uses a USB-connected sensor to do color analysis. It's all been done in C#, and it's so nice to know that when we want an iOS version of this, we just have to do the storyboarding. Once that part's done, the app will already be fully-tested and ready to go.
Xamarin now also supports writing iOS and Android apps in F#; it's only a "preview" at the moment, but some of the Mono developers have been getting more involved in the F# open-source community and Xamarin recently hired a well-known, very skilled F# contractor to help improve their support for the language.
There is also the "dynamic" part of C# and the DLR. Here is a library I worked on to mainly showcase the dynamic features - https://github.com/manojlds/cmd
Clojure has some awesome libraries, but unless you can show some use cases where futures/promises and core.async make it possible (or even just easier) to implement functionality compared to async/await (or F# async) I'm not inclined to take your word for it.
CSP gives you everything async/await gives you, plus more. Channels can act as throw away promises, or as continual streams of events. Add to that the power of alt! (http://clojure.github.io/core.async/#clojure.core.async/alt!) and you got some very powerful primitives. There's nothing about async/await that's really new. You can implement these on top of yield (C#/Python), or with any language that supports the pausing and resuming of execution.
In Clojure CSP is implemented as a library (core.async), no changes to the compiler needed. Now that's power.
I agree, async is much more flexible and powerful when it's a library feature (as it is in F#) as opposed to being a built-in language feature (as it is in C# 5).
core.async looks very well-rounded, congratulations on a fine job.
Replying to myself, since I can't edit my post anymore --
Futures and promises aren't unique to Clojure. For example, AliceML had them ages ago.
After thinking it over, I'm going try implementing them for my ExtCore library for F# (https://github.com/jack-pappas/ExtCore). Thanks to the GP for the idea.
When I meet other devs and tell them I work in lots of languages and platforms but prefer c# they usually look at me like I have 3 heads.
I like to show them LINQ and Async as some things I really like about C#, then I get into how rich the BCL itself is.
Devs are also pretty shocked when I tell them I can write truly 100% native iOS and Android apps in C# (thank you Xamarin) and that one of the most popular mobile game engines (Unity) uses C# and a version of the .NET Framework under the hood.