How do you select the best object-oriented language for your project?

Don't choose a language, choose an ecosystem. Who cares about the syntax of the language or whether it supports single or multiple inheritance. None of that is going to move the needle. https://josvisser.substack.com/p/its-the-community-stupid

I worked on many different projects, both military and civilian. Rarely did I have a choice of programming language. And I never had a choice of platform (hardware.) Knew many proficient programmers but few who had a grasp of the whole system. They could program a routine (object) but not the program itself.

Project type, resources, and skill sets mostly preselect programming language for the project. Most business application development teams do not have C++ experts, and non-mainstream language selection generally creates more problems than fast-track solution development. Scala is one example where people selected it as a functional alternative to Java and regretted it later. Some of the well-known patterns for Project's first choice of programming languages are Data science and POC/utility projects --------> Python Microservices Projects----------> Java, C# Mobile and front-end development ------> JS, Typescript Cloud Native high-performance apps ----> Go, Lang,

I almost agree with Jos Visser. Ecosystem must come first, of that there can be no doubt. With that satisfied, one may still have choices to make. C++ is magnificent, but C# gets a lot of jobs done quite well and with way less fuss. Availability and interest of engineers to go with a particular language does matter. I would call that "ecosystem-adjacent"

Performance and efficiency are crucial factors when selecting an object-oriented language for your project. Consider the language's runtime performance, memory management capabilities, and concurrency support. Look for a language that optimizes execution speed and minimizes resource usage. Additionally, evaluate the availability of profiling and optimization tools. Choosing a language that can efficiently handle the project's requirements will ensure optimal performance, responsiveness, and scalability. It's important to strike a balance between performance and other considerations to achieve the desired outcomes for your project.

"compiled languages [...] require more time and effort to compile and debug" I don't find this accurate. I would agree there's more waiting around to compile, and more effort to work out the kinks. As far as debugging goes, one could argue that strongly-typed compiled languages result in less bugs, so less debugging. I agree interpreted languages are more flexible. They are not more portable though. You can be 100% certain that C++ is going to take that crown. The argument gets much murkier when you get into library availability, however.

There is a broader consideration that stems this point and the subsequent one on popularity. What is the long term vision? If you are selecting a language, you’re clearly planning to author something. Is this something going to grow into a full company employing lots of other developers? Or will it be a solo maintainer project? If it’s the former, consider how you’d find, hire and train people in this language. If it has a large thriving market it will be much easier to hire. But as with anything in software it’s balance. Don’t pick something just because it has a large market. Is the market growing, shrinking, stable? Balance the ability to hire and grow the project with the other factors to maximise the potential later!

This is spot on. I will just add that as Jos V rightly pointed out earlier, ecosystem is a major priority. Don't hang your shingle on something new and unsupported unless you are very comfortable with a lot of added engineering mysteries.

Using a language that has a big following can be a smart move. More people using it means more tools, resources, and developers to help when you're stuck. Plus, it can't hurt to know a language that a lot of jobs are asking for. But remember, just because it's popular doesn't mean it's always the best fit. You have to look at what you're working on, how the language works for that, and how comfortable you are using it. Don't just follow the crowd; think about what works best for you and your project.

Agreed. Additionally, never hesitate to ask a trusted expert for their opinion. We're talking foundational architectural choices here. Might have a big impact!

Picking a programming language is a lot like picking the right tool for the job. If the tool is so complicated that it slows you down, it's time to think about picking something else. Your programming language should help you get your work done quicker, not hold you back. If it's causing delays, it might be worth reconsidering what language you're using.

I like to consider the skills and experience of the team as well. There are no hard and fast rules, but often it's better to pick a language that your team is already familiar with, unless there's a compelling reason to do otherwise, such as creating a greenfield project. The type of project can sometimes dictate or narrow down the list as well.

There is no mention of 3rd party formal/accessible support. There is mention of "community" and popularity but that does not always translate to support. Also, are there acquisition and running costs associated with each platform?

Project Requirements: Understand the specific requirements of your project. Consider factors such as the type of application you're building, its complexity, scalability needs, performance requirements, and integration with existing systems or frameworks. Determine if the project involves specific domain-specific features or constraints. Long-term Considerations: Consider the long-term viability and evolution of the language. Evaluate the language's roadmap, community support, and release cycles. Consider the language's backward compatibility and ability to adapt to future trends and requirements.