Na verdade, já seria difícil usar todos esses serviços, então ter MCP é uma grande vantagem.
Daqui para frente, se a manutenção da API continuar boa, acho que pode ser útil.

Embora o hardware da Apple seja excelente, o software é cheio de mecanismos feitos para manter o usuário na coleira.
Mesmo que você só queira fazer um app que você mesmo criou e compilou rodar apenas no seu próprio dispositivo, ainda precisa de uma assinatura de 100 dólares.

Se você é um desenvolvedor que usa apps open source pequenos ou médios e compila para uso próprio,
fazer jailbreak explorando vulnerabilidades e usar sideload nos dispositivos da Apple é menos prático do que simplesmente usar Android.

No nosso caso, o plantão era pago com metade do valor da hora normal, havia auxílio para telecomunicações, e o tempo de atendimento era considerado hora extra com adicional de 50%.

Tem uma turma do C# escondida aí no meio.

> Falando bem francamente, hoje em dia, para desenvolver em Java, não é exatamente necessário usar produtos da JetBrains

Essa parte... é um pouco difícil de concordar, sniff sniff...

[link removido] Parece que colocaram aqui a captura de tela da versão Android. Quanto mais eu uso, mais ele parece uma ferramenta curiosa. A comunidade também é bem animada e há muitos aspectos surpreendentes.

Com apenas o Emacs, dá para fazer de tudo. Recentemente até consegui instalar no Android, então é ótimo poder aproveitar no desktop exatamente os mesmos recursos. Estou me aprofundando bastante no tema de ferramentas de gestão do conhecimento no Emacs. Quando meu filho, que ainda está no jardim de infância, entrar no ensino fundamental, talvez nessa época eu já esteja fazendo lifelogging com Emacs haha. Como basta aprender uma única ferramenta, no longo prazo isso acaba reduzindo as preocupações.

[link removido]

Mas, se vocês simplesmente tivessem explicado aos usuários o princípio da ofuscação e obtido o consentimento deles com uma cláusula de isenção dizendo que isso poderia ser quebrado por determinados modelos, talvez nem tivesse sido necessário reembolsar; vocês realmente foram muito atenciosos com os usuários haha

Foi um texto que trouxe uma resposta para as reflexões que tenho tido ultimamente. Muito obrigado por compartilhar um texto tão bom.

Estou compilando e usando o lsp diretamente. Ao mudar para Go, dá para perceber claramente a redução no consumo de recursos.

Ultimamente, às vezes dá a impressão de que eles demitem gente e, como a manutenção ficou mais difícil, transformam isso em open source para jogar a responsabilidade em cima da comunidade.

Nossa, sensacional, finalmente...!!!

A MS é realmente incrível.

Hoje em dia, virou moda simplesmente migrar JS para Rust/Go para melhorar o desempenho

Nossa, incrível

Quando eu estava refatorando, acontecia bastante de a análise de código do lado do tsserver ficar lenta e o editor travar por completo; tomara que isso saia logo para nos libertar desse sofrimento.

Achei que muita gente estava fazendo isso sem nem pensar em structural typing.
Para reescrever em uma linguagem de nominal typing como C# ou Rust, seria preciso mudar demais a estrutura fundamental do projeto, então certamente não seria fácil.
Entre as linguagens que adotam structural typing, as únicas que provavelmente conseguiriam entregar desempenho superior ao ecossistema JavaScript existente seriam C++ ou Go, mas, considerando também a produtividade, não há alternativa.

Parece que produtos comerciais com suporte a múltiplos writes, como Oracle RAC ou DB2 pureScale, nem estão sendo considerados.

Uma fase vergonhosa em escala muito, muito grande...

Sinceramente, achei que isso não seria adicionado... vai dar uma nova vida a vários editores.