61–70 of 72 posts
What's your experience been like with Nix? How do you feel about devenv vs stock Nix? How are you getting devenv to work, as I don't see a devenv.nix file. I'm still a Nix beginner and would like to find ways of integrating it more into my development and improving my current techniques.[0] [0] https://mtlynch.io/notes/nix-dev-environment/
So, we've been using devenv for some time now and it's useful for describing a monorepo-like environment that zig-enjoyers can quickly code and test their changes on the latest version of the erlang server. Also, it's incredibly easy to also manage postgres from there. It's great if you like local-first development experience.
I now see that you're using devenv from within your flake.nix, which I didn't realize you could do.[0] Neat!
I'm going to give that a spin in my projects, as my current solution for pinning versions of Go, Zig, etc. is to use nixhub to look up which commit of nixpkgs corresponds to which version of Go (e.g., Go 1.23.2 is nixpkgs version 4ae2e647537bcdbb82265469442713d066675275). That's obviously a pain to look up and performs poorly, so I'm curious to see how devenv goes.
Thanks for sharing the source!
[0] https://github.com/Dr-Nekoma/lyceum/blob/1b0acf2d4bf295135bb...
Earlier quoted context omitted.
I'm not aware of anyone running a limited dist to allow for untrusted dist clients. But here's an OTP response to a proposal that's pretty clearly a no [1]. It'd be much simpler to put together a custom protocol to communicate between the client and server. You could use Erlang's External Term Format to exchange data if you want, in which case you'd want to do binary_to_term(Binary, [safe]) to prevent creation of new…
Thanks for the ideas and references! I gotta say, though, that I will be pretty sad if having to write a custom protocol turns out to be the final solution. So much more convenient to use OTP (especially now that we finally have an infinitely extensible serialization library for it; Zerl). I'm shocked such an oversight would exist in a real commercial solution which is the BEAM.
Additional applications for dist have been explored over the years, but most of them involve clustering servers; where a security barrier isn't necessary; although it might be desirable --- I've used dist clusters where some people had access to only certain types of nodes; bypassing access control using dist clustering was certainly a possibility. Bolting security onto something designed without it often is pretty challenging. Especially if you want to keep all the existing applications working.
Earlier quoted context omitted.
I'm not aware of anyone running a limited dist to allow for untrusted dist clients. But here's an OTP response to a proposal that's pretty clearly a no [1]. It'd be much simpler to put together a custom protocol to communicate between the client and server. You could use Erlang's External Term Format to exchange data if you want, in which case you'd want to do binary_to_term(Binary, [safe]) to prevent creation of new…
Thanks for the ideas and references! I gotta say, though, that I will be pretty sad if having to write a custom protocol turns out to be the final solution. So much more convenient to use OTP (especially now that we finally have an infinitely extensible serialization library for it; Zerl). I'm shocked such an oversight would exist in a real commercial solution which is the BEAM.
Earlier quoted context omitted.
So, we've been using devenv for some time now and it's useful for describing a monorepo-like environment that zig-enjoyers can quickly code and test their changes on the latest version of the erlang server. Also, it's incredibly easy to also manage postgres from there. It's great if you like local-first development experience.
I looked harder at the code to figure out how you're using devenv without a devenv.nix file. I now see that you're using devenv from within your flake.nix, which I didn't realize you could do.[0] Neat! I'm going to give that a spin in my projects, as my current solution for pinning versions of Go, Zig, etc. is to use nixhub to look up which commit of nixpkgs corresponds to which version of Go (e.g., Go 1.23.2 is nixp…
I've actually written about the process that led us to use the following flake here: https://mtrsk.github.io/blog/2024/experiments-with-erlang-an...
Earlier quoted context omitted.
I'm not aware of anyone running a limited dist to allow for untrusted dist clients. But here's an OTP response to a proposal that's pretty clearly a no [1]. It'd be much simpler to put together a custom protocol to communicate between the client and server. You could use Erlang's External Term Format to exchange data if you want, in which case you'd want to do binary_to_term(Binary, [safe]) to prevent creation of new…
Thanks for the ideas and references! I gotta say, though, that I will be pretty sad if having to write a custom protocol turns out to be the final solution. So much more convenient to use OTP (especially now that we finally have an infinitely extensible serialization library for it; Zerl). I'm shocked such an oversight would exist in a real commercial solution which is the BEAM.
For example, several of the gRPC libs I've used for Erlang/Elixir are pretty low-cognitive-overhead to use, and they come with all the added gRPC goodies: RPC semantics are described in one place rather than ad-hoc throughout code, protobufs have at least a documented (if not actually good) process for upgrades and backwards compatibility, multilanguage gets easier (even if your second language is just a tiny sliver of "dump protobufs into a database/Jupyter notebook/Rust program occasionally for offline reporting").
To be clear, this isn't a paean to gRPC; most of those features are table stakes for an IDL-driven protocol definition. Just saying that you do get some things in return for giving up the convenience of OTP, if you pick the right tools.
I was clicking the source expecting to see what kind of game Lyceum is. There is no description about the game and no images of the game.
You can also check it out a little demo: https://www.youtube.com/watch?v=ejYcWRERetM&t=2758s