Executando verificação de segurança...
2

Gostaria de dar meus 2 centavos de contribuição nesta conversa, como desenvolvedor PHP de longa data e certa experiência em Java Spring Boot.

A maior questão não está na linguagem. Ela, se não tiver requisitos bem específicos que seja imperativo que faça X, tanto faz a escolha no final das contas... desde que o projeto seja embasado em METODOLOGIAS CAMPEÃS, que evitem usar estratégias dinâmicas para resolver problemas estáticos (um dos maiores gargalos dentro do servidor é o acesso ao DB, o que deve ser atrasado até o último instante e só para dados que devem vir do DB para diminuir o cu$to da requisição... deve-se pensar em usar dados normalizados para as transações e denormalizados e segregados noutro DB para relatórios sobre dados que não serão mais alterados). Até aqui não entrou nenhuma linguagem! Mas a lista não para nos exemplos listados.

O que se tem de ter em mente: OWASP Top-10, respostas em X ms. Aqui também não entra linguagem.

Já na "esteira do desenvolvimento", o que mais conta são as metodologias mais eficientes para resolver as mesmas coisas de sempre: o tal do CRUD: Inserts, Selects e Update (sendo o delete mais incomum).

Entre o recebimento de uma requisição/post e a execução da SQL, tem um processamento. É neste intervalo que entram as diversas abordagen METODOLÓGICAS que farão a diferença! É aqui de se deve por a atenção e tentar descobrir o máximo possível de formas como empresas resolvem e aprimoram a sua atividade.

Se querem realmente aprender algo, aqui é que está a coisa... por isso, blog posts e cursos não são recomendados para "aumentar a bagagem", pois são rasos nesse aspecto por focarem no básico.

Por isso, a melhor estratégia para aprender METODOLOGIAS em repositórios de códigos que estejam em produção. Por exemplo, vejam o repositório do ótimo sistema https://rallly.co/pt-BR (uma alternativa ao Dooble para encontrar o melhor dia/horário de reunião para várias pessoas). Quem tiver mais dicas de sistemas em produção, cujo cógigo esteja disponibilizado, compartilha o repositório com a gente! ;o)

Mais dois pontos para finalizar: normalmente, muitas vezes nós não escolhemos a linguagem. Elas já vem no "pacote de vaga". Ser especialista só em uma linguagem é restringir em muito as possibilidades, seja de empregos, seja na prestação de serviços a clientes... a menos que isso seja uma escolha consciente, como quem se especializa em iOS.

Deixo aqui o vídeo o Fábio Akita para destroçar nossas paixões: Sua Linguagem NÃO É Especial! (Parte 1).

Ampliando: neste outro link, o Fábio Akita tem 2 vídeos afirmando que a linguagem de programação NÃO é especial... e outros 2 perguntando se ela é especial: https://www.youtube.com/results?search_query=Sua+Linguagem+N%C3%83O+%C3%89+Especial!

Carregando publicação patrocinada...
2

Dentro da avaliação técnica eu concordo com tudo que foi dito, mas no escopo de negócio eu acredito que linguagem é não apenas importante, como a escolha correta (baseado em fatores mercadológicos), pode significar a vida de um negócio.

Pensando com a cabeça de um CTO ou até mesmo CEO de uma startup, se eu decidir iniciar um projeto com Javascript sei que em cada esquina vou encontrar mão de obra, e portanto, será mais "barato" escalar no longo prazo.

Se eu iniciar o mesmo projeto em Ruby, por exemplo, se minha empresa estiver longe dos grandes centros já posso esquecer a contratação presencial, e certamente o custo de manutenção será maior, chegando até o ponto da refatoração total para outra linguagem mais popular por falta de orçamento técnico.
Já vi acontecer, é caro, causa demissões e às vezes invibializa um projeto inteiro.

2

Você está correto, Heigler... e obrigado por ampliar o que eu resumi em uma oração (segunda oração de meu segundo parágrafo).

Basei-me mais pela proposição inicial, cujos requisitos são para atender a um projeto pessoal e não a uma requisito comercial e de considerável monta.

A linguagem deve ser adequada ao tamanho e requisitos do projeto.

Como foi citado o caso de uma starup, além da linguagem adequada, o que é uma pequena fração a ser considerada, temos também que abordar coisas como: Tornando sua App Web Mais Rápida! | 4 Técnicas de Otimização.

Agora, pensando em fazer o que o consultor/administrador de empresas Carlos Júlio fala: começar pequeno e crescer rápido, que em nossa área nos referimos em fazer algo que deve escalar, temos que ampliar o assunto indo mais na linha do vídeo A Forma Ideal de Projetos Web | Os 12 Fatores um compilado de The Twelve-Factor App.

Isso também pode ser conferido no artigo Engenharia de Software na Web: os 12 fatores, que descreve cada ponto.:

  1. Base de código
    • Uma base de código com rastreamento utilizando controle de versões, muitos deploys
  2. Dependências
    • Declare e isole as dependências explicitamente
  3. Configurações
    • Armazene as configurações no ambiente
  4. Serviços de Apoio
    • Trate os serviços de apoio como recursos anexados
  5. Construa, lance, execute
    • Separe estritamente os builds e execute em estágios
  6. Processos
    • Execute a aplicação como um ou mais processos que não armazenam estado
  7. Vínculo de Porta
    • Exporte serviços via vínculo de portas
  8. Concorrência
    • Escale através do modelo de processos
  9. Descartabilidade
    • Maximize robustez com inicialização rápida e desligamento gracioso
  10. Paridade entre desenvolvimento e produção
    • Mantenha o desenvolvimento, homologação e produção o mais similares possível
  11. Logs
    • Trate logs como fluxos de eventos
  12. Processos administrativos
    • Rode tarefas de administração/gestão em processos pontuais

Mais uma vez, vemos que a linguagem é só um item, dentre outras 12 estratégias.

Para entender mais, veja este "estudo de caso" Como fazer o Ingresso.com escalar? | Conceitos Intermediários de Web.