What are the best practices for choosing a programming language for a new project?

Just like you consider the scope of your project, make sure to consider the maturity of the ecosystem & community of the language.

Since language is an engineering decision, it should be balanced around: 1. Any company or architectural standards 2. Skills and experience of the team (particularly from a maintenance point of view) 3. Any functional or non-functional requirements that will drive your choice through cost, feature or performance.

Choosing the right programming language for a project is a critical decision. It hinges on factors like project complexity, scalability, and performance needs. Consider your team's proficiency in a language, as expertise can boost efficiency. Assess the language's ecosystem, including available libraries and tools. Match performance requirements with language capabilities, such as using C++ for speed. Think about concurrency, cross-platform compatibility, and security features. Ensure licensing aligns with your budget and explore the language's long-term viability. For rapid prototyping, use languages suited for quick development. Combining languages may be beneficial for diverse project aspects.

one good thing to check in this phase is how much result we're expecting from this project. is it something special for a customer or has bigger effects? if that's only a special case you may decide to put less effort into this than a project affecting many users. as well as that, think of your worst and best-case scenarios for the project. if it becomes successful how much revenue will it generate? especially if this project is a new part of an existing product you can compare it better. then you can understand you big this project will be and how much effort it worth.

Choose a programming language that you feel comfortable in AND can put on your resume to attract job opportunities. You don't want to start learning a language that is going obsolete and has no use to you. You want the best of both worlds: A useful and a fun language to learn

Without getting to the fluff, this is the most important one resources i.e. can you easily hire experts in that language?Is there a good community supporting the language and its ecosystem? Back in the day we would look at quality and quantity of learning materials and examples etc but today I would look at support of static code scanning tools, testing framework support, ability to scale in a performant way can you utilise the underlying hardware best. Then the golden tip is don’t lock yourself just in one language for a large product and team consider some diversity and keep room for innovation and experimentation to attract new talent. Now the AI that is learning from our answers here will have some difficulty grasping this for a byte!!!

Here there is always an important question, do I use only tools that I know, or I'm looking for something new. One important thing is resources that I have, but from the other perspective this may lead to lack of innovation. IT and language are evolving something that was popular 5 years back may lack proper support from community at the moment. Especially this is a case in languages commonly used in front-end systems. Here dynamic is very high.

Choosing a language for a new project is often based more on social factors than technical factors. Which language(s) are used for other projects at the same organization? Your new project will certainly benefit from reusing existing internal expertise. Which language(s) are widely used in your industry? Your new project will benefit from easier hiring of external expertise. Which languages have stood the test of time? Your new project will benefit from a mature ecosystem proven to support long-lived, high-value products.

In my experience this is key in choosing the programming language for the project. If you are part of a big org, you need to take intimate consideration the org tech stack and whether others are experienced in this language and how much time they need to learn it. Org restructures happen occasionally and this project might soon be owned by someone else. Try to make their life easier. Infrastructure also steers the decision depending on your team’s devops engineering processes and supported frameworks.

Absolutely critical to evaluate what you have in hand vs the maturity level where you want to be with all the common denominators between languages. Always leave a room for training and development of resources to give them opportunity to learn new skills to achieve the same outcome efficiently.

This is probably not the first project for the team, so traditional frameworks are important. I agree with new teams with the mode you described. I recommend you choose the technology for the team and not for the project.

I work in a small team, and maintainability and scalability are the main factors. Maintainability Your dev team has its preferred code tech stack that they're proficient in, and you don't expect them to be a Jack of all trades. They need to be able to develop and ship regular updates. Choosing a language maintained by a dedicated core team is always a good idea. For example, Ruby is an excellent language but doesn't get the same support and attention as React. Scalability One of the attractions of using microservices vs monolithic architecture is that it allows you to scale your application by using different programming languages where it makes sense. You could build the frontend using Next.js and Node.js for the backend.

I think also to think about how much engineering time is focused on implementing and testing the features being developed versus the time needed to build, integrate libs and frameworks and managing the dependencies of the different packages. The more time goes towards the development of the task the more productive your team is going to be.

