Trabalho com javascript. E toda vez que alguém fala mal eu concordo antes de ver os argumentos. Depois vejo se mudo de opinião kkkk geralmente em 99.99% das vezes estão certos.
Javascript cada dia mais popular e mudando vidas em diversos cenários enquanto rustzinho já tem seu nicho mas neguinho quer fazer videi comparando js com Rust qual sentido nisso?
@@MarcusTorres-zv5cv Acredito que precise assistir o vídeo novamente. A ideia não foi ridicularizar nenhum lado. Foi mostrar como as coisas funcionam por baixo dos panos. No mundo real, você tem problemas reais e utiliza a tecnologia para resolve-los. No geral o cliente não está nem ai em qual linguagem de programação você utiliza ou o padrão de desenvolvimento modinha que viu em algum lugar, ele quer seu problema resolvido da melhor forma possível e mais barata possível. Hoje trabalho com javascript/typescript no frontend e .NET para backend e toda essa stack está resolvendo o problema para o cliente que trabalho. Se no futuro for avaliado que pra resolver o problema de algum cliente seja necessário usar Rust, Go, Excel, WordPress etc. Eu vou utilizar e resolver o problema kkkk no fim é isso o que importa.
video super necessário! Eu entendo a diferença mas gosto do trade off que o js traz, isso acaba nem sendo tão ruim já que a perca de performance acontece só quando o array precisa mudar de endereço, e ter isso auto gerenciado é muito bom, não me vejo fazendo side project em rust
Em quais casos rola essa troca de endereço? Pelo o que entendi apenas pelo vídeo, o JS instância algo que chama de array, mas não se comporta como um, certo? Então, na teoria, ele não faria essa troca de endereços, não?
@@felipefontenele648 até onde eu sei eu diria que a maioria das engine tem uma implementação da alocação dinamica onde cada item é guardado de forma contigua e quando o algoritmo vê a necessidade de aumento do array ele dobra o espaço disponivel copiando o valor para um endereço que tenha essa quantidade disponivel, por algum motivo (estudo passado) tenho comigo que essa é a implementação das engine ao invés de uma lista encadeada (que imagino que não seja possivel já que o acesso em uma linked list não é O(1)) Meu entendimento do video é que o javascript tem a alocação dinamica enquanto outras linguagens pedem que você aloque a memoria em um array normal
@@TeamEternalEmpire você está correto, arrays não espaçadas são salvas em blocos de memória contíguos com growth rate ao empurrar itens, que torna a inserção de itens em O(n), porém tem um detalhe, como o growth rate pode ser por exemplo 2x, em uma array de 100 elementos, ao inserir o elemento de n 101, a array irá ser movida para outro bloco com o dobro de espaço em tempo O(n) e depois ao adicionar o elemento de n 102 a operação voltará a ser O(1) novamente, o que muitos chamam de amortização da complexidade, é um conceito que depende do ponto de vista, se você olhar a complexidade considerando apenas uma inserção, o Big O pode ser O(1), se for considerar uma inserção em massa/concatenação, pode ser O(n), então depende muito do algoritmo e de o desenvolvedor saber se seria válido criar uma array com o construtor especificando o tamanho dela ou simplesmente deixar de forma dinâmica, na maioria dos casos para Javascript é um grande de tanto faz, ninguém vai utilizar javascript para processar dados de forma massiva e se existir alguém fazendo isso a pessoa é completamente insana ou não sabe o que está fazendo.
@@minimovzEt Blz, mas o processamento de dados com Js de forma massiva, não seria como vc mencionou, uma vez que podemos usar streams para ler os dados sob demanda invés de armazenar tudo de uma vez em memória. Não é justo fazer esse tipo de comparação, e isso seria feito em qualquer outra linguagem.
Isso acaba se tornando mais complexo quando consideramos a memória virtual, pois se o array ocupar duas ou mais páginas de memória, nada garante que será linear na memória física (e também pode ser alocado no disco se o SO tiver swap). Não sei se existe algum alocador de memória que consegue garantir linearidade na memória física, pois poderia ser até ruim se o computador estiver com a memória muito fragmentada (em alguns casos poderia causar um OOM com o uso de RAM em 50%, por exemplo). Até a memória do computador é uma abstração 🤯.
Não cheguei a olhar o v8 (base do chromium/nodejs, e escrito em C++), mas duvido que eles implementem arrays como linked list, a razão pra ser lento é que, por ser um código que precisa de runtime, GC, e interpretador, isso fica bem custoso, mas ainda assim, é bem rápido num panorama geral, logicamente, que se comparado com linguagens que geram binários, a conversa já muda. Sobre a afirmação de push, se for seguir essa “regrinha”, ele não seria um array, poderia ser considerado um slice/vector/list, dependendo da lang q tu ta usando. Mas a propriedade de leitura O(1) se mantem, exemplo: se eu alocar (int)*LenArray, e chamar isso de capacity. Logicamente, cada push seria o equivalente a mudar posicao do ultimo iterador para +1. E então, a cada vez q size == cap (ou alguma heurística), vc aloca outro array, copia, e muda o lugar aonde o ponteiro aponta.
@@daishes uma list, imagino que vcs estejam se referindo à uma estrutura na qual o tempo de acesso seria O(n) no caso do acesso do n-1 elemento, uma vez que teria que dar um loop e mudar o iterator. Mas pelo q pesquisei por alto, n parece ser o caso th-cam.com/video/PtZuzwZjYbM/w-d-xo.htmlsi=yrByiuY7r4_I4EOW Pelo que entendi, por padrão usa um std::vector, e aí, se criar “buracos” demais (se usar push e pop, isso n vai acontecer), ele muda para um map/hashmap, o que por sua vez, aumenta o tempo de acesso por causa da função de hash. Uma vez que muda o tipo, ele fica mais lento, sendo impossível melhorar novamente. Então, se vc usar arrays “igual gente decente” (com TS/jsdoc/ou simplesmente n meter o louco), vc vai ter um desempenho legal, pois no pior cenário, vc iria ter um std::vector, aonde ao fazer array.push({name: “Foo”}); o tempo de acesso de array[0].name, seria o equivalente à (*(arrPtr+pos)).name (seria O(1), com algumas instruções a mais). E se vc for um coda-fofo, e fazer algo do tipo array[100]=2.5; array.push(“name”). Ai vira hashmap e deixa de ser o(1) e ai vai depender de como foi implementado a função de hash e o número de colisões, mas chuta um O(log n). No geral, é um bocado de otimização pra fazer a gambiarra, que ngm gosta, funcionar decentemente. De qualquer jeito, foi bem massa esse estudo. Odeio ainda mais JS, mas admiro o espírito de gambiarra do time de dev
@@daishes Não é uma lista.... Listas não teriam esse acesso rapído, no Javascript são arrays concatenados, que podem tem um aumento de tamanho considerável quando necessário. Ou seja, novos arrays são criados e contatenados
Na real que o array do Javascript é um Dynamic Array, ou seja, o Javascript inicia um array statico com o tamanho necessário para alocar os itens passados ao instanciar o array, e depois automaticamente realoca o array inteiro para um novo endereço de memória se necessário. Geralmente as implementações de array dinâmico dobram a quantidade de itens nessa realocação, mas o Javascript aumenta em 50% + 16 itens. Então, se vc inicia um array vazio, este é um array estático com tamanho 0. Ao fazer um push, esse array é realocado para um novo endereço de memória, agora com tamanho 17. Se vc inserir itens o suficiente para encher esse array, o mesmo será realocado para um novo endereço de memória, agora com tamanho 43. Em resumo, o javascript te entrega um array mais alto nivel, no qual você nao precisa se preocupar com realocação. Em contrapartida, este array não vai ser tão eficiente quanto um array estático pq as realocações são feitas em O(n). Na minha opinião é um tradeoff justo :D
alguem de JS lúcido ! JS tem mt magia lá na V8, a galera que diz senior nunca nem lê as especificações e defende com unhas e dentes. parabéns pelo conteudo
Só um detalhe, essa parte de object, array, e outros tipos do Javascript, é tudo pela V8, Os runtimes (Node / Bun / Deno) só adiciona ou altera implementações que não estão na especificação da V8 ou que não seria compatível fora do Browser. ( FS, Fetch, Child Process,etc..)
Legal, gostei pra caramba de aprender isso, eu pesava que mais cedo ou mais tarde eu iria ter que entender, mas não imaginei que conseguiria entender isso do nada assim tão rápido. Esses dias estava tentando entender a diferença entre List e Array no Kotlin, e pronto! tá ai a diferença! Vlw Galego!
Muito bom, nunca usei rust e agora fiquei com uma pulga atrás da orelha enorme para saber como funciona uma implementação de uma lista ou array onde o número de elementos é desconhecido
Não sei como é a implementação em outras linguagens. Mas no próprio Rust tem o tipo Vec que o tamanho não precisa ser informado de antecipadamente. A leitura, escrita e remoção no Vec é O(1). Já a inserção é O(1) armotizado. O Vec tem um tamanho e uma capacidade. O tamanho é quantos elementos o Vec tem, e a capacidade é quantos bytes alocado o Vec tem na memória de forma contígua. Para acessar e inserir, é facil ver porque a operação é O(1). Romover é só diminuir o tamanho sem diminuir a capacidade (apesar de que diminuir os bytes alocados também é O(1). Já a inserção, pode ser que estoure a capacidade. Nesse caso é necessário alocar um espaço contíguo maior e copiar tudo de um espaço para o outro. O que faz a inserção ser O(1) amortizado, é que novo espaço alocado é mais que um elemento maior, garantimdo que as parte das próximas inserções sejam O(1), e de forma que se olhar para várias inserções como um todo, o preço de aumentar a capacidade é dividida com as inserções O(1), de modo que a inserção a inserção seja O(1) amortizada. === Aliás lista em python consegue suprir o papel de varias estruturas de dados. Funciona bem como array, pilha, lista heterogênea e lista recursiva. Mas não é uma boa fila nem deque.
voce poderia fazer um video explicando como que o comando "sorted" em python funciona de baixo dos panos ? tenho curiosidade em saber qual lógica ela utiliza
Eu teria que estudar a fundo como funciona o js por baixo dos panos, mas js é uma linguagem de mais alto nível que o c, por exemplo, então será que quando criamos a lista e aumentamos o tamanho dela, por baixo dos panos o js não está apagando o array anterior e criando um novo?
se tu quiser muito muito usar array puro no lugar do Object Array, tem os TypedArrays Minha sensação é que sempre tem jeito de otimizar o js pra ter performance, só que demanda um esforço maior, tu pode ir pelo complexo e performático ou só fazer teu projetinho de boas com um let arr = [] e ter essas duas opções me parece mó gostosin mano...
@@dhanielr Mas o que falta pra ser puro, tem tamanho pré definido e datatype também, imagino que na conversão pra C++ ele acabe alocando isso na memória da maneira correta ou do contrário ele perde o sentido. Tu sabe como funciona ele por baixo dos panos?
@@lucaslevandoski2946 oq de fato falta pra ser puro é ser um array em memória em si. Ele carrega lógica em conjunto com a implementação nativa do array. Por isso que na própria documentação do TypedArrays, eles se referem como um "Array-like object".
Lembro da diferença quando estudei java, no java precisa definir o tamanho e tipo do array (só não fazer um pré preenchimento), mas realmente, chamar de array não faz sentido. Em Dart segue a mesma idéia de python: existem listas, não arrays, justamente por conta dessa flexibilidade
Não tenho certeza ,mas se me lembro bem o array em javascript ele faz o(1) para pegar só o primeiro e o último elemento. O resto ele sai passando pelos endereços de memória. Exemplo: se quiser achar a terceiro elemento ele vai no primeiro que aponta o espaço de memória do segundo, olha o segundo que aponta o espaço de memória do terceiro.
Eu tinha percebido a um tempo até tbm em outras langs q. "Mesmo que se chame array, não significa que seja um array como em C". É só problema com escolha de palavras, até porque se for analisar o inglês ainda está certo chamar de array, só não vai ser um array padrão C. Inclusive minha mente buga quando vejo algo em inglês tipo série e eles usam a palavras "array" para algo fora da computação.
Então é por isso que em C você pode acabar sobre-escrevendo a memória? Porque C não se importa se no campo,.digamos, 0xDEADBEEF, já tenha coisa guardada e escreve coisa lá mesmo assim? WTF
Uma pergunta, em C++ conseguimos criar uma array sem um tamanho pré-definido, isso a torna ou não uma lista ou uma gambiarra (sou iniciante em c++, não manjo tanto)
Gambiarra é um nome forte para o que os arrays de js são. Js usa o conceito que algumas linguagens como chamam de array list ou vector. Que nada mais é do que um array que tem uma certa capacidade e ao dar push, se a capacidade não puder suportar o número de itens, ele aloca outro espaço continuo de memória maior que o original e realoca os itens para lá, adicionando o novo no final.
Comparar Javascript que é uma linguagem interpretada criada para coisas pequenas com rust que é uma linguagem compilada feita para coisas grandes é completamente desfundamentado. Claro que rust é melhor a gerir memória, javascript foi criado para fazer piscar coisas no DOM não para gerir memória, até porque um script JS quanto mais tempo ele demora a executar pior fica a memória. Concordo com os argumentos do vídeo mas acho que era mais justa a comparação entre por exemplo c++ e rust ou java e rust, por exemplo.
Por isso eu tenho uma relação de amor e ódio com o javascript,porque eu concordo que o javascript tem gambiarras,mas ao mesmo tempo tu consegue fazer tudo nele,sem contar que é mais prático pois tem o backend e o frontend junto,de qualquer maneira nenhuma linguagem é perfeita e sim concordo com você que o javascript tem uns "improvisos" mas mesmo assim eu amo programas em javascript por ser prático. De qualquer maneira ótima aula e analogia.
Meu caro, achei que vc ia falar mal do JS por falar igual a maioria dos criadores de conteúdo tech. Virou moda falar mal de JS, mas todo mundo usa, não programando, mas usa. Vídeo incrível, parabéns.
Descobri isso recentemente em java, quando fui adicionar mais dados no array em não consegui por que era fixo o seu tamanho, diferente do Javascript que podemos dar um push 😂😂
No PHP a definição do array segue os mesmos moldes e não há limites de alocação depois de instanciado (claro que irá ter o limite fisico ou o definido na configuração). Nesse caso podemos dizer que no PHP também não é um array de verdade ?
@@marcelsantee1809 mas pelo menos o termo arrayList deixa aceitavel, é uma lista de arrays, nao tem problema ele ter tamanho mutavel nesse caso porque a lista encadeada é mutavel
Javascript não é transpilado pra c++. A V8 é escrita sim em c++, mas não significa que ela pega o teu código JS e transforma em C++, são coisas diferentes.
@@Eduardoxlord Quem executa é A V8, que é escrita em c++, e vc ainda tem dúvida de quem tá alocando recursos e organizando a estrutura dos objetos? kkkkk
@@inosuke3626 Eu não tenho dúvida nenhuma, a dúvida aqui é só sua. O javascript NÃO é transpilado para c++, a V8 é escrita em c++ para interpretar linha a linha do JS, mas ela não traduz a tua linha em js para c++, na verdade se não me engano ela trabalha com ECMA e WebAssembly, no final transformando em binário na arquitetura do sistema que está rodando, entendeu? A lógica do array continua sendo algo como List, é isso que dá o dinamismo nesse caso. Ela não pega o teu array da linha x e transforma no array do c++, entendeu?
A parada é que geralmente estamos lidando com arrays dinamicos (principalmente em js) onde não sabemos nem o tipo e nem a largura que esse array pode ter kkk
então o problema é só o nome? porque ter que definir tamanho e tipo de uma lista pra dados totalmente dinâmicos no JavaScript não faz nem sentido kkk javascript é bom até pra gerar "conteudo" pra galera kkk
![[UNCUT] The Loyal Pin ปิ่นภักดิ์ EP.6 (2/4)](http://i.ytimg.com/vi/GgeGQOP10RQ/mqdefault.jpg)
Trabalho com javascript. E toda vez que alguém fala mal eu concordo antes de ver os argumentos. Depois vejo se mudo de opinião kkkk geralmente em 99.99% das vezes estão certos.
bem isso kkkk javascript é terra de nimguem kkkk
exatamente kkkkkkkkkkk
Javascript cada dia mais popular e mudando vidas em diversos cenários enquanto rustzinho já tem seu nicho mas neguinho quer fazer videi comparando js com Rust qual sentido nisso?
@@MarcusTorres-zv5cv Acredito que precise assistir o vídeo novamente. A ideia não foi ridicularizar nenhum lado. Foi mostrar como as coisas funcionam por baixo dos panos. No mundo real, você tem problemas reais e utiliza a tecnologia para resolve-los. No geral o cliente não está nem ai em qual linguagem de programação você utiliza ou o padrão de desenvolvimento modinha que viu em algum lugar, ele quer seu problema resolvido da melhor forma possível e mais barata possível.
Hoje trabalho com javascript/typescript no frontend e .NET para backend e toda essa stack está resolvendo o problema para o cliente que trabalho. Se no futuro for avaliado que pra resolver o problema de algum cliente seja necessário usar Rust, Go, Excel, WordPress etc. Eu vou utilizar e resolver o problema kkkk no fim é isso o que importa.
@@MarcusTorres-zv5cvmudando vidas. Tô estudando a 3 anos essa bosta e até agora nada de mudança
Augusto. Gosto muito do sua jornada em passar conceitos básicos de programação. Parabéns mano.
video super necessário!
Eu entendo a diferença mas gosto do trade off que o js traz, isso acaba nem sendo tão ruim já que a perca de performance acontece só quando o array precisa mudar de endereço, e ter isso auto gerenciado é muito bom, não me vejo fazendo side project em rust
Em quais casos rola essa troca de endereço? Pelo o que entendi apenas pelo vídeo, o JS instância algo que chama de array, mas não se comporta como um, certo? Então, na teoria, ele não faria essa troca de endereços, não?
@@felipefontenele648exatamente
@@felipefontenele648 até onde eu sei eu diria que a maioria das engine tem uma implementação da alocação dinamica onde cada item é guardado de forma contigua e quando o algoritmo vê a necessidade de aumento do array ele dobra o espaço disponivel copiando o valor para um endereço que tenha essa quantidade disponivel, por algum motivo (estudo passado) tenho comigo que essa é a implementação das engine ao invés de uma lista encadeada (que imagino que não seja possivel já que o acesso em uma linked list não é O(1))
Meu entendimento do video é que o javascript tem a alocação dinamica enquanto outras linguagens pedem que você aloque a memoria em um array normal
@@TeamEternalEmpire você está correto, arrays não espaçadas são salvas em blocos de memória contíguos com growth rate ao empurrar itens, que torna a inserção de itens em O(n), porém tem um detalhe, como o growth rate pode ser por exemplo 2x, em uma array de 100 elementos, ao inserir o elemento de n 101, a array irá ser movida para outro bloco com o dobro de espaço em tempo O(n) e depois ao adicionar o elemento de n 102 a operação voltará a ser O(1) novamente, o que muitos chamam de amortização da complexidade, é um conceito que depende do ponto de vista, se você olhar a complexidade considerando apenas uma inserção, o Big O pode ser O(1), se for considerar uma inserção em massa/concatenação, pode ser O(n), então depende muito do algoritmo e de o desenvolvedor saber se seria válido criar uma array com o construtor especificando o tamanho dela ou simplesmente deixar de forma dinâmica, na maioria dos casos para Javascript é um grande de tanto faz, ninguém vai utilizar javascript para processar dados de forma massiva e se existir alguém fazendo isso a pessoa é completamente insana ou não sabe o que está fazendo.
@@minimovzEt Blz, mas o processamento de dados com Js de forma massiva, não seria como vc mencionou, uma vez que podemos usar streams para ler os dados sob demanda invés de armazenar tudo de uma vez em memória. Não é justo fazer esse tipo de comparação, e isso seria feito em qualquer outra linguagem.
cara, muito bom !
Sempre explicando bem simples mas com muita profundidade!
Isso acaba se tornando mais complexo quando consideramos a memória virtual, pois se o array ocupar duas ou mais páginas de memória, nada garante que será linear na memória física (e também pode ser alocado no disco se o SO tiver swap). Não sei se existe algum alocador de memória que consegue garantir linearidade na memória física, pois poderia ser até ruim se o computador estiver com a memória muito fragmentada (em alguns casos poderia causar um OOM com o uso de RAM em 50%, por exemplo).
Até a memória do computador é uma abstração 🤯.
Não cheguei a olhar o v8 (base do chromium/nodejs, e escrito em C++), mas duvido que eles implementem arrays como linked list, a razão pra ser lento é que, por ser um código que precisa de runtime, GC, e interpretador, isso fica bem custoso, mas ainda assim, é bem rápido num panorama geral, logicamente, que se comparado com linguagens que geram binários, a conversa já muda.
Sobre a afirmação de push, se for seguir essa “regrinha”, ele não seria um array, poderia ser considerado um slice/vector/list, dependendo da lang q tu ta usando. Mas a propriedade de leitura O(1) se mantem, exemplo: se eu alocar (int)*LenArray, e chamar isso de capacity. Logicamente, cada push seria o equivalente a mudar posicao do ultimo iterador para +1. E então, a cada vez q size == cap (ou alguma heurística), vc aloca outro array, copia, e muda o lugar aonde o ponteiro aponta.
Provavelmente a implementação do Javascript é uma list msm.
@@daishes uma list, imagino que vcs estejam se referindo à uma estrutura na qual o tempo de acesso seria O(n) no caso do acesso do n-1 elemento, uma vez que teria que dar um loop e mudar o iterator. Mas pelo q pesquisei por alto, n parece ser o caso
th-cam.com/video/PtZuzwZjYbM/w-d-xo.htmlsi=yrByiuY7r4_I4EOW
Pelo que entendi, por padrão usa um std::vector, e aí, se criar “buracos” demais (se usar push e pop, isso n vai acontecer), ele muda para um map/hashmap, o que por sua vez, aumenta o tempo de acesso por causa da função de hash. Uma vez que muda o tipo, ele fica mais lento, sendo impossível melhorar novamente.
Então, se vc usar arrays “igual gente decente” (com TS/jsdoc/ou simplesmente n meter o louco), vc vai ter um desempenho legal, pois no pior cenário, vc iria ter um std::vector, aonde ao fazer array.push({name: “Foo”}); o tempo de acesso de array[0].name, seria o equivalente à (*(arrPtr+pos)).name (seria O(1), com algumas instruções a mais).
E se vc for um coda-fofo, e fazer algo do tipo array[100]=2.5; array.push(“name”). Ai vira hashmap e deixa de ser o(1) e ai vai depender de como foi implementado a função de hash e o número de colisões, mas chuta um O(log n). No geral, é um bocado de otimização pra fazer a gambiarra, que ngm gosta, funcionar decentemente.
De qualquer jeito, foi bem massa esse estudo. Odeio ainda mais JS, mas admiro o espírito de gambiarra do time de dev
@@daishes não é uma list, pelo menos não no v8
@@daishes Não é uma lista.... Listas não teriam esse acesso rapído, no Javascript são arrays concatenados, que podem tem um aumento de tamanho considerável quando necessário. Ou seja, novos arrays são criados e contatenados
@@taveirinha1337 Com listas eu quis dizer um ArrayList de algo como Java
Na real que o array do Javascript é um Dynamic Array, ou seja, o Javascript inicia um array statico com o tamanho necessário para alocar os itens passados ao instanciar o array, e depois automaticamente realoca o array inteiro para um novo endereço de memória se necessário.
Geralmente as implementações de array dinâmico dobram a quantidade de itens nessa realocação, mas o Javascript aumenta em 50% + 16 itens.
Então, se vc inicia um array vazio, este é um array estático com tamanho 0. Ao fazer um push, esse array é realocado para um novo endereço de memória, agora com tamanho 17.
Se vc inserir itens o suficiente para encher esse array, o mesmo será realocado para um novo endereço de memória, agora com tamanho 43.
Em resumo, o javascript te entrega um array mais alto nivel, no qual você nao precisa se preocupar com realocação. Em contrapartida, este array não vai ser tão eficiente quanto um array estático pq as realocações são feitas em O(n).
Na minha opinião é um tradeoff justo :D
Exatamente!
alguem de JS lúcido !
JS tem mt magia lá na V8, a galera que diz senior nunca nem lê as especificações e defende com unhas e dentes.
parabéns pelo conteudo
Só um detalhe, essa parte de object, array, e outros tipos do Javascript, é tudo pela V8, Os runtimes (Node / Bun / Deno) só adiciona ou altera implementações que não estão na especificação da V8 ou que não seria compatível fora do Browser. ( FS, Fetch, Child Process,etc..)
Legal, gostei pra caramba de aprender isso, eu pesava que mais cedo ou mais tarde eu iria ter que entender, mas não imaginei que conseguiria entender isso do nada assim tão rápido. Esses dias estava tentando entender a diferença entre List e Array no Kotlin, e pronto! tá ai a diferença! Vlw Galego!
Chegando aqui pelo Lucas Montano, vou maratonar esse canal. lets go
Seus conteúdos sao top!! estava querendo comprar esse livro e agora ganhei um motivo kkkkk
Nao confio em programador javascript que nao fala mal da linguagem 😂
No pyhton tem array nativo. Você faz assim:
from array import array
temp_array = array("i", [1, 2, 3, 4, 5])
print(temp_array)
//Output
[1,2,3,4,5]
Em go chamamos de slice e ele define um size automaticamente, como deixamos de usar um tamanho fixo não chamamos mais de array.
Obrigado pelos ensinamentos, mestre!
Muito bom, nunca usei rust e agora fiquei com uma pulga atrás da orelha enorme para saber como funciona uma implementação de uma lista ou array onde o número de elementos é desconhecido
Excelente esses comparativos e casos de estudo… poderia fazer entre mais linguagens como C#, Java e GO já que são muito utilizadas também...
o array no js é um map em que as chaves sao numbers kkkkkk
kkkkkkkkkkkkkkkkkkkkkkkkkkk
@@matheusdasilva7895 é duro kkkkkkk
Comprei pelo link de afiliado pra ajudar o canal :) . Continue com o excelente conteúdo
Na moralzinha? Tomara que esse canal cresça, são poucos TH-camrs técnicos restando, a galera tá se aposentando😢
Próximo mês eu compro esse livro 😊
Não sei como é a implementação em outras linguagens. Mas no próprio Rust tem o tipo Vec que o tamanho não precisa ser informado de antecipadamente.
A leitura, escrita e remoção no Vec é O(1). Já a inserção é O(1) armotizado.
O Vec tem um tamanho e uma capacidade. O tamanho é quantos elementos o Vec tem, e a capacidade é quantos bytes alocado o Vec tem na memória de forma contígua.
Para acessar e inserir, é facil ver porque a operação é O(1). Romover é só diminuir o tamanho sem diminuir a capacidade (apesar de que diminuir os bytes alocados também é O(1).
Já a inserção, pode ser que estoure a capacidade. Nesse caso é necessário alocar um espaço contíguo maior e copiar tudo de um espaço para o outro. O que faz a inserção ser O(1) amortizado, é que novo espaço alocado é mais que um elemento maior, garantimdo que as parte das próximas inserções sejam O(1), e de forma que se olhar para várias inserções como um todo, o preço de aumentar a capacidade é dividida com as inserções O(1), de modo que a inserção a inserção seja O(1) amortizada.
===
Aliás lista em python consegue suprir o papel de varias estruturas de dados. Funciona bem como array, pilha, lista heterogênea e lista recursiva. Mas não é uma boa fila nem deque.
voce poderia fazer um video explicando como que o comando "sorted" em python funciona de baixo dos panos ? tenho curiosidade em saber qual lógica ela utiliza
Eu teria que estudar a fundo como funciona o js por baixo dos panos, mas js é uma linguagem de mais alto nível que o c, por exemplo, então será que quando criamos a lista e aumentamos o tamanho dela, por baixo dos panos o js não está apagando o array anterior e criando um novo?
se tu quiser muito muito usar array puro no lugar do Object Array, tem os TypedArrays
Minha sensação é que sempre tem jeito de otimizar o js pra ter performance, só que demanda um esforço maior, tu pode ir pelo complexo e performático ou só fazer teu projetinho de boas com um let arr = [] e ter essas duas opções me parece mó gostosin mano...
Falae mano, blz? Mas só te falar, TypedArrays continua nao sendo um Array puro e ele traz um ganho de performance não muito grande.
@@dhanielr Mas o que falta pra ser puro, tem tamanho pré definido e datatype também, imagino que na conversão pra C++ ele acabe alocando isso na memória da maneira correta ou do contrário ele perde o sentido.
Tu sabe como funciona ele por baixo dos panos?
@@lucaslevandoski2946 oq de fato falta pra ser puro é ser um array em memória em si. Ele carrega lógica em conjunto com a implementação nativa do array. Por isso que na própria documentação do TypedArrays, eles se referem como um "Array-like object".
@@dhanielr faz sentido, doidera, vlw
@@lucaslevandoski2946 tmj, nada nao fi
Lembro da diferença quando estudei java, no java precisa definir o tamanho e tipo do array (só não fazer um pré preenchimento), mas realmente, chamar de array não faz sentido. Em Dart segue a mesma idéia de python: existem listas, não arrays, justamente por conta dessa flexibilidade
Um video que falou algo bem obvio, mas não entendi pq ta QUEBRADO NO FIM.
Ficou um video sem conclusão.
Ta certo isso?
Não tenho certeza ,mas se me lembro bem o array em javascript ele faz o(1) para pegar só o primeiro e o último elemento. O resto ele sai passando pelos endereços de memória. Exemplo: se quiser achar a terceiro elemento ele vai no primeiro que aponta o espaço de memória do segundo, olha o segundo que aponta o espaço de memória do terceiro.
presente na aula de hoje 🤚
já tenho o livro, o conteúdo do vídeo não é uma novidade pra mim, mas gosto de ver seu trampo =)
Uma boa sugestão do @Lucas Motano.
Sonhando pelo dia que JS não será obrigatoriedade 😅
quando eu fiz o curso de algoritmo do primeagen ele explica isso tambem muito bom
javaScript tem implementação em cada navegador
E o vídeo fala isso...
fique tranquilo amigo, TODOS podem e devem falar mal de javascript
Aprendi algo novo.
Acredito que tanto java Script quanto Rust tem propositos diferente
mas valeu pela explicação
Eu tinha percebido a um tempo até tbm em outras langs q.
"Mesmo que se chame array, não significa que seja um array como em C".
É só problema com escolha de palavras, até porque se for analisar o inglês ainda está certo chamar de array, só não vai ser um array padrão C.
Inclusive minha mente buga quando vejo algo em inglês tipo série e eles usam a palavras "array" para algo fora da computação.
No começo do vídeo eu imaginava que seria algo diferente disso, tipo usar Map ou hash table
O mundo vai colapsar, pq alguém tem que dizer que tem lugar de fala pra algo.
Vídeo sensacional
Qual o nome da ferramenta que esta utilizando para demostrar ?
Excalidraw
Então é por isso que em C você pode acabar sobre-escrevendo a memória? Porque C não se importa se no campo,.digamos, 0xDEADBEEF, já tenha coisa guardada e escreve coisa lá mesmo assim? WTF
Obrigado pelo conteúdo.
Uma pergunta, em C++ conseguimos criar uma array sem um tamanho pré-definido, isso a torna ou não uma lista ou uma gambiarra (sou iniciante em c++, não manjo tanto)
Gambiarra é um nome forte para o que os arrays de js são. Js usa o conceito que algumas linguagens como chamam de array list ou vector. Que nada mais é do que um array que tem uma certa capacidade e ao dar push, se a capacidade não puder suportar o número de itens, ele aloca outro espaço continuo de memória maior que o original e realoca os itens para lá, adicionando o novo no final.
Ué, mas no python não chamam de lists?
Comparar Javascript que é uma linguagem interpretada criada para coisas pequenas com rust que é uma linguagem compilada feita para coisas grandes é completamente desfundamentado. Claro que rust é melhor a gerir memória, javascript foi criado para fazer piscar coisas no DOM não para gerir memória, até porque um script JS quanto mais tempo ele demora a executar pior fica a memória. Concordo com os argumentos do vídeo mas acho que era mais justa a comparação entre por exemplo c++ e rust ou java e rust, por exemplo.
Legal a explicação da memória. E Array no js é um object, na real. 😅
O problema é que aprendemos a chamalos de Array,,, JS deveris ser igual ao py e chamar de List
Faz sentido!
vim pelo reacT do Lucas Montano do canal Lucas Montano
Por isso eu tenho uma relação de amor e ódio com o javascript,porque eu concordo que o javascript tem gambiarras,mas ao mesmo tempo tu consegue fazer tudo nele,sem contar que é mais prático pois tem o backend e o frontend junto,de qualquer maneira nenhuma linguagem é perfeita e sim concordo com você que o javascript tem uns "improvisos" mas mesmo assim eu amo programas em javascript por ser prático. De qualquer maneira ótima aula e analogia.
Uma linguagem de mentira foi a melhor kkkkkkkkkkk
Meu caro, achei que vc ia falar mal do JS por falar igual a maioria dos criadores de conteúdo tech. Virou moda falar mal de JS, mas todo mundo usa, não programando, mas usa. Vídeo incrível, parabéns.
Nem é moda de agora cara... Todo mundo fala mal de JS desde que eu estudava Pascal 🤣🤣🤣🤣🤣
@@Set_Abominae se atualizou? Sabe como funciona o JS de forma profunda? Enfim, rsrs pra falar mal de algo, conhece esse algo.
@@mayromyller4086 Exato! Concordo plenamente. Só não fala mal de JS quem não conhece.
É um "array".
by JS
Presente ✋
Descobri isso recentemente em java, quando fui adicionar mais dados no array em não consegui por que era fixo o seu tamanho, diferente do Javascript que podemos dar um push 😂😂
Python não tem array nativo, o clássico é da biblioteca numpy que herda o conceito do c
Olá! Python tem array nativo. Testa aí
from array import array
temp_array = array("i", [1, 2, 3, 4, 5])
print(temp_array)
[...]"uma de mentira (JavaScript)"[...] me pegou desprevenido kkkkkk
No PHP a definição do array segue os mesmos moldes e não há limites de alocação depois de instanciado (claro que irá ter o limite fisico ou o definido na configuração).
Nesse caso podemos dizer que no PHP também não é um array de verdade ?
sim
Javascript é rio de janeiro
java tbm faz esse gambiarra ou é um array real?
Java tem ArrayList que comporta como no JS e o Array, que comporta como no Rust.
@@marcelsantee1809 mas pelo menos o termo arrayList deixa aceitavel, é uma lista de arrays, nao tem problema ele ter tamanho mutavel nesse caso porque a lista encadeada é mutavel
Eu não compro livros mas recomendo demais esse livro citado pelo Galego, faz a gente entender estruturas complexas tranquilamente...
Mas se o js é transpilado pra c++, não seria esse o responsável pela alocação de memória?
Javascript não é transpilado pra c++. A V8 é escrita sim em c++, mas não significa que ela pega o teu código JS e transforma em C++, são coisas diferentes.
@@Eduardoxlord Quem executa é A V8, que é escrita em c++, e vc ainda tem dúvida de quem tá alocando recursos e organizando a estrutura dos objetos? kkkkk
@@inosuke3626 Eu não tenho dúvida nenhuma, a dúvida aqui é só sua. O javascript NÃO é transpilado para c++, a V8 é escrita em c++ para interpretar linha a linha do JS, mas ela não traduz a tua linha em js para c++, na verdade se não me engano ela trabalha com ECMA e WebAssembly, no final transformando em binário na arquitetura do sistema que está rodando, entendeu? A lógica do array continua sendo algo como List, é isso que dá o dinamismo nesse caso.
Ela não pega o teu array da linha x e transforma no array do c++, entendeu?
e os TypedArrays ?
kkkk linguagem de verdade, polemica
muito bom os videos, ja sou follow no linkedin
Bota a culpa no C++. JS nem é linguagem 🤡
A parada é que geralmente estamos lidando com arrays dinamicos (principalmente em js) onde não sabemos nem o tipo e nem a largura que esse array pode ter kkk
então o problema é só o nome? porque ter que definir tamanho e tipo de uma lista pra dados totalmente dinâmicos no JavaScript não faz nem sentido kkk javascript é bom até pra gerar "conteudo" pra galera kkk
ou seja por ser gambiarra é a mais usada. não crie complexidades crie gambiarra