Luiz Felipe
@luizfelipe.dev
enum do TS (usando a keyword enum) é basicamente a mesma coisa de Java, C#, etc: uma lista de valores (geralmente escalares) do mesmo domínio/tipo
Union é outra coisa. Em TS você tem isso usando o `|`
Union é outra coisa. Em TS você tem isso usando o `|`
December 30, 2024 at 12:28 AM
enum do TS (usando a keyword enum) é basicamente a mesma coisa de Java, C#, etc: uma lista de valores (geralmente escalares) do mesmo domínio/tipo
Union é outra coisa. Em TS você tem isso usando o `|`
Union é outra coisa. Em TS você tem isso usando o `|`
Programa em Rust q vc descobre; ou em alguma outra lang com sum types
TS tb dá pra ter isso com discriminated unions, mas imo é um pouco mais convoluto no caso simples pq na maioria dos casos vc precisa explicitamente definir a tag
TS tb dá pra ter isso com discriminated unions, mas imo é um pouco mais convoluto no caso simples pq na maioria dos casos vc precisa explicitamente definir a tag
December 30, 2024 at 12:26 AM
Programa em Rust q vc descobre; ou em alguma outra lang com sum types
TS tb dá pra ter isso com discriminated unions, mas imo é um pouco mais convoluto no caso simples pq na maioria dos casos vc precisa explicitamente definir a tag
TS tb dá pra ter isso com discriminated unions, mas imo é um pouco mais convoluto no caso simples pq na maioria dos casos vc precisa explicitamente definir a tag
IMHO o money do PG nao é muito aconselhável porque só suporta um locale (configurado ao nível do database inteiro!)
Numeric (aka decimal) já traz toda a precisão necessária e a flexibilidade
Numeric (aka decimal) já traz toda a precisão necessária e a flexibilidade
December 30, 2024 at 12:25 AM
IMHO o money do PG nao é muito aconselhável porque só suporta um locale (configurado ao nível do database inteiro!)
Numeric (aka decimal) já traz toda a precisão necessária e a flexibilidade
Numeric (aka decimal) já traz toda a precisão necessária e a flexibilidade
Aí não é fã o suficiente
December 9, 2024 at 3:15 PM
Aí não é fã o suficiente
Provinha de FTC na segunda né
September 12, 2024 at 4:02 AM
Provinha de FTC na segunda né
Yeah, por ora eu só tô usando pra gerenciar uma infinidade de PDFs e ler alguns deles… Tô aprendendo conforme vou usando
September 9, 2024 at 1:51 AM
Yeah, por ora eu só tô usando pra gerenciar uma infinidade de PDFs e ler alguns deles… Tô aprendendo conforme vou usando
já tem bastante coisa, mas nao esquece de isolation levels :P
September 6, 2024 at 2:18 AM
já tem bastante coisa, mas nao esquece de isolation levels :P
Eu tive que apagar o aplicativo do twitter por causa disso
September 5, 2024 at 11:27 PM
Eu tive que apagar o aplicativo do twitter por causa disso
Isso garante a tal da serialização, assim como o lock :)
September 5, 2024 at 11:24 PM
Isso garante a tal da serialização, assim como o lock :)
E o canal de mensagens consegue fazer isso justamente porque é implementado de modo a ser capaz de receber várias mensagens de vários atores ao mesmo tempo, *mas* só fornece *uma mensagem por vez* para o ator que consome seus elementos (afinal, o recurso só está na posse de um "ator").
September 5, 2024 at 11:24 PM
E o canal de mensagens consegue fazer isso justamente porque é implementado de modo a ser capaz de receber várias mensagens de vários atores ao mesmo tempo, *mas* só fornece *uma mensagem por vez* para o ator que consome seus elementos (afinal, o recurso só está na posse de um "ator").
A resposta é: fazendo a operação usando algum tipo de mensagem. O ator "dono" do recurso (a memória, por ex) fica continuamente processando essas mensagens e agindo de acordo com o que deve fazer.
Nesse caso o "elemento de sincronia" (que antes era o mutex) passa a ser o próprio canal de mensagens!
Nesse caso o "elemento de sincronia" (que antes era o mutex) passa a ser o próprio canal de mensagens!
September 5, 2024 at 11:23 PM
A resposta é: fazendo a operação usando algum tipo de mensagem. O ator "dono" do recurso (a memória, por ex) fica continuamente processando essas mensagens e agindo de acordo com o que deve fazer.
Nesse caso o "elemento de sincronia" (que antes era o mutex) passa a ser o próprio canal de mensagens!
Nesse caso o "elemento de sincronia" (que antes era o mutex) passa a ser o próprio canal de mensagens!
A outra abordagem, message passing, elimina a necessidade de sincronização com locking porque garante que uma região de memória *sempre* irá pertencer a um "ator"/"processo" por vez.
Mas aí você se pergunta: como outros processos vão usar aquele recurso (que eles precisam, afinal).
Mas aí você se pergunta: como outros processos vão usar aquele recurso (que eles precisam, afinal).
September 5, 2024 at 11:23 PM
A outra abordagem, message passing, elimina a necessidade de sincronização com locking porque garante que uma região de memória *sempre* irá pertencer a um "ator"/"processo" por vez.
Mas aí você se pergunta: como outros processos vão usar aquele recurso (que eles precisam, afinal).
Mas aí você se pergunta: como outros processos vão usar aquele recurso (que eles precisam, afinal).
Um mutex, por exemplo, sincroniza os dados de modo a garantir que em um momento possa existir apenas um leitor/escritos mexendo na região compartilhada.
September 5, 2024 at 11:22 PM
Um mutex, por exemplo, sincroniza os dados de modo a garantir que em um momento possa existir apenas um leitor/escritos mexendo na região compartilhada.
Shared memory é quando os processos concorrentes podem ler e escrever em uma mesma região de memória. Naturalmente, se você fizer isso de forma "descontrolada" (sem sincronização), você terá problemas graves, como data races. Na maior parte dos casos, dá pra sincronizar o acesso usando lock.
September 5, 2024 at 11:22 PM
Shared memory é quando os processos concorrentes podem ler e escrever em uma mesma região de memória. Naturalmente, se você fizer isso de forma "descontrolada" (sem sincronização), você terá problemas graves, como data races. Na maior parte dos casos, dá pra sincronizar o acesso usando lock.
Vou reduzir o escopo para simplificar. Em um mesmo computador, existem duas "grandes" abordagens para se estruturar código concorrente dentro de um mesmo processo. Shared memory e message passing.
September 5, 2024 at 11:22 PM
Vou reduzir o escopo para simplificar. Em um mesmo computador, existem duas "grandes" abordagens para se estruturar código concorrente dentro de um mesmo processo. Shared memory e message passing.
O problema de ter um único recurso que precisa ser compartilhado por mais de um processo de forma concorrente é bem comum--seja em um mesmo computador (paralelismo via multi-threading, por ex.) ou, como no exemplo do @zanfranceschi.bsky.social, em um sistema distribuído (vários nós).
September 5, 2024 at 11:21 PM
O problema de ter um único recurso que precisa ser compartilhado por mais de um processo de forma concorrente é bem comum--seja em um mesmo computador (paralelismo via multi-threading, por ex.) ou, como no exemplo do @zanfranceschi.bsky.social, em um sistema distribuído (vários nós).
Feedback-loop muito longo? Ou outra coisa?
September 5, 2024 at 9:56 PM
Feedback-loop muito longo? Ou outra coisa?
Muuuuuuuito bom mesmo!! (embora o autor seja intragável no twitter)
September 3, 2024 at 3:30 PM
Muuuuuuuito bom mesmo!! (embora o autor seja intragável no twitter)
A semântica é a mesma inclusive por fora do iex. Lembrando que em Elixir quase tudo é expressão, então quase tudo retorna um valor mesmo.
September 1, 2024 at 1:50 PM
A semântica é a mesma inclusive por fora do iex. Lembrando que em Elixir quase tudo é expressão, então quase tudo retorna um valor mesmo.