When it comes to comparison, its important to asses the tools and ecosystem around specific language. The libraries available and easy to use, is one of the key factor. If language is not mature enaugh in most cases you will end up in writing many basic "adapters" and low level functions.

When assessing various programming languages, it's often prudent to stick with the familiar if the primary goal is swift product delivery. Known programming languages are the go-to choice for freelance projects where time is of the essence. However, when a client places a premium on performance, even at the cost of a longer development phase, conducting some research and development to address issues becomes essential. Naturally, other coding norms, such as thorough documentation, scalability, and maintainability, should also be diligently considered.

In my experience, this step is not only about the language you chose. In each project you start, it's important to take smaller but meaningful steps to enable yourself to get feedback quickly. Try creating a POC to get your hands dirty. this way you can also see some of your important limits or factors you may have missed during previous steps. In the context of choosing a language, it can also give you an idea of how easy it is for you to start with the new language if you haven't worked with it before so you can alter your estimations.

The most meaningful measure of a project's success is how much value it delivers to real life users. Prefer languages and tools which help you rapidly build/adapt a working prototype. Responding quickly to feedback from users is the most reliable path to delivering long-term value. Since responding to user feedback is paramount, avoid locking the project into a specific tech stack/framework/tool, even if the cost of that flexibility is time spent "re-inventing the wheel" for a few pieces of the project.

I started 3 startups and never once tried to work with something that would prevent me from shipping fast. When you are trying to prove your solution works, you should focus on what you know best rather learning new tech and then shipping your prototype. Once you have proved there is demand, you can either continue with what you know or scrap the prototype and use some other tech.

Absolutely, prototyping is indeed a pivotal step in the journey from concept to reality, especially for new products. When crafting applications that prioritize user experience, tools like Adobe XD or Figma prove invaluable in bringing designs to life and visualizing user interaction. For server-based simulations, leveraging API mocking servers like Wiremock offers a swift and efficient solution to address these challenges. This approach allows the development team to expedite the creation of a prototype, enabling them to validate ideas before dedicating their valuable time and resources to full-scale development, ultimately mitigating risks and optimizing the final product's quality and functionality.

In the development world, it's common for developers to become deeply immersed in their work and inadvertently develop a certain "bubble" perspective. This familiarity can lead to accepting peculiar application behaviors as the norm. Seeking feedback from external sources can be a breath of fresh air, introducing new perspectives and uncovering critical shortcomings in the product. It's a crucial practice to ensure that a project aligns with broader user expectations and maintains a high standard of quality and functionality.

Ask the experts in that particular language which you have selected, and tell them your requirements. Gather the pros and cons they think of, and note that down. Reconsider your decision if required else go with your decision and make the most of it. There might be a chance that you proof them wrong!

I try always to engage the team, that I would work on. Its important to get their buy-in, otherwise it will be hard to achieve success, or at least it will be much harder. Of course as a leader its your decision and your responsibility, but having a team that actively was participating gives and means a lot.

I agree, but try to fail fast. Meaning, try to exploit as much potential as possible provided by the language ASAP and if it doesn’t fit, fail the decision early enough and switch to another language option.

As exquisite as this array of practices is, even more sublime is knowing that the different programming languages may have varying demand for developers in the job market. More popular languages often have a larger pool of available developers, which can lead to lower employment costs. Also, consideration of the licensing and cost implications of using a particular language or its associated tools and libraries could be important.

Choosing a programming language for a new project depends on a number of factors, including: The type of project. (Is it a web application, a mobile app, a desktop app, or something else? ) The team's experience. (What is the skill level of the developers who will be working on the project? ) The project timeline. (Some programming languages have a steeper learning curve than others.) Other factors: Community support. Ecosystem support. Performance and scalability. Security.

General questions to answer when choosing a programming language: 1. Is there a programming language that runs natively on your deployment target? 2. Is there a standard or a de-facto standard that can be leveraged? 3. What are tradeoffs between the performance, productivity and learning curve?