vereis

doesn't stop someone running a long running claude cli session in tmux and programmatically giving it messages... anthropic is fighting an unwinnable battle

crit was a game changer for my longer planning sessions and it gives me a good way to do code review for llm output locally first

I was anticipating setting up gitea or something and using that as a place where I'd push code while I was still iterating but thanks to crit I totally avoid that!

just fits into my workflow too

the problem with this is I'd strongly argue that you could do this pen and paper process with the human brain and our consciousness too; we just lack enough understanding to put pen to paper in that case

the notion of consciousness being something an experience that other animals/humans share is entirely faith based.

the only person with evidence of ones consciousness is the person claiming they're conscious.

https://vereis.com

yeah this is the distinctive ps1 look I think all games look like this, at least polygonal games

i think the original quote is "Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang" :-) but your point still stands

elixir is only better imo because of better tooling, more libraries/bigger ecosystem, and macros

give me macros and I'd be happy (not preprocessor stuff, not parse transforms)

honest q: how do you distinguish between single node erlang applications vs clustered erlang applications?

my personal reality is that the majority of projects I've consulted on have seldom actually leveraged distributed erlang for anything. the concurrency part yes, clustering for the sake of availability or spreading load yes, but actually doing anything more complex than that has been the exception! ymmv tho!

I recommend taking a look at the various open source Riak applications too! Might not be updated to any sort of recent versions of erlang but was a great resource to me early on.

ahoy!! thanks for spotting the issue I wrote the post in a stream of consciousness after a long day! I'll make that edit and call it out!

the statement about what historically constitutes a large erlang cluster was an anecdote told to by Francesco Cesarini during lunch a few years ago — I'm not actually sure of the time frame (or my memory!)

likewise I'll update the post to reflect that! thanks ( ◜ ‿ ◝ ) ♡

ahoy!!! never expected to see any of my posts on hn D:

for the first point it was purposely not written on the beam as otherwise there would be no post!

an original draft of did talk more in depth about replies but it just got convoluted and too long!! maybe I'll try to restore something to this end

granted on the runtime and genserver point (though technically it's just a process that receives messages, nothing so formal as a genserver itself)

Gleam runs on the BEAM

or use home-manager via nix!

well doesn't the argument suggest the only thing you can be certain of is I, or at least some 'experiencing agent' exist, otherwise there would be no subject to do the experiencing

I've not tried this for any adobe products, but you could try running them in a locked down environment (container, vm, whatever) and don't allow network access.

Depending on the model I'd take one!

You can always use a different email address to manage the domain if that's the issue?

Guaranteeing a singleton process is a very difficult problem which horde definitely does not solve perfectly mind you.

All is well and good until it isn't. We opted for leveraging different mix release permutations deployed on k8s as needed instead.

Definitely takes more effort than what you describe, and has its own issues... But imo definitely better understood than fighting weird state with horde

TypeScript bringing a half decent type system to JavaScript is orthogonal to OOP

JavaScript is OOP already. TypeScript just provides better typing like what you would find in Haskell, Ocaml or other functional languages

I just forego docker desktop and run docker on the command line in wsl2 instead.

Have you considered trying that?

It doesn't come with any styling OOTB. The idea is that you're just building a frontend (all the markup, styling etc) around some provided state management

You can find my site at cbailey.co.uk (it's my first time sharing it online!)

It's a pretty informal blog (and it's very unpolished). It's a standard Elixir/Phoenix app which polls GitHub Issues which is actually where my blog posts are stored (I'm basically leveraging it to do syntax highlighting, markdown to HTML compilation and eventually comments)

Might fall into the same category as Hound but Wallaby exists and works.

Otherwise have you heard of Crawley?

Popup menus, sidebars, drawing on top of a pages can all be done to a certain extent with some CSS

Accessibility is possible with standard semantic HTML and aria tags (again to a certain extent)

D&D is probably not workable though

This works until something does go wrong. At least with NixOS you can simply roll back!

I found the start up time for powershell to be quite noticeable in WSL for scripts like that.

If copying is all you're after you can invoke `clip.exe` instead.

Honestly though I just caved and ended up using an xserver with WSL for really smooth copy and paste support. Paste requires a powershell invocation without an xserver.

Definitely recommending X410 (paid) or VcrXsrv (free) -- let's you launch x11 apps too!

Once WSLu is released everything will be even more seamless though.

For me, one plus of home-manager is that I can easily use it and share modules between NixOS and, say, Alpine + Nix

It isn't perfect but I just end up installing nix (the package manager) and home-manager and hacking together my configuration through that.

The majority of my NixOS configuration is written in NixOS agnostic modules so it works pretty well.

I share my NixOS configurations between one bare metal Alpine install as well as an Alpine WSL2 install.

Whilst I have had problems with WSL, WSL2 is much better. Not run into anything which really causes an issue (if you can live with the reduced Linux<->Windows interoperability)