C# contemplation points

04 July 2018

C# has come a long way since 2000 – its popularity in the TIOBE Programming Community index peaked in Feb 2012 with an index score of about 8.6%. While it is now at 4.3% and the trend is one of gradual usage decline, Chris Sawyer suggests it should not be set aside just yet.

I’ve mentioned the TIOBE Programming Community index several times over the years as it’s a good resource for picking out future language trends. It is good, but not foolproof. It’s susceptible to Google tweaking its indexing algorithms and this can throw out results.

That said, I want to look at C#. It has come a long way since 2000 and should have stuck with its original code name ‘Cool’ (it didn’t for trademark reasons — even Microsoft’s pockets would have been emptied defending that name in court). Its popularity peaked in Feb 2012 with an index score of about 8.6%. It is now at 4.3% and the trend is one of gradual usage decline. This is possibly due to several factors:

• Microsoft is pushing Azure and its ‘any language will work’ service strategy rather than an ‘Azure is great but it’s C# only’ strategy as that’s where the regular money is.
• Other more dynamic languages are vying for people’s attention, e.g. Python with Numpy/Pandas/AI, or Kotlin, and hoping for a productivity boost.
• C# is promoted and developed by a single company.

Now .NET Core is a good answer to some of these issues and allows for writing C# on Linux – which is neat, but it’s probably a bit too late and Linux has no shortage of languages already. So, what does the future hold for C#?

The language isn’t standing still, it’s actually accelerating – albeit slowly – with version 7.3 released in May and there are also some interesting features coming up in version 8:

• Non-nullable references. This is a great feature for making you think about your code and therefore improving its robustness. However, you can’t just switch it on for existing code, as it will almost certainly break everything. Great for new routines though.
• Default implementations in interfaces. Like Java (I do) and just as useful.
• Lightweight classes called ‘Records’. Class Quote (Guid Id, string name, decimal value), that sort of thing. It gets expanded out with all the usual boilerplate, such as IEquatable. They are also directly comparable, so equity tests are easy.

So, keep the faith and don’t migrate away just yet. Especially not to Scala.

Fabrics for HTAP

I’ve mentioned it before, but we’re increasingly taking on projects that can be classed as ‘HTAP’ — Hybrid Transaction/Analytical Processing (thank Gartner for the name). Think of it as OLTP merging with OLAP. The results of deep analysis of your vast pools of data are moving closer and closer to real-time, but the data needs to be processed closer to real time as well. These are competing challenges with the processing side wanting lots of small transaction with a high percentage of updates, but the analysis side wanting long, complex queries across huge data sets. The arrival of cheap(er) memory – which in turn leads to In-Memory data processing – makes both these requirements possible and there are now many database vendors and open source solutions that provide HTAP solutions.

In the past, Riskcare has used best-of-breed independent components for in-memory data stores – backed with robust messaging (using, for example, Redis & Apache Kafka) – but there are other solutions that exchange some flexibility for performance, and disk-based processing nodes for more memory.

Sometime though, a good solution needs more than a database with memory-based tables and that’s where Data Fabrics come in. Fabrics cover far more than just an in-memory database and usually provide:

• Key-value store.
• Messaging/queuing.
• Calculation grid.
• Directory service.
• Micro service hosting platform.

Two of the most popular are Apache Ignite/Ignite.net (open source – the commercial name is GridGain) and HazelCast IMDG. They’re both Java-based and excellent choices, although I find Ignite easier, faster and more feature rich. A few minutes of Duck-Duck-going (I refuse to ‘Google’ stuff, DuckDuckGo is far superior) will show that these two companies argue about benchmarks and features like ferrets in a sack. There’s a third interesting choice though and that’s Microsoft Service Fabric (SF).

SF is open source and C# based and forms the underpinnings of Azure. It can host code written for either Linux or Windows and takes C# or Java, or Python etc. Code written for Docker containers or plain windows services and allows them to run in a resilient manner. It can distribute key-value based data using ‘reliable’ services and even supports an Actor-based development model ‘reliable Actors’ inspired by Microsoft Orleans framework. It comes with some really nice support UIs, but you do have to compile it yourself and that takes about four hours on an eight core, 32Gb PC, which is the minimum spec. This really is a different Microsoft – Linux, Java, Python? They really are moving to a platform-independent, services-based company as fast as possible.

What about the most famous Fabric? The ‘Tweed’ of fabrics is Oracle Coherence – old and reliable. It hasn’t seen any real updates for five to six years now. It is not really a data fabric as its functionality is limited, but it’s the one most people think of.

Microsoft Office Fabric API in react

From one kind of fabric to another. The Microsoft Office 365 widget set and UX rules, or ‘Office 365 UI Fabric’ as it’s known, has been around for a while and is exceptionally nice. This means that any applications you build will have Office’s look and feel as well as all their lovely widgets to complement all your components and fit right in. It’s also available for Angular and iOS but React JS is the platform of choice. It’s definitely worth a look.