Home > C#, IronPython > If C# is so awesome, why use anything else?

If C# is so awesome, why use anything else?

Anyone who knows me professionally knows I work in C# most of the time. I think it’s a great language that’s been well designed and made very portable by way of being an open language specification. A lot of people look at C# and say, that’s just Java with some Microsoft-extensions. Sort of, since it’s framework (.NET) ships with quite a few libraries that interoperate well with Windows, although the C# language itself doesn’t have anything to do with Windows, and runs on Linux, OS X, Android, iOS, and so on. In my opinion, Java has stagnated over the years, while C# has been evolving with generics (which Java followed), lambdas (Java finally gets them years later), anonymous types, partial method and class declarations, language integrated query (LINQ), dynamic runtime integration, and soon a simplified asynchronous programming model with await and async that will allow the runtime to deal with the gory details of async programming rather than forcing the programmer to understand and properly implement callbacks and cleanup. Java isn’t catching up fast, so Scala is filling the gaps, but C# remains years ahead.

Every year, my family looks at me funny when I they give me new books. That’s right, I’m a geek that reads computer books. Most of these books are not on C#, but on JavaScript, Python, Haskell, and I even keep an old PERL book on my shelf. What is all this other stuff?

JavaScript – it’s pretty rare these days that other developers would say, “why would you ever want to write JavaScript?” It’s a ubiquitous language amongst web browsers, and it’s pretty rare that anyone can write much of a browser-based application at all without it. Besides, the latest trend is to write a “language X to JavaScript converter” and what good would that be if I didn’t know JavaScript and wasn’t willing to learn language X? There have always been some nice server-side implementations, like Spidermonkey and newer V8, powering trendy applications like MongoDB and Node.js. Until I started down the Python path, whenever I needed extensibility, I would embed Spidermonkey for some JavaScript fun.

Python – in the realm of C#, a lot of people are uncomfortable mixing in Python. They don’t like the idea of losing compile-time checks and worry about needing a myriad of Python frameworks to solve any sizable development tasks. However, Python is an excellent tool for large and small projects alike, and IronPython take the Python language and gives it access to the full .NET framework. In the last few years, I’ve felt constrained if I didn’t have a layer of extensibility that IronPython can add to CLR applications. Python scripts let you treat code as data, meaning you can store it, transmit it, and change it at runtime. Python gives you a new way to move the problem around, solve it at a different time in your overall solution. It’s a great piece of the toolbox.

I remember spending weeks building business rules engines so non-programmers could add some logic to enterprise applications. These engines would use reflection and Lightweight Code Generation (LCG) and a clumsy UI where end users would select data objects and operators and build expression statements. IronPython uses LCG, is highly optimized, and gives you a general purpose scripting language with access to CLR objects. Most end users prefer the ability to write an expression in script rather than fumble with the type of UI needed to build an expression tree. This is just scratching the surface of the Python language, but at the very least, it’s a great tool anywhere you want to offer runtime extensibility.

Haskell is pure functional programming – no state, just functions. I used F# a bit for professional work just to learn it, but it allows you to fall back into the OOP line of thinking. Haskell makes you take a fully functional approach. I recommend every developer that’s looking to expand their approach to problem solving to spend some time with it.

What about that PERL 5 book? Well, I don’t use that, to be honest. I did once upon a time, but I really do avoid PERL at all costs. Maybe one day, I’ll pick it back up.

