On the need for a C# Renaissance
On the need for a C# Renaissance
In 2011, Bob Lee, speaking at OSCON, rallied Java developers against the decline in the usage of that language post the rise of Ruby on Rails, and identified that the time was right for a Java Renaissance: https://www.youtube.com/watch?v=k-PyVYY7QFI
In 2017, we need to rally C# developers against the server-side decline of the language, post the rise of Rails, Django and Node.JS. The time is right for a C# Renaissance.
This is a long post, but I want to cover off a number of things.
First, some may doubt that we are in any kind of Dark Ages that requires a Renaissance Certainly for developers targeting Windows Desktop there is little competition; Xamarin does well on Mobile; and Unity is strong in games programming. And any look at job data suggests there are a lot of vacancies for .NET developers. But for server side .NET, many have a nagging feeling that there, the jobs are drying up and there are fewer new projects. I will demonstrate with some data, why folks are feeling that, as on the server, the picture is less rosy.
Second, I want to look at some of the reasons for this decline on the server: what replaced .NET and why.
Third, I want to talk about why the developments coming down the pipeline create an opportunity to reverse that situation.
Fourth, a .NET renaissance requires a body of knowledge for us to discover and reinvigorate our language. Where is this coming from?
Finally, any Renaissance that takes advantage of this development will only come if we, the community, create it. We cannot rely on MS. We have to build excitement about .NET on the server at community events, and infect people outside the community with that enthusiasm. This post won’t address all of that, we will need more time to talk about it, but hopefully it can frame the conversation.
I hope this post will be the start of a debate. I don’t necessarily have this right. Others may have a very different viewpoint on whether we have been in a dark ages, and whether we can create a renaissance. I could be very wrong. But let’s discover the truth together.
The Dark Ages
Decline
The news for server side C# developers, seeking a platform to support their careers has been poor in recent years.
Pulling data from Indeed.com shows that overall C# jobs declined from 1.4 % of software development jobs, to 0.84 %
In the US, there are half as many new C# positions now, as there were four years ago. By comparison Python grew from 0.54% to 1.11% during the same period.
Now, this situation does vary by geography. In some places C# is more popular than others, with historically there being clusters around Seattle, Austin, New York, and London for example.
So let’s drill down on some data I understand anecdotally, as well as by numbers, to see what is happening: the UK.
The UK has long been a strong C# market, so it should be possible to judge the health of the language there.
A look at C# in the UK suggests that it was in high demand, between 2009 and 2012 before declining, more sharply in the contract than permanent market.
But overall the number of jobs in C# in the UK remains strong — so it does not look as though you are going to be out of work tomorrow by choosing C#. Sure C# is trending down, but is that 5% slope in permanent and 8% slope in contract significant enough to bother us? There are still a lot of jobs.
What is worrying is that decline in the contract market can be a leading indicator of a drop in new projects. The danger is that this implies that shops only use C# where it already in use, and not in new developments. If true, whilst existing .NET shops will continue to provide work on their existing codebases for some time to come, due to the market penetration of C# for all those years, that situation lasts until it doesn’t.
But we all know, it isn’t just about a development job. It is about a ‘good’ job. Few people like Sharepoint for example, but that usually counts as a C# job:
Anecdotally, the experience of many of my UK peers when job hunting for C# projects is that ‘good’ positions are harder to come by. What is a good position? I think most people think of a role handling both web and worker roles on the server, not Sharepoint roles. Of coure YMMV.
It is the backend roles though, in particular, that are drying up. C# has less competition on the Windows Desktop or within Office Automation, but on the server there are many more options.
So does the data explain this difference between what people feel when they are job hunting, and what those numbers for C# developers suggest?
Well, let’s drill down more specifically.
Take a look at this graph for ASP.NET jobs in the UK:
Whilst demand for permanent roles has fallen, it is in contract roles that we see an extremely steep decline: since 2009 contract roles have fallen from 20% of all IT jobs, to less than 10%. Half of the open contract positions have gone since 2009.
This reinforces the picture from the Indeed data for the US, though it started in 2009.
Don’t feel sorry for contractors? Remember that contracts are often a leading indicator given that contractors are often brought in for new projects. This suggests that new backend roles for C# are dying out.
It is this precipitous decline in contract ASP.NET roles that matches anecdotal evidence from peers of their struggle to find ‘good’ roles: the collapse of .NET on the server.
To understand the strength of C# we might look at some of the indicators of language popularity. Again, some of the headline data looks positive, C# consistently remains a Top 5 language in most benchmarks.
What is more worrying is the trend line.
For Tiobe the popularity of C# peaked in 2012 , has been in decline ever since, and has declined by half from its peak.
Fall
On the backend this news is worrying, as it suggests that for ASP.NET projects, C# is close to becoming a legacy platform. Those anecdotal stories, do appear to be backed up by data.
Now, I want to drill into C#’s plight on the backend. Again it is that I really understand it better. It’s been some time since I did windows desktop, or phone and games are outside my experience. There may be no decline there, which is great if true.
But first, let’s remember, the UK is a good market for C#. There are more C# jobs than Java jobs.
So why worry?
As with any data, there is plenty of room for interpretation, but we can be clear that whilst C# is an important platform today, it may not be tomorrow, particularly on the server.
The good news is that C# started from a significant base, particularly here in the UK. So its decline does not have to be terminal, if we don’t want it to be.
Java and .NET sitting in a tree
Before anyone using Java gets too much schadenfraude over the old rivals decline their graph of job data shows exactly the same decline in that time frame — they started at about 3.5% and declined to 1.5% So although Java started at a higher point, its trend in the US is similar.
Remember that conversation on local hotspots? By comparison to the US The permanent market for C# seems better in the UK than for Java, reflecting that stack’s popularity over they years here. But we show similar overall data. Java has lost about 5% of its permanent roles in the last 5 years, and has declined by about 10% from 10 years ago:
The contract market for Java was showing a similar pattern, but seems to have recovered since 2013, growing by 10% from its all time low of 24% of UK IT jobs, which suggests that the Java Renaissance might not be just hype. We all know the stories of Java being brought into to do heavy-lifting on successful sites written on other languages, a key target for the Java renaissance .
Java has had a less precipitous journey on the Tiobe index although it has still declined over the same period, not quite losing half, and again seeming to gain a bounce recently.
Whilst I only have UK data to show it, the recovery in the contract market, a leading indicator, may be a sign that Bob Lee’s Java Renaissance is bearing fruit:
I think Java had a strength that enabled it to stage a comeback on the server: CPU bound workloads. Python, Ruby, and especially Node.JS work well with I/O bound workloads. But all use the process model to scale. If your workload is CPU bound there can be advantages to using a vm like the JVM (or the CLR) to scale. This is famously the issue that hit sites like Twitter, pushing them to bring the JVM in from the cold.
Where did all the people go?
First, let’s kill the persistent belief that all the C# developers of any quality are now F# developers. There is not a realistic demand for F# developers in the UK.
or the US:
Anecdotally, many of my F# friends are doing Scala, to at least work in an FP language.
Yes, F# is loved, and many in the .NET community are passionate about it. It polls well on the most loved ratings for Stack Overflow’s developer survey:
But its numbers are so small, that any F# revolution is a way out. It needs time, and I believe that it needs time that only C# can buy it, to gain more sizable market share. Right now, it is too dependent on the health of the .NET ecosystem to survive alone.
F# is not your parachute. For now.
If not F#, Scala? Well Scala has some noticeable numbers by comparison at 6% of UK programming jobs
This may account for some drift, particularly away from Java, in the UK or the US. And again this would match anecdotal evidence for where people go on the backend, when leaving C# behind. But I don’t think we can account for all the movement there.
Scala is not much more significant than Ruby, which has also seen steady growth over them same period though it doesn’t have the same kind of traction on Tiobe as even Java or C#.
Although Ruby may have peaked according to the Tiobe trend line:
Still, although there are less Ruby or Scala jobs that ASP.NET, both can still argue that their trend for jobs is up, not down.
Both of these pale behind Python, which has as many jobs as both of them combined. In the war of Python vs. Ruby, Python can declare victory:
Python also shows growth on Tiobe, though even it may be past its peak:
But the elephant in the room is JavaScript. It has an irresistible climb in UK job data:
Of course the problem with JavaScript is that it is hard to know if this represents front-end jobs (which might be paired with C#), or back end jobs. However, the Stack Overflow Developer Survey suggests that JavaScript is dominating both front and backend workflows:
But even if we call backend as just Node.js jobs (and ignore terms like Fullstack) the curve is steep (and it probably represents more backend jobs than Python, despite Python’s higher overall number).
And again, anecdotally, I hear evidence of many picking up Node.js, easily accessible for full-stack developers who have used it on the front-end, for use on the backend.
Of course, that is still less developers than ASP.NET, but the trend is up, not down. And it is only just less developers than ASP.NET on contract positions
On Tiobe JavaScript has a complex picture, moving in and out of popularity, although its trend is still up
It’s worth talking about Go, Elixir and Clojure briefly perhaps. They’re certainly the ‘cool kids on the block’ for many outside the CLR. In many ways they hold a position similar to F# for the .NET community. The smart kids like to talk about them.
Clojure is to the JVM as F# is to the CLR. It’s functional and lots of smart folks I respect like the language, but as of today, its not really hitting high enough numbers to explain much of the diaspora.
Elixir is the destination for Ruby smart kids, but again, it has almost no users. Again it doesn’t tell much of our story.
Go is notable because a lot of infrastructure of note is developed on it and anecdotally the Node.JS + Go stack, with Go microservices fronted by a Node.JS web server is increasingly seen by many I know as: ‘the new stack’. It’s numbers place it in a different ball park to Clojure and Elixir, and F#, though still way behind the big boys:
I think Go is ‘one to watch’ though as it is far easier for Java and C# devs to transition to Go over Clojure and F#.
Overall though it’s not as simple, I suspect, as saying that the backend roles went to one ‘new’ language. Some went to JavaScript, some went to Python, some went to Ruby and others to Scala. Some of these languages are better at one part of that stack than another. But on the backend, mostly over the last four to five years, C# is bleeding out on the server.
The Reasons for the Fall
So why has C# declined?
I think the answer is complex.
Let’s see what we know.
On the server, Unix
First let’s look at the argument that because Linux has won on the server, .NET is declining because it’s primary host platform is declining.
Why has Linux won? Because as increasingly apps target Cloud Native scenarios, Linux has better tooling for Infrastructure as Code, Containers etc.
Windows feels to be perpetually in catch-up mode on those areas. (Although as we move towards Containers and Serverless, the OS providing your app’s host may matter less and less).
Indeed, I know of a number of enterprises that declared that they would only provision Unix on the server, condemning C# to client scenarios.
Under this theory .NET Core, an x-platform solution is the answer to the loss of C# jobs. Supporting Linux should arrest, or even reverse that decline by nullifying any platform risk.
Sadly, whilst it’s definitely important, I don’t think that platform risk cannot explain the decline completely — because Java which has always been able to target Unix experienced a decline over the same period. There is competition in Unix space.
I’m very glad .NET will be x-platform and I can host on the best available environment, be that Windows or Unix. It is certainly likely that the gap between Java and C# can be partially explained by the JVM being available on Unix.
It’s necessary to be on Unix, to ship .NET core, for server-side relevancy. Of course.
But it’s not enough to explain the losses on its own.
The Cathderal and the Bazaar
Next let’s address ourselves to the argument that the world has shifted to OSS ecosystems and the domination of the .NET ecosystem by Microsoft has never allowed that ecosystem room to breathe and grow.
By comparison to Java, .NET often lags in tooling for server side architecture, and is, as on the OS, always playing catchup.
Under this argument working to improve .NETs OSS ecosystem would be the solution. If we OSS the runtime and framework we might encourage participation in OSS across the community. If MS worked with OSS projects instead of replacing them the ecosystem would no longer fear the 500lbs gorilla in the room.
I welcome MS stepping into the OSS space, making it easier to contribute to, access, and understand the runtime. I welcome a desire to work with the community instead of in replacement of it. I welcome their embracing that space having long been a user of OSS projects and a contributor.
But, whilst a healthy OSS ecosystem is very possibly another key advantage for Java, again explaining its greater market share, the decline of Java shows that you have to have the right stack — one that supports today’s scenarios. All the OSS in the world won’t help you, if your platform is being eclipsed for how people want to work today.
Is a healthy ecosystem necessary for server-side relevancy. Of course.
But it has to keep-adapting, keep evolving, keep innovating.
OSS in this context has as much to do with agility as much as openness The two-year turnaround of traditional enterprise software development improvements no longer keeps pace. Your platform will be seen as bureaucratic and left to rot if that is your approach.
Speed of delivery of your platform is everything. Dropping every 6 months is too little, too late.
If no one is building out OSS on your platform to better support emerging patterns and practices, you may well end up tagged as ‘enterprise’ and your future rapidly becomes managed decline and legacy.
So it’s not enough for C# to have OSS, it has to have OSS relevant to today’s scenarios with an active community pushing it forward at pace.
A Language is a Map of the World
Given the similarity between C# and Java, are the languages themselves at fault? Have newer, better, paradigms appeared.
Functions, Functions
Have you noticed that a lot of the smart kids have switched from an OO to FP paradigm? Is it simply that people are switching away from the OO paradigm in these languages to F#, Clojure, or Scala.
As noted above, the evidence for a significant drift to F# or Clojure is poor. They might be tomorrow’s alternatives, but they are not today’s competitors. The number of open F# positions is just not significant enough to represent a change in the predominant .NET language. The number of Clojure positions is yet to represent a change in the dominant paradigm for the JVM either.
Have they all gone to Scala? There has been an impact, certainly.
But the growth of non FP platforms such as Python suggest it is not simply FP that is drawing people away from OO. And the rise of Go suggests there is still life in OO language paradigms.
A lot of folks I know are fantastic cheerleaders for functional. In some scenarios (finance) it is clearly a better tool for the job. Having a functional language a runtime is an important for the health of that runtime. It has a diverse offering that supports different scenarios.
It may even own tomorrow, I think that is very early to call. Good OO might make a come back too. Anecdotally, I know more folks who class themselves as F# or Clojure fans, than I know folks working in F# or Clojure. We are not at the tipping point.
But they don’t have enough traction to explain why C# (or Java) has declined on the server. C# has often borrowed features from F#, as have Java. Where that makes sense, it can make sense to do so,as a living language is better than a dead one.
Dynamic vs. Static
When we look at some of the languages that Java and C# bled out to, there is a significant role call of dynamic languages. JavaScript, Python and Ruby all gained traction and many of the Top 10 Tiobe dynamic languages are dynamic. Are dynamic languages just more popular than statically typed languages because they have less-ceremony, more flexibility and and a ‘wrist-friendly’ approach.
Personally, I find this debate interesting. When I started my career many moons ago I cut my teeth on Dbase family languages. Now, admittedly, this was pre-TDD, but the number of type related bugs, and the amount of type related documentation to try and defeat them meant we were rushed gladly into the embrace of a statically typed language (C++ in my case) even though that language had more ceremony and was arguably less productive.
I suspect this static vs dynamic flip-flopping, making choices on static vs. dynamic, has as much to do with the problems of first building and then maintaining a large code base and looking for a ‘silver bullet’ for the problems we hit last time, than anything else. Took to long to build: use dynamic next time; to hard to maintain: use static next time.
I might argue that the resurgence of interest in type systems through languages such as F# and Haskell is partially a reaction to maintaining large codebases in languages like C# and Java. I’m not sure it is the right solution either, like most silver bullets.
TDD might well be a better answer for me.
I suspect that for language longevity there may be an argument for optional typing, but I don’t believe that this is why C# and Java declined.
Complexity
I have long-argued that a key problem for both Java and .NET is their ‘barrier to entry’.
The .NET Framework is now 15 years old and over the years has accreted many features that we now rarely use, for example .NET Remoting, or WebForms. This large surface area is intimidating to newcomers. This results in much of the anecdotal feeling that Java and C# are archaic languages that it is difficult to start working with. Time and time again in software we see the lure of the new, drawing developers away from established languages and frameworks, to ones that seem to do less, or at best are better in a small range of scenarios, but don’t seem a genuine competitor to a more established language. The attraction of new languages is less to do with the ‘new shiny’, or problems with the existing set of languages and frameworks, but the high surface area that you have to understand if you get in at the ground floor of the older ones.
I often liken this problem to a TV show or sequence of movies with a complex back story. It is hard to start watching Game of Thrones half-way-through or X-Men. Of course the presence of box sets etc. mean folks can catch up, just as they do when learning C# or Java, but a new franchise removes the need to do that. Hollywood loves the ‘reboot’ as a result. We can reset the clock and let new folks in, whilst still hopefully keeping the fans interested.
I believe that to reduce complexity we need to trim the surface area of the .NET Framework, so that we can focus on supporting key server side scenarios.
C# supports many scenarios: desktop, games, server-side and mobile. Most developers don’t do all four, and only a few do more than one. By creating frameworks to lessen the surface are developers in those scenarios need to understand, you can lower the barrier to entry and increase adoption. The language and core of the framework remain the same, but different deployment scenarios only contain the dependencies they need. This also allows you to target training and documentation to the scenarios developers targeting those environments require. We can clarify how the framework can be used to solve common problems.
It is also important to remember that the range of available OSS frameworks needs to balance both the desire of many to have winners that reduce the number of frameworks a newcomer might have to learn to feel productive with the language, and be open enough to new entrants the people feel that they could contribute something, and have a chance of that contribution being recognized for its value. Both a chaotic mass of OSS options, with no clear direction on ‘what most people are using’, and a inability for people to make contributions that can be recognized, can be fatal. It is a hard line to walk at times.
Community
When people write ‘leaving x’ posts on blogs, one aspect they often draw attention to is the community. ‘This community is so much more open to new ideas,’ we here or ‘This community is so much better at sharing knowledge.’
Established languages can become closed echo-chambers. Not because the participants desire that, but because they don’t actively try to recruit people into their language, having already established their base. This presents a number of dangers:
- Lack of new entrants means that the community will eventually decline as losses to attrition are not replaced.
- The ‘establishment’ that rewards existing experts over new voices can seem elitist and unwelcoming, resulting in a barrier to new entrants into the language and community
- This is particularly problematic if coupled with a complex accretion of libraries in the framework that new entrants have to master before ‘proving’ themselves.
- It is also reinforced by closed, private communities such as slack channels that are hard to discover for new entrants
- This reinforces the notion that the community is inward-looking, an echo chamber of ideas
- The rewarding of an establishment over new entrants creates a resistance to change, as influence is often based on knowledge of existing frameworks or approaches. Preservation of ‘authority’ often means resistance to change, as that in itself is perceived to undermine that authority obtained from expertise in older approaches.
- As a result, the language declines into legacy scenarios because both its adherents reject new approaches and outsiders perceive the language as one that cannot tackle new idea, or the community is unwelcoming to them.
- Diversity is often absent as the community is unwelcoming.
Languages with welcoming communities grow, those without are doomed to decline. A great example is the Python community’s commitment to diversity: https://wiki.python.org/moin/DiversityInPython and it may be that it owes much of its growth to attempts to address the problems of diversity. Personally, I have always found the Python community exceptionally welcoming.
C# will not survive unless it is pro-active in encouraging diversity in the industry.
Conclusions
I don’t think any one factor is a smoking gun, but I think we could infer all those factors, combined together create the circumstance for C#s decline in server-side scenarios.
Speed or Scale
So why did Java decline (and then bounce) and why is C# still declining?
It is interesting to review Bob Lee’s assertion that in 2011 what drew people away from Java was that people left for Rails because struts was so inferior to Rails as a web platform. Rails solved problems people had with Java development, and so it crossed the chasm from early adopters to the mainstream. Those problems related to the lack of an MVC framework and CLI infrastucture, which had created problems of over-complexity, but most of all increased build times for Java projects over Rails competitors.
Rails was a more productive development experience.
But later, as the successful sites had to scale, Java has the better libraries (and runtime) to help teams meet web scale demands.
So one simple answer is people switched to more productive languages and frameworks, for their development scenarios.
If true, Bob’s insight would suggest that there are two reasons for choosing a server-side platform: speed of initial delivery and then if successful the need to scale.
Indeed, public information tells us that Twitter started in Rails but move to Java to scale. Uber started in Node.JS and Python, but is increasingly switching to Go.
It is possible that no language really suits both use cases well right now.
And certainly the ability to offer both speed (time-to-market) and scale (library, and runtime, even type system) would be something of a Holy Grail. Because this would let you use one language on your server side development from inception to high scale.
Of course this was the sweet-spot that Java and C# tried to hit. It might still be possible.
What scenarios do you need to think about server-side, today. If you wanted to create a compelling platform to provide for speed and scale, what would it need to cover.
One big trend that may work against many of the incumbents is the shift to Single Page Applications and Mobile First which has moved server-side development away from rendering Html to fulfilling the role of an API server.
Another big trend is the move away from monoliths to microservices, helping organizations to scale.
Finally, the growth of infrastucture on demand, be it containers, PAAS, or Serverless creates whole new paradigms for server side developers.
Yesterday’s framework is not tomorrow’s framework. Of course that disruption creates the opportunity for a .NET Renaissance, provided it is not squandered fighting yesterday’s battles with a focuse on legacy concerns.
I would opt for a set of priorities often described as Cloud Native, coupled with the productivity of good tooling:
- Microservices
- API First
- Web and Worker Roles
- Run in Containers, PAAS, and Serverless environments
- CLI Infrastructure
You could summarize this as: target Cloud Native.
If you are willing to lead generate yourself with Pivotal you can pick up a Gartner report from Pivotal that discusses the health of the application server market and predicts its decline with the shift to Cloud Native; specifically they predict the demise of Java EE in favor of frameworks like Play, Spring Boot and DropWizard, as the latter provide better support for Cloud Native approaches. https://content.pivotal.io/analyst-reports/gartner-market-guide-for-application-platforms I suspect that a very similar fate awaits ASP.NET hosted in IIS. The future is self-hosted processes, listening on ports, scaling out via the process model.
A couple of key quotes from that report that resonate with me:
“Design all new applications to be cloud-native, regardless of whether or not you plan to deploy them in the cloud: Shift from three-tier to MASA and adopt miniservices or microservices to improve agility and scalability.”
and
“ Give preference to vendors that articulate a platform strategy that supports modern application requirements, such as public, private and hybrid cloud deployment; in-memory computing; multichannel clients; microservices; event processing; continuous delivery and API management.”
The recovery of Java might suggest that having the right products in the OSS space, to deal with web-scale workloads could be a reason for Java’s successful renaissance. Java was able to move sites forward to scale, that no longer needed speed. That was Bob Lee’s proposition back in 2011, and whilst it is hard to find data to prove it, I consider it possible.
Of course, Java’s domination of this space is not guaranteed. But many see Go as replacing Java for those scenarios where Java stepped in to help web scale companies as Cloud Native scenarios predominate.
As a static, compiled language, C# needs to consider itself a competitor to Go and Java for scale. And it needs to meet Cloud Native scenarios to position itself on the server.
I believe that the folks who talk about ‘good’ .NET jobs are interested in their framework competing in those scenarios.
The Renaissance
The Good News
The good news is that I believe the ASP.NET team really get this.
The plays they have made with .NET Core would seem to address many of the key issues:
- Runs on Unix
- Fast
- Good CLI infrastructure and support for rapid development
- Reduced Complexity of Libraries, removing redundant code
- Support for API First development
- Support for 12-Factor App, approaches to development (including self-hosted, scale out via process model, etc.)
Another key piece of good news here is that as we paradigm shift from microservices to functions (serverless) C# is well-placed. Along with Python, Java, and JavaScript it tends to be available on all the key IAAS platforms. This is a real opportunity for the C# community to make waves, by becoming a strong contributor to these ideas and this space. Of course more languages will join, increasing the competition, so the time to start talking about this is now.
Of course, this first-mover advantage is down to .NET Core running in x-platform containers. In those environments there is little need to wait for the next release of .NET Core as the libraries you cannot support on that version, are mostly about your existing stacks and not about new development under this paradigm.
In addition as well as Docker and Serverless scenarios, tools like Service Fabric support PAAS models and .NET Core.
We need to talk about Workers
But although this shows that we many options for worker roles, as well as web roles, I worry that we tend to talk more about the web role for Server Side .NET and forget the worker role. We need to change that dialogue. Even if your API is in Node.JS, it is tough to write your microservices in that platform, due to its lack of typing etc. Java developers have already picked up on delivering microservices as a key sweet-spot, and I believe it is for C# too.
Now we can use web frameworks like Nancy or ASP.NET there but we don’t have Netty or Spring Boot equivalents, and that doesn’t handle event-driven scenarios. We do have a good OSS ecosystem (Service Fabric, Orleans, Akka.NET, Brighter, Mass Transit, NServiceBus, et al) that we can leverage, but we don’t talk in the community about these enough.
We need to talk about Cloud Native
Overall we don’t talk about Cloud Native enough. It feels like a work used outside the C# community. When I submit talks on 12-Factor Apps or other Cloud Native topics to conferences in response to CFPs, many have never heard of that practice.
I would like to change that.
We need to see more people talking about what it takes to run in these environments, and how .NET integrates with the kind of tools you need in microservice deployments such as application performance monitoring, log repositories??, tracing tools?? etc.
We need to talk about what we see as our versions of Netty, Play, DropWizard, or Spring Boot. We need to talk about whether we have new paradigms that are better than these.
These areas are particularly attractive for the community because MS has less of a dominant footprint here; there is real opportunity for the community to step up and have an impact.
Who knows, we could even innovate and drive new approaches.
But only if we step up and start having the conversation about how we build applications in C# for this Cloud Native future.
We have the ability to create a .NET Renaissance around tomorrow’s workloads, but only if, as a community we begin to hold conversations about the challenges of building applications for tomorrow’s scenarios and of expanding our community to include new voices, not just the same old faces and people.
We need to talk about Community
As outlined above we need to talk about re-energizing our community and bringing in new faces and greater diversity
We have tagged this move toward a new .NET Renaissance as the work of a new Alt.NET movement. Why?
Alt.NET was about opening the eyes of C# developers to many of the patterns and practices happening around them, and keeping C# developers relevant: TDD, Agile, SOLID, Design Patterns, POCO, DDD, CQRS & ES et al. Alt.NET was about keeping the community relevant. I believe that it succeeded, and there was a first .NET Renaissance at that time, given that those practices are now the new normal for most C# developers working today.
This rebirth of Alt.NET then is about opening the eyes of C# developers to the new conversations that they should understand. What asked the other day I suggested I felt the pillars would be Unix, Cloud Native, Diversity. C# developers today need to be having conversations around those ideas, and working to bring them into fruition in our community.
We need to go faster
The uncertainty surrounding the .NET Core project has damaged the ‘move fast’ paradigm of OSS. Whilst ASP.NET Core 1.1 is very usable, the announcements on .NET Core have deferred uptake and libraries being ported. Perhaps worse, the opportunity for new OSS projects to take up the strain of projects that relied on older APIs that were no longer part of the surface area, and thus provide room for new projects, ideas, and people to breathe was squandered on folks ‘waiting for the next release’.
If C# is seen as being tied to a platform with slow release schedules, it will be perceived, as Java has been, as bureaucratic. That no longer cuts it in server-side development.
Move fast and break things
MS has an adimirable commitment to supporting its existing customers. But it also has only so many resources to go around. A focus on supporing existing customers diverts effot away from frameworks that support Cloud Native scenarios to ones that support older models of delivery (ASP.NET MVC, WCF, etc.).
One reason that new languages and frameworks are so attractive is that unburdened by the past, they can move faster. This is not simply ’the new shiny’. In this model, Go gains advantages over Java and C# because it has less legacy code to divert its energy.
So we do need to worry less about legacy scenarios if we want to remain competitive — they will join us when they can — and embrace moving fast and breaking things.
That is harder for Microsoft, which has commitments to its existing customers, so that is where the community has an opportunity to put a shoulder to the wheel to produce new frameworks to fill the gaps.
Why bother?
Of course one question is: why bother? Why not just write Go or Python and leaven C# behind?
Well, I would always recommend that you are polyglot and think about your skill set today, tomorrow, and the day after tomorrow. The future is uncertain, and having expertise in a wider range of languages and platforms helps cushion you against shocks.
So get a parachute, in case C# continues to decline. Python is mine, and I’m likely to add Go to the mix. Don’t bet on C# being there tomorrow, just because it was there today. We started by putting our Acceptance Tests into Python, then rolling it out for some API scenarios. It’s easy to make little changes to hedge your bets.
And using different tools also helps you cross-pollinate. You can bring back ideas back from those environments into C#. The Alt.NET was always about looking up and out, seeing what the wider community was talking about, and involving the .NET community in those discussions. The early Alt.NET movement learned a lot from the Ruby on Rails community. Who will we learn from this time?
But given that many of us have skills in C#, and the size of the installed base means C# is still useful today. And that pool of talent could be taking their skills forward into tomorrow.
But to do that the community has to start talking about server side scenarios for C# that let it compete with Java and Go.
I like C#, its a great language, and I have met some fantastic people working in that language. C# could be just as useful tomorrow, or the day after. But first we need have a conversation about what C#, .NET, and the community look like tomorrow, if we chose to move forward.
There are good people out there, trying to make a difference. I believe that the ASP.NET team, for example, is making a real attempt to tackle this problem. But they need us to step up. And the community needs to own this, not MS. Let’s own taking C# forward.
Alt.NET Redux
In the UK Alt.NET was inspiring to many, and it helped pushed their careers forward, further than they might have imagined. It championed a new type of community, open and participatory, that eschewed ‘word from on high’ to community action.
I would like to see that excitement once again. And as part of that I would like to see a new generation of Alt.NET developers pushing forward, taking us toward the new normal, not just the same old (white male) faces.
We have much to learn
I think that could be worth the fight.
One last shout, before closing time.
