λ (λ 2 (1 1)) (λ 2 (1 1))
@hauleth.dev
Meme Driven Developer
All opinions aren't my own, these belongs to supreme being chosen at random
Sometimes I do some #ElixirLang and #Erlang
All opinions aren't my own, these belongs to supreme being chosen at random
Sometimes I do some #ElixirLang and #Erlang
It is called Duckex (hex.pm/packages/duc...) and it uses Port instead of NIF (as other DuckDB client libraries do).
The advantages are obvious - bug in DuckDB (or loaded extension) will not cause BEAM VM to fail and it also helps with RAM handling (as OOM killer will handle subprocess instead of VM)
The advantages are obvious - bug in DuckDB (or loaded extension) will not cause BEAM VM to fail and it also helps with RAM handling (as OOM killer will handle subprocess instead of VM)
duckex
DuckDB client library
hex.pm
November 6, 2025 at 10:52 AM
It is called Duckex (hex.pm/packages/duc...) and it uses Port instead of NIF (as other DuckDB client libraries do).
The advantages are obvious - bug in DuckDB (or loaded extension) will not cause BEAM VM to fail and it also helps with RAM handling (as OOM killer will handle subprocess instead of VM)
The advantages are obvious - bug in DuckDB (or loaded extension) will not cause BEAM VM to fail and it also helps with RAM handling (as OOM killer will handle subprocess instead of VM)
Why not use `image` library or if someone is really daring - using `wxImage` from OTP.
November 6, 2025 at 10:46 AM
Why not use `image` library or if someone is really daring - using `wxImage` from OTP.
I am open for such possibilities. Thanks, I will apply.
October 29, 2025 at 12:31 PM
I am open for such possibilities. Thanks, I will apply.
One tidbit - it is significant/mantissa sign, not exponent
October 10, 2025 at 11:24 PM
One tidbit - it is significant/mantissa sign, not exponent
Yay, yet another reason to dislike Tailwind ❤️
September 30, 2025 at 3:10 PM
Yay, yet another reason to dislike Tailwind ❤️
`nil` is perfectly valid value that may be returned by the DB when doing query, especially when you select just single value. That is the reason why I do not like `Repo.get*` functions, as these do not differentiate between "no result" and "empty value".
September 26, 2025 at 6:30 AM
`nil` is perfectly valid value that may be returned by the DB when doing query, especially when you select just single value. That is the reason why I do not like `Repo.get*` functions, as these do not differentiate between "no result" and "empty value".
application_start callbacks are so underused feature.
September 24, 2025 at 9:00 PM
application_start callbacks are so underused feature.
Are You learning Polish?
September 24, 2025 at 8:58 PM
Are You learning Polish?
I prefer DDD (destroy database daily).
September 24, 2025 at 5:45 PM
I prefer DDD (destroy database daily).
We need to go back to RSS/Atom feeds with that.
September 24, 2025 at 12:22 PM
We need to go back to RSS/Atom feeds with that.
It is interesting wrapper, but used incorrectly there. Instead I prefer to add to my `Repo` function:
def fetch(queryable, opts) do
case all(queryable, opts) do
[val] -> {:ok, val}
_ -> :error
end
end
Which is proper way to do so (as `nil` is perfectly fine value returned from query).
def fetch(queryable, opts) do
case all(queryable, opts) do
[val] -> {:ok, val}
_ -> :error
end
end
Which is proper way to do so (as `nil` is perfectly fine value returned from query).
September 24, 2025 at 8:21 AM
It is interesting wrapper, but used incorrectly there. Instead I prefer to add to my `Repo` function:
def fetch(queryable, opts) do
case all(queryable, opts) do
[val] -> {:ok, val}
_ -> :error
end
end
Which is proper way to do so (as `nil` is perfectly fine value returned from query).
def fetch(queryable, opts) do
case all(queryable, opts) do
[val] -> {:ok, val}
_ -> :error
end
end
Which is proper way to do so (as `nil` is perfectly fine value returned from query).
Russel's Teapot?
September 20, 2025 at 5:34 PM
Russel's Teapot?
Support for development deployments that would not require me to setup any accounts or do any fancy setup. I want just be able to run observability stack locally.
I was even planning on writing something like that with just in-memory storage, so I can test and use it in development as well.
I was even planning on writing something like that with just in-memory storage, so I can test and use it in development as well.
September 18, 2025 at 7:32 PM
Support for development deployments that would not require me to setup any accounts or do any fancy setup. I want just be able to run observability stack locally.
I was even planning on writing something like that with just in-memory storage, so I can test and use it in development as well.
I was even planning on writing something like that with just in-memory storage, so I can test and use it in development as well.
If you have some file watcher (like entr), then you can do that without extra tools
rg -l -telixir "" | entr -p echo /_ | mix test --listen-on-stdin
rg -l -telixir "" | entr -p echo /_ | mix test --listen-on-stdin
September 14, 2025 at 12:22 PM
If you have some file watcher (like entr), then you can do that without extra tools
rg -l -telixir "" | entr -p echo /_ | mix test --listen-on-stdin
rg -l -telixir "" | entr -p echo /_ | mix test --listen-on-stdin
I hope that there will be second edition as I couldn't go this year.
September 13, 2025 at 7:43 PM
I hope that there will be second edition as I couldn't go this year.
You can use separate DB for your processes. And if you want ephemeral queue of jobs to be done then just do not use DB at all just spawn a process and call it a day.
September 11, 2025 at 7:55 PM
You can use separate DB for your processes. And if you want ephemeral queue of jobs to be done then just do not use DB at all just spawn a process and call it a day.
What do you mean by "scale" there?
September 11, 2025 at 6:11 PM
What do you mean by "scale" there?
In UNIX everything is file descriptor, but not file. In Plan 9 everything is a file.
September 8, 2025 at 11:06 AM
In UNIX everything is file descriptor, but not file. In Plan 9 everything is a file.
I do not have anything against NIFs per se, but their deployment is PITA, so I prefer to avoid them if possible, especially with runtime dependencies.
About OpenSSL KDF - it was released 2 years ago, so maybe it is time to add it to `crypto`.
About OpenSSL KDF - it was released 2 years ago, so maybe it is time to add it to `crypto`.
September 6, 2025 at 4:04 PM
I do not have anything against NIFs per se, but their deployment is PITA, so I prefer to avoid them if possible, especially with runtime dependencies.
About OpenSSL KDF - it was released 2 years ago, so maybe it is time to add it to `crypto`.
About OpenSSL KDF - it was released 2 years ago, so maybe it is time to add it to `crypto`.
Hopefully in near future we will not need external NIF for Argon2 anymore, as now it is part of OpenSSL (docs.openssl.org/3.3/man7/EVP...). So maybe it will be available from Erlang in near future.
EVP_KDF-ARGON2 - OpenSSL Documentation
docs.openssl.org
September 6, 2025 at 1:36 PM
Hopefully in near future we will not need external NIF for Argon2 anymore, as now it is part of OpenSSL (docs.openssl.org/3.3/man7/EVP...). So maybe it will be available from Erlang in near future.