Quando eu vi de quem era o post, ja fui direto em up, nem li ainda, mas ja digo · jeffcarlosbd

Quando eu vi de quem era o post, ja fui direto em up, nem li ainda, mas ja digo logo, isso daqui é um conhecimento extremamente importante, independente da sua expertise, linguagem, framework, patterns que aplicar, ter esse conhecimento profundo de como computadores funcionam, entender como a sua linguagem se relaciona com essa parte do computador vai te fazer ser um dev melhor!

Edit: post incrível @maniero!

Meus 50 centavos dedicados a Jrs:

No post ele fala sobre "pilha de chamadas de funções", sempre que você executa uma função, ela é adiconada na pilha pro computador saber o que está sendo feito no momento e se dentro dessa função for executada outra função, essa segunda é adiconada numa nova "sessão" em cima da pilha, se a segunda executar uma terceira, cria nova "sessão" dessa forma vai "empilhando" (conceitualmente) as chamadas por cima e por fim se uma função do topo entrar em excessão (erro) o computador vai anotando "descendo" a pilha procurando uma tratativa (como um try catch), caso nao encontre, esse erro é lançado para visualização e é assim que é gerada aquelas varias linhas no erro indicando todo o caminho trilhado.
Ele fala que o "garbage collector" é responsável por desalocar memoria, ele faz isso contando quantas vezes determinada parte da memória é utilizada, quando chega a 0, ele disponibiliza essa parte para uso. ou seja, sabe quando você faz uma querie no banco, pega aquela infinidade linhas pra gerar um relatório CSV? se você nao trabalhar bem essa parte, ficara com dados duplicados na memória (o resultado da querie E a string CSV montada), entao o ideal é retornar isso o quanto antes ao cliente, para que o garbage collector veja que esses dados nao estão sendo utilizados e libere memória, mas se for necessário alguma outra ação após gerar o relatório, como disparar notificações de que o relatório ficou pronto ou cachear esse CSV... é interessante que procure na doc da sua linguagem como indicar ao computador que pode "matar" pelomenos a variável que guarda o resultado da querie (já que costuma servir somente para gerar o CSV).
Mesmo linguagens de alto nivel como JS e Python que automatizam essas questoes de memória, possuem formas de limpar e tratar a memoria utilizada, pesquise e pode não parecer mas essas linguagens também possuem ponteiros que podem te ajudar a ser mais eficiente em muitos casos, inclusive quando voce cria um Objeto no javascript, a variável nao guarda os dados do objeto diretamente, ela guarda o ponteiro indicando onde os dados estão na memória. inclusive em objetos que possuem outros objetos são basicamente listas de ponteiros indicando onde cada pedaço está, por essa razão que não dá para comparar diretamente dois objetos como fazemos com variáveis numéricas ou de strings.

Obrigado, foi muito fofo da sua parte.

A explicação de pilha de chamada está correta, mas lembre-se que nem todas as linguagens possuem exceções, e algumas podem ter de uma forma um pouco diferente do descrito.

O GC explicado aí é um reference count, que algumas pessoas nem chamam de garbage collector (eu chamo), em geral a maioria das vezes quando se fala de GC está falando de um não determinístico, um rastreador, que funciona de uma forma diferente, com vantagens e desvantagens. Tem mais informações no link na postagem principal. Poucas linguagens, especialmente as mais mainstream, trabalham com um GC de refcount. Em muitas linguagens não se recomenda chamar o tracing GC manualmente, apesar de poder e ser útil em casos bem específicos.

Para scripts realmente a preocupação com memória não é relevante, mas quando se faz aplicações, entender bem o funcionamento dela pode ajudar muito a tomar certas decisões. Se a pessoa vai fazer aplicações complexas, que são pesadas, e não querem se preocupar com a memória, por isso escolheu uma linguagem de script, pode ter sido uma decisão equivocada.