Hating is maybe a big word but I think there is a big problem with configuration files. Especially the ones in a .NET project/solution.
There is too much noise in a configuration file these days and the xml-style enhances the clutter.
Because we work with more then one project these days and every project has there responsibility, the ‘top-level’ project needs to copy all the important parts. If you forget one bit or change it to something wrong you are in trouble and you need to scan all possible config files. The horror :-) I understand the meaning of this all and I understand that we need to have a configuration file that you can change at runtime. Better then doing everything in the registry as it used to be. But don’t forget this configuration file system exist more then 10 years. It was there from the beginning. Maybe it is dated and we need to think of something new, something better, something improved.
My solution should be some sort of DSL that do the trick, with the DevOps that are coming up it should be something to consider. I was thinking something in the style of Powershell. From the shell you can retrieve and inject new settings in your application. Better then inventing a new DSL language that makes it worse then it is.
The second method that I am thinking of is instead of injecting settings is translating settings. From a certain language to the configuration files we have today.
In a way how Coffeescript is build up, or better how Sass is made. A scripting language that interprets into configuration files and vice versa. Why vice versa? Well there is a lot of entries in the configuration files that is generated, the settings from the entity diagram, WCF bindings, …
And we integrate it in Visual Studio 2012 (maybe with backwards support for 2010) with the necessary additions.
I was building a referential architecture in .NET to support my future projects. I do this every year with the latest Microsoft technologies and sometimes near future technologies. I do this for two reasons, one to get to know those technologies and understand thoroughly what features are available. The second reason is to see what we can do with it in the context of current/future projects. A software architect needs to know what is available and see it with his/her own eyes. Not only by reading articles and take it for granted.
While I was doing this I saw a presentation on InfoQ from Joe Armstrong (one of the creators of Erlang). That brought me to the idea, why don’t I write an application server in Erlang from scratch with workflow and communication (net.tcp, net.http, net.pipe) capabilities and let them compete to each other and learn from it.
Before I could start I needed to refresh my Erlang knowledge. As I am a Pragmatic Programmers fan and bought a lot of their back-catalog I started to reread Programming Erlang from Joe Armstrong.
In chapter 8 there was an interesting exercise (8.11.2 to be precise). Not only interesting but also challenging.
The exercise is the following: Write a ring benchmark. Create N processes in a ring. Send a message round in the ring M times so that a total of N * M messages get sent. Time how long this takes for different values of N and M.
My first attempt to write this was a total failure to say the least. I tried to spawn a process and that process spawns the following and so on until I got N processes. That was not that easy as I thought. And maybe I was thinking too much in C#/C++.
You can see here my attempt:
After struggling on that attempt I thought I need to do it differently. The next attempt was to create the N processes and connect them together as a belt.
That worked out better.
That was of-course with one round of message passing. Refactored and with the multiple message passing it gives the following:
The clasp is the starting point. The head. You see it creates first the head/clasp and then I create the shackles and connect them to the previous one. At the end I close the ring (the last shackle I connect to the head so we get a ring). When that is done I send the message through the head. I keep the message cycles left in Max. The hardest part is that you need to think for each process individually. Joe uses persons but I preferred to picture it as a chain, with shackles and clasps.
Now I need to find a way to time this. Ofcourse we are not working sequential so we need to time it at start and when the receive is in the last case.
For my curiosity and as it is mentioned in the book, I am going to attempt the same exercise in C#, C++ and Clojure. The three languages that are on the top 3 spots of my usage list. I will posts my results on Gist and in this blog of-course.
Feel free to comment. Feel free to pass me your solution or make it in your preferred language and proof me it is better to implement my application server in your preferred language.
They send me a reaction, with why I choose to go for Erlang. This is the answer that I send them back.
I think you can define several important things about Erlang:
- Processes belong to the Erlang programming language and not the operating system.
- Erlang is a pure message passing and concurrency-oriented language.
- Erlang has no mutable data structures. That means no locks. The problem you have to deal with in Python, Ruby, C#.
- Processes live on their own and do have their own memory queue. Creating or spawning an extra process doesn’t cost an extra effort.
You can do all these in theory in Python, Ruby, Java or C# but you need to set the restrictions and you need to be sure there are no locks or shared memory.
A framework could do the trick, but at what cost and where is the proof that it is going to work?
And what I find the most important feature, or say cool feature is the auto-update. Update your code while the processes are still running.
Am I an Erlang advocate? I try not to be. I try to be a true polyglot, using the right tool/language for the required feature set. But that is in my opinion not enough, you need to have the right mindset too. You need to think differently when you work with so many cores.
At the end to have a correct answer on your question, I need to know the requirements, the feature set and the roadmap to build the correct architecture and so the ‘correct’ answer.
I remember seeing this headline on Hacker News. It was to attract for a job offer of some sort.
I send them an email saying, “I would write it with Erlang.”
As I am trying to be a true polyglot a better answer should be, “It depends on the requirements and the given architecture”.
I don’t have 10000 cores to my availability but working with that question I will try to get the most out of the 16 cores that I have.
With the focus on the application server, all those cores will be dedicated to that layer.
I see these days that the application server is still build up in a sequential way. I am thinking how can I get the most out of the available cores,
especially when I am designing the application server. I am working on that and will post my findings on this blog.