Back to blog

Language is an implementation detail

2013-12-23 - Posted in Uncategorized Posted by:

by Rinat Abdullin
Although everything about working at HPC is interesting, last week was quite peculiar on its own. There was an interesting discussion about use of async pub-sub messaging for communications between micro-services. That’s what Fred George does, for example, with event messages. However, command messages have their own value as well, due to the behaviour that we associate with them (only one message handler could deal with command messages, unlike event messages, where there could be 0 or more). Yet, after a bit of discussions with Tomas, we discovered that introduction of command messaging breaks our nice decoupling with regards to ease of upgrades, experimenting or continuous delivery. Besides, if needed, you can always implement command messing within the boundaries of the service. This is possible, since we place a clear separation between high-level design decisions (the ones which talk about how mServices should behave and communicate) and implementation details (which govern how mServices should be actually implemented). For example, here are some high-level design decisions:
  • Protocol for communications – JSON/HTML over HTTP in our case
  • Messaging semantics – async pub/sub in our case
  • Approaches for deployments, versioning them and experimenting with them – rapid iterations, A/B testing, using business metrics as the driver
  • Set of recommended languages and technologies – still evaluating (see below)
  • Design and development priorities – creating fun environment to work in, keeping things real, small and simple
  • Execution and hosting constraints – Linux, clustered in our own DC with geo-replication
  • Additional constraints – low latency and failure-tolerant
Curiously enough, we are still iterating through the suitable languages for implementing new version of HPC (while also addressing the design and domain questions). So for this week I’m going to spend more time learning Haskell (in addition to doing dives into Erlang and Golang during the previous weeks). At the same point, our rewrite will probably start in .NET with micro-services design. Reason for that being – .NET, despite it’s shortcomings and costs is the language where we all would be most productive and could release initial versions fast. This is crucial for gaining real-world feedback for evolving the system. Then, as the need arise, micro-services will be rewritten in one of more Linux-friendly functional languages to:
  • Save on licensing costs.
  • Improve performance and reduce latency.
  • Make code more simple and concise.
  • Stand on the shoulders of giants, reusing ecosystem and communities of languages we choose.
By the way, if you listen to Fred George, he mentions that at one point 150000 lines of Java code where rewritten in 4000 lines of Closure code (or so). Based on my exposure to Haskell so far, I’d say that C# is almost as verbose as Java in this sense.
In other words, languages are treated just like implementation details of the system. Even though there are some recommendations and guidelines, developers should be able to choose the tool they want in order to get the job done in the most efficient way.
by Rinat Abdullin

4 Comments

Ali 6 years ago

“4000 lines of Closure”. Type -> Clojure.

Reply

Ali 6 years ago

“4000 lines of Closure”. Typo -> Clojure

Reply

Kaarel 6 years ago

With regard to lines of code. I don’t object the clame in large. What my own experience has shown at least some (not all by any means) of the conciseness of functional languages comes from using very short function names. Java anc C# I think are deliberately more verbose there. And many of the nice line saving functions often seem something that, granted are not part of the out of the box framework experience, but a simple extension method effort.

Still I’m keen to hear your summary few months down the line how the mService prototype architecture in C# compares to your chosen technology. Been looking at Scala lately (have mental injuries with Haskell from uni days).

Reply

Rinat Abdullin 6 years ago

Kaarel, Java and C# definitely have their own merits (especially as imperative languages). However, we explicitly wanted to avoid them. Personal language fatigue and usability/cost characteristics (compared to other languages) being among the factors.

We plan to talk about that topic more. I hope to be able to share experiences comparing my previous C# life to the new territories we explore.

Reply

Leave a Reply

Your email address will not be published. Required fields are marked *