Python has become the most popular language for machine learning right now since almost all machine learning tools provide service for this language, and it is really to use since it has many build-in objects like Hashtable. In C, you need to implement everything by yourself.

C++ is one of the most popular programming languages in graphics. It has many fancy libraries like eigen to help us process matrix. I have many previous projects about graphics based on C++ and this time, we also need to deal with graphics since we need to analyze movements of the human body. C++ has much more advantages than Java. C++ uses only compiler, whereas Java uses compiler and interpreter in both. C++ supports both operator overloading and method overloading whereas Java only supports method overloading. C++ supports manual object management with the help of new and delete keywords whereas Java has built-in automatic garbage collection.

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.

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.

As a personal research project I wanted to add post-quantum crypto KEM (key encapsulation) algorithms and new symmetric crypto session algorithms to openssh. I found the openssh code and its channel/context management extremely complex.

Concurrently, I was learning Go. It occurred to me that Go's excellent standard library, including crypto libraries, plus its much safer memory model and string/buffer handling would be better suited to a secure remote shell solution. So I started from scratch, writing a clean-room Go-based solution, without regard for ssh compatibility. Interactive and token-based login, secure copy and tunnels.

Of course, it needs a proper security audit for side channel attacks, protocol vulnerabilities and so on -- but I was impressed by how much simpler a client-server application with crypto and complex terminal handling was in Go.

$ sloc openssh-portable 
  Languages  Files    Code  Comment  Blank   Total  CodeLns
      Total    502  112982    14327  15705  143014   100.0%
          C    389  105938    13349  14416  133703    93.5%
      Shell     92    6118      937   1129    8184     5.7%
       Make     16     468       37    131     636     0.4%
        AWK      1     363        0      7     370     0.3%
        C++      3      79        4     18     101     0.1%
       Conf      1      16        0      4      20     0.0%
$ sloc xs
  Languages  Files  Code  Comment  Blank  Total  CodeLns
      Total     34  3658     1231    655   5544   100.0%
         Go     19  3230     1199    507   4936    89.0%
   Markdown      2   181        0     76    257     4.6%
       Make      7   148        4     50    202     3.6%
       YAML      1    39        0      5     44     0.8%
       Text      1    30        0      7     37     0.7%
     Modula      1    16        0      2     18     0.3%
      Shell      3    14       28      8     50     0.9%

https://gogs.blitter.com/RLabs/xs