We're moving from Java to Kotlin with our Microservice Stack (Spring Boot) because it is excellently supported by framework and tools and the learning curve is not very steep Kotlin is way more straightforward and convenient to use while providing less boilerplate and more strictness, which finally leads to better code, which is more readable, maintainable and less error-prone. We especially like Kotlin's (functional) data structures, which are, e.g. compared to Scala, easier to understand and don't require deep knowledge in functional programming.

A developer and project manager from our team X says the following about our use of Rails at i22:

"We use Rails to build stable and flexible backend systems. Rails is extremely good for managing data structures and quickly setting up new systems. It is the perfect base for most use cases."

I asked the same Team X member why the team prefers to work with Ruby on Rails, rather than Python and Django:

"Because Python is a scripting language and from my point of view not suitable for building stable web services. Python is for me rather good for scripts and fast small tools. Not for stable business applications. And if I want it fast I prefer Go."

I am working in the domain of big data and machine learning. I am helping companies with bringing their machine learning models to the production. In many projects there is a tendency to port Python, PySpark code to Scala and Scala Spark.

This yields to longer time to market and a lot of mistakes due to necessity to understand and re-write the code. Also many libraries/apis that data scientists/machine learning practitioners use are not available in jvm ecosystem.

Simply, refactoring (if necessary) and organising the code of the data scientists by following best practices of software development is less error prone and faster comparing to re-write in Scala.

Pipeline orchestration tools such as Luigi/Airflow is python native and fits well to this picture.

I have heard some arguments against Python such as, it is slow, or it is hard to maintain due to its dynamically typed language. However cost/benefit of time consumed porting python code to java/scala alone would be enough as a counter-argument. ML pipelines rarerly contains a lot of code (if that is not the case, such as complex domain and significant amount of code, then scala would be a better fit).

In terms of performance, I did not see any issues with Python. It is not the fastest runtime around but ML applications are rarely time-critical (majority of them is batch based).

I still prefer Scala for developing APIs and for applications where the domain contains complex logic.

I was considering focusing on learning RoR and looking for a work that uses those techs.

After some investigation, I decided to stay with C# .NET:

• It is more requested on job positions (7 to 1 in my personal searches average).

• It's been around for longer.

• it has better documentation and community.

• One of Ruby advantages (its amazing community gems, that allows to quickly build parts of your systems by merely putting together third party components) gets quite complicated to use and maintain in huge applications, where building and reusing your own components may become a better approach.

• Rail's front end support is starting to waver.

• C# .NET code is far easier to understand, debug and maintain. Although certainly not easier to learn from scratch.

• Though Rails has an excellent programming speed, C# tends to get the upper hand in long term projects.

I would avise to stick to rails when building small projects, and switching to C# for more long term ones.

Opinions are welcome!

We have a lot of experience in JavaScript, writing our services in NodeJS allows developers to transition to the back end without any friction, without having to learn a new language. There is also the option to write services in TypeScript, which adds an expressive type layer. The semi-shared ecosystem between front and back end is nice as well, though specifically NodeJS libraries sometimes suffer in quality, compared to other major languages.

As for why we didn't pick the other languages, most of it comes down to "personal preference" and historically grown code bases, but let's do some post-hoc deduction:

Go is a practical choice, reasonably easy to learn, but until we find performance issues with our NodeJS stack, there is simply no reason to switch. The benefits of using NodeJS so far outweigh those of picking Go. This might change in the future.

PHP is a language we're still using in big parts of our system, and are still sometimes writing new code in. Modern PHP has fixed some of its issues, and probably has the fastest development cycle time, but it suffers around modelling complex asynchronous tasks, and (on a personal note) lack of support for writing in a functional style.

We don't use Python, Elixir or Ruby, mostly because of personal preference and for historic reasons.

Rust, though I personally love and use it in my projects, would require us to specifically hire for that, as the learning curve is quite steep. Its web ecosystem is OK by now (see https://www.arewewebyet.org/), but in my opinion, it is still no where near that of the other web languages. In other words, we are not willing to pay the price for playing this innovation card.

Haskell, as with Rust, I personally adore, but is simply too esoteric for us. There are problem domains where it shines, ours is not one of them.

In 2015 as Xelex Digital was paving a new technology path, moving from ASP.NET web services and web applications, we knew that we wanted to move to a more modular decoupled base of applications centered around REST APIs.

To that end we spent several months studying API design patterns and decided to use our own adaptation of CRUD, specifically a SCRUD pattern that elevates query params to a more central role via the Search action.

Once we nailed down the API design pattern it was time to decide what language(s) our new APIs would be built upon. Our team has always been driven by the right tool for the job rather than what we know best. That said, in balancing practicality we chose to focus on 3 options that our team had deep experience with and knew the pros and cons of.

For us it came down to C#, JavaScript, and Ruby. At the time we owned our infrastructure, racks in cages, that were all loaded with Windows. We were also at a point that we were using that infrastructure to it's fullest and could not afford additional servers running Linux. That's a long way of saying we decided against Ruby as it doesn't play nice on Windows.

That left us with two options. We went a very unconventional route for deciding between the two. We built MVP APIs on both. The interfaces were identical and interchangeable. What we found was easily quantifiable differences.

We were able to iterate on our Node based APIs much more rapidly than we were our C# APIs. For us this was owed to the community coupled with the extremely dynamic nature of JS. There were tradeoffs we considered, latency was (acceptably) higher on requests to our Node APIs. No strong types to protect us from ourselves, but we've rarely found that to be an issue.

As such we decided to commit resources to our Node APIs and push it out as the core brain of our new system. We haven't looked back since. It has consistently met our needs, scaling with us, getting better with time as continually pour into and expand our capabilities.

In December we successfully flipped around half a billion monthly API requests from our Ruby on Rails application to some new Python 3 applications. Our Head of Engineering has written a great article as to why we decided to transition from Ruby on Rails to Python 3! Read more about it in the link below.

We needed to incorporate Big Data Framework for data stream analysis, specifically Apache Spark / Apache Storm. The three options of languages were most suitable for the job - Python, Java, Scala.

The winner was Python for the top of the class, high-performance data analysis libraries (NumPy, Pandas) written in C, quick learning curve, quick prototyping allowance, and a great connection with other future tools for machine learning as Tensorflow.

The whole code was shorter & more readable which made it easier to develop and maintain.

When I was evaluating languages to write this app in, I considered either Python or JavaScript at the time. I find Ruby very pleasant to read and write, and the Ruby community has built out a wide variety of test tools and approaches, helping e deliver better software faster. Along with Rails, and the Ruby-first Heroku support, this was an easy decision.