Categories: C#, IronPython Tags: , ,
  1. obran
    September 11, 2012 at 5:26 am

    Why use anything else? Maybe because the .net platform doesn’t run on Unix or Linux which happen to dominate the server market. Are you suggesting that everyone should migrate to Windows? Are you willing to pay for that? Can you guarantee that things will still work as expected as when the *nix platforms were in place?

    • loosexaml
      September 11, 2012 at 6:52 am

      Why migrate to Windows? And why would I pay for your migration?

      Mono framework anyone? I write C# code that run on *nix platforms every single day with mono. Like I said in the post, C# itself isn’t specific to Windows, and the mono framework brings a very well designed and forward thinking language to many other platforms.

      • obran
        September 11, 2012 at 7:23 am

        So you’re telling me that we should be using the mono framework for our production applications. Our applications that are absolutely mission critical? I’ve seen many large organisations that would never trust their production environments to the mono project.

        Does mono have any kind of mature enterprise support? Do you honestly think that the mono framework should be a single source of failure for all major software applications that are currently running on *nix systems?

        If you think mono is the answer to getting high scalability and high availability production software written in C# running on existing UNIX infrastructure then you are fooling yourself.

      • loosexaml
        September 11, 2012 at 8:08 am

        Many organizations don’t trust any open source software in general, for unfounded reasons like security concerns or fear of having to open source anything that touches it. How is your concern any different? If it’s a concern of stability, test your software on the platforms you intend it to run – functional testing and load testing – and find out where it really breaks. This would be just as true if using java or python.

        If you’re in an environment where everything is built on JBoss, and you have a complete development and support infrastructure built around that, that’s a good reason to use Java. If you’re in an environment where everything is built on twisted, that’s a good reason to use python. You probably wouldn’t port all existing applications to a different language because there is likely not a tremendous benefit to converting these applications instead of spending that time fixing bugs or adding features.

        So what’s your scalability and availability solution? Is java or python magically more scalable and available or do you gain scalability and availability by building applications in such a way that they can be easily distributed across processes or servers? I really don’t think the language of choice has as much to do with production uptime as the application architecture itself. Unless you’re an extraordinary gifted developer and architect (or just never implemented any software) I’m sure you’ve built a single point of failure into an application before. Was it the language or framework that caused that?

  2. obran
    September 11, 2012 at 8:24 am

    Given that a fair amount of our clients run Tomcat and MySQL in their production environments, I can assure you it’s nothing to do with being nervous about open source.

    It comes down to how proven the platform is. We can’t risk using mono in production as it’s an unproven technology. There aren’t multiple examples of where it’s being used in similar environments to ours with any great success. Why would we want to be the guinea pig for that?

    Even with all the testing in the world, we can’t be sure that the framework isn’t going to let us down in ways that would have only been discovered through extensive production uses.

    Even if testing could identify these issues and it turns our mono isn’t suitable for us, why would we want to burn all that money testing something that isn’t proven? At least we know our JVM, Glassfish and Tomcat infrastructure (or similar) is used in multiple other places doing heavy load and high availability stuff. We have some level of confidence before embarking on creating the infrastructure. You just don’t have that with mono.

    Why would we use anything else other than C#? Because we have massive Unix infrastructures that are mission critical. That’s why.

    • loosexaml
      September 11, 2012 at 9:44 am

      I wouldn’t make a decision based on FUD, but yes, there are more users of the JVM than mono so there has certainly been more testing. That isn’t to say it can’t or doesn’t run in just such an environment, but that you have more “shoulders to stand on” when you run JVM on UNIX.

      Also, you have a lot of existing Tomcat and mySQL infrastructure that’s a good reason to stick with Java.

      But to say that mono can’t run mission critical applications on UNIX because you can’t find enough examples is a poor assessment.

      When I write mission critical software, I don’t make any assumptions about the underlying stability of the system and use persistent transactions for mission critical data. If the application or OS or server or network fails, the mission critical data isn’t left in an indeterminate state where another server can pick back up and continue the overall job. If the data is critical enough, maybe I don’t consider it persisted until its been persisted to DB, fsync’d, and replicated to two other data centers. This approach has absolutely nothing to do with the language or framework, but with the overall solution architecture. this was as true when I’ve written Java applications as when I write C#. Don’t pretend that writing in Java gives you some sort of safety net for your users’ mission critical data. You’d be the one fooling yourself.

  3. obran
    September 11, 2012 at 10:19 am

    So back to my original point. We don’t use C# because we have a massive UNIX infrastructure and mono hasn’t proven itself and we’re not going to risk money on testing out the framework.

    This is why people don’t use C# in general to be honest. The London Stock Exchange completely migrated away from Windows Server. I doubt it ever occurred to them to try and run all of their C# code on their new Linux infrastructure. What idiot would do that?

    • loosexaml
      September 11, 2012 at 11:17 am

      Well, your original point was, “Why use anything else? Maybe because the .net platform doesn’t run on Unix or Linux which happen to dominate the server market.” That’s a false statement. It runs, runs quite well, has a very large and growing user base on platforms other than Windows. Your answer, to paraphrase, is that C# just isn’t capable of producing mission critical applications. I’ve worked for several large enterprises where our .NET software supported mission critical applications with enormous transaction volumes, so again, I think you’re just making false statements. Mission critical applications come with a large set of infrastructure requirements that have little to do with the application implementation language and more to do with management of the technology.

      As for the London Stock Exchange, I think you’re saying that they migrated away from Windows Server (where C# is fully supported by a mega corporation on the same scale as Oracle), over to Linux to escape C#. It might be worth noting that they didn’t move to Java, but to C++. I don’t think the JVM, Tomcat, and mySQL would fare any better in running the London Stock Exchange, even on massive UNIX infrastructure.

      Finally, why the incendiary tone with statements like “you are fooling yourself and what idiot would do that?” You’re making assertions based on anecdotal evidence and I’m suggesting you take a more pragmatic approach to considering technology choices. We aren’t all building a stock exchange. If your software runs on mySQL, I kind of doubt you are either. I’m sure you make great software, and I’m not trying to imply that you are an idiot for not considering the mono framework for running applications on UNIX, as it sounds like you had other reasons. For one, you’ve got an existing Java application running on Tomcat that’s in use and making lots of money, and probably a lot of Java developers that know your business domain, so it doesn’t make sense to migrate it to C#. Back when you chose Java, were alternatives considered? Why didn’t you choose PERL if you want a mature framework or Erlang if you wanted extremely high scalability? Today, mono is a viable consideration, and if one is building a new application or porting an existing Windows application to UNIX or Linux, it should definitely be considered and evaluated on real world scenarios. In particular, if you’re building a mission critical application on any software stack, you really need to be doing your homework and not just reading some blogs to decide what to do.

  4. obran
    September 11, 2012 at 11:41 am

    Your reply seems to be putting a lot of words into my mouth!

    Mono isn’t viable until somebody proves it capable. What idiot would think they should write C# with a view to deploying it into a UNIX production environment… fan boys like you maybe?

    • loosexaml
      September 11, 2012 at 12:09 pm

      Do you have a blog, or do you just troll around on others’ blogs? You seem to take a very junior software development approach, where you think the one language you’ve ever used or maybe even the one platform you’ve ever used in your 6 months of professional experience makes you an expert in building mission critical software. I’m sure the people at the company that’s willing to put up with you had the forethought to make reasonable and rational decisions, weighing various platforms and technologies in order to build the large scale mission critical system that you happen to help maintain. That doesn’t make YOU an expert in mission critical systems or even a useful contributor either to that software or to this blog. Maybe you are a real expert in mission critical software, and you can share some of your excellent architectural designs and Java patterns that have helped you to build a successful platform, but I expect that you have little to no expertise and will have to always remain a little troll.

      If you have real beefs with mono, then much like other open source technologies that you use, there is a community and company that supports it, and would welcome useful contributions, even if they are nothing more than, “this thread pooling model doesn’t scale well and here are my metrics to prove it.” If you just go to people and say “your software sucks because I think the language or framework or library sucks” then everyone will pause for a second, think of how worthless your opinion is, maybe take as much time as I have to respond, and then move on without care or regard to the nonsense you spew.

    • loosexaml
      September 11, 2012 at 5:55 pm

      Maybe it’s just me using it or maybe all these companies:


      along with many, many commercial and enterprise software companies and developers that for one reason or another don’t want to list proprietary information about their implementation stack.

      Obviously the framework has proven itself, but you can pretend it hasn’t if that makes you feel better.

    • mathgl
      October 22, 2012 at 1:27 am

      I want to know who is somebody and how He/she can prove it?

      • loosexaml
        October 27, 2012 at 9:53 pm

        I’m not sure I understand the question. What are you asking to prove?

  5. obran
    September 12, 2012 at 4:40 am

    From an enterprise perspective, it’s not proven until other enterprises with similar availability and scalability issues have implemented it. Pointing to a list of other implementors, none of which I’ve hard of and none of which are doing anything remotely similar to us doesn’t fill me with confidence and this does not mean it’s been proven.

    • loosexaml
      September 12, 2012 at 12:00 pm


      It sounds like the Craig Silk Certification Program is quite comprehensive. Best of luck with your project.

  6. obran
    September 12, 2012 at 4:40 am

    *heard of

  7. Mike
    June 4, 2014 at 6:36 am

    The reason I write software in C# is ease of use, very good and heavily supported (of course it’s $ that supports it but that’s not the case here) visual studio and many libraries out there to use. What I don’t like is lots of dependencies required to run simple application. You most likely will want to use one or two functions from .net framework yet you will have to include the whole .net framework in your installation package in order it to work. I compare here, for instance, size of .net to size of Qt and Boost together. I tried many times to start with c++, telling myself that I’ll finally do some scalable app but eventually I always ended up in C#. One reason was that it had to be done quickly and just do it’s job in windows environment. I keep telling myself “you are working in windows environments only, why bother trying in cpp” but it’s so hard for me to accept the fact that I’m developing in language that is platform dependent and probably over-sized. Like I’m not accepting the fact that we live in 32 core CPUs and thinking that my software must run on microcontrollers.. hehe

    • loosexaml
      June 4, 2014 at 3:16 pm

      There is mkbundle for mono, which can embed just the libraries you need into a resulting application.

  8. AndJohn
    October 11, 2015 at 10:41 am

    Windows and .NET are suck and still far away from *NIX and Java. One of example big issue on having NET in mission critical environment, is inability to get stack dump when the app is hanging. In the mission critical, this stack dump is a must and in *NIX, we just easily execute “kill -3” or jstack for it. It is just silly people to use .NET to run mission critical. You want to just reboot the production server without corrective action when the app is crashed, LOL…

    • loosexaml
      October 11, 2015 at 10:49 am

      That’s a good thought, but just so you can be a little less naive, to get a thread dump from a mono app, do this:

      kill -QUIT $PID_OF_MONO_APP

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: