It’s $20 per month if you click through, and I haven’t tried it but almost certainly the normal hosting costs will be added on top.
Thanks, apparently didn't click through enough
Readit Newsfinder83 commented on Phoenix.new – Remote AI Runtime for Phoenix fly.io/blog/phoenix-new-t... · Posted by u/wut42
finder83 commented on Phoenix.new – Remote AI Runtime for Phoenix fly.io/blog/phoenix-new-t... · Posted by u/wut42
Phoenix creator here. I'm happy to answer any questions about this! Also worth noting that phoenix.new is a global Elixir cluster that spans the planet. If you sign up in Australia, you get an IDE and agent placed in Sydney.
This looks amazing! I keep loving Phoenix more the more I use it.
I was curious what the pricing for this is? Is it normal fly pricing for an instance, and is there any AI cost or environment cost?
And can it do multiple projects on different domains?
The trouble is although you get billed for the book, the library does not replace it. I've had things on hold get cancelled with a note about "no longer available".
I've bought a lot of books from the thrift store that had library stamps in them.
It's very possible they don't replace them, but many libraries also have legitimate sells to clear books from inventory to make room. Usually over like a week or three day weekend once or twice a year, the last day having bags of books for $5. All of them have stamps/card holders/stickers designating the library. So those don't necessarily mean they were borrowed and never returned.
Deleted Comment
finder83 commented on GitHub Copilot is now available for free github.com/features/copil... · Posted by u/ksec
I have been using Cursor, but I am a vim user at heart. What is the best plugin I can use that gives us the power of AI coding, but for vim? Every time I look, the plugins seem to be far behind Cursor.
https://github.com/github/copilot.vim works pretty well for inline autocompletion
https://github.com/CopilotC-Nvim/CopilotChat.nvim is the best I've found for the chat-type interaction. It lets you choose models/etc.
It's still not quite as nice as cursor, but decent enough that I enjoy using them
finder83 commented on Serialization Is the Secret zachdaniel.dev/p/serializ... · Posted by u/borromakot
> One of the major elements that sets Elixir apart from most other programming languages is immutability.
It's interesting to compare Elixir to that other immutable programming language: Haskell.
In Elixir, a binding
counter = counter + 1
Of course that doesn't make sense, and indeed this causes an infinite loop when Haskell tries to evaluate counter.
BUT it does make sense for certain recursive data structures, like an infinite list of 1s:
ones = 1 : ones
ghci> take 5 ones
[1,1,1,1,1]
Can you define such lazy infinite data structures in Elixir?
Infinite, yes, but I would say it's not quite as core to the language as it is in Haskell where everything's lazy. Infinite streams are quite simple though:
Stream.iterate(1, fn(x) -> x end)
|> Enum.take(5)
[1, 1, 1, 1, 1]finder83 commented on Serialization Is the Secret zachdaniel.dev/p/serializ... · Posted by u/borromakot
> I would argue that, from the perspective of our program, it is not more or less mutable than any other thing. The reason for this, is that in Elixir, all mutating state requires calling a function to observe it.
Are you never not inside a called function?
This just sounds like pervasive mutability with more steps.
The functions don't return a mutable version of a variable or anything. You still get an immutable copy (it may not be an actual copy, I don't know the internals) of the state, and the state he's referencing in a Genserver is the current state of a running process that runs in a loop handling messages. For example in liveview, each connection (to an end-user) is a process that keeps state as part of the socket. And the editing is handled through events and lifecycle functions, not through directly mutating the state, so things tend to be more predictable in my experience. It's kind of like mutation by contract. In reality, it's more like for each mailbox message, you have another loop iteration, and that loop iteration can return the same value or a new value. The new values are always immutable. So it's like going from generations of variables, abandoning the old references, and using the new one for each iteration of the loop. In practice though, it's just message handling and internal state, which is what he means by "from the perspective of our program".
You typically wouldn't just write a Genserver to hold state just to make it mutable (though I've seen them used that way), unless it's shared state across multiple processes. They're not used as pervasively as say classes in OOP. Genservers usually have a purpose, like tracking users in a waiting room, chat messages, etc. Each message handler is also serial in that you handle one mailbox message at a time (which can spawn a new process, but then that new process state is also immutable), so the internal state of a Genserver is largely predictable and trackable. So the only way to mutate state is to send a message, and the only way to get the new state is to ask for it.
There's a lot of benefits of that model, like knowing that two pieces of code will never hit a race condition to edit the same area of memory at the same time because memory is never shared. Along with the preemptive scheduler, micro-threads, and process supervisors, it makes for a really nice scalable (if well-designed) asynchronous solution.
I'm not sure I 100% agree that watching mutating state requires a function to observe it. After all, a genserver can send a message to other processes to let them know that the state's changed along with the new state. Like in a pub-sub system. But maybe he's presenting an over-simplification trying to explain the means of mutability in Elixir.
There is one big issue with terminal editors that I keep running up against: single font size. One notable place where this is an issue is file listings, being able to have smaller proportional fonts makes a huge difference in usability.
I have switched to Zed, but it sadly shares more in common with vscode than it does vim. I believe the ideal text editor would bring a small amount of GUI to the general idea of one of the popular nvim distros (especially telescope).
Telescope feels so game-changing, and I've not found anything like it outside of Neovim and Emacs. Being able to fuzzy search a buffer or my project instantly makes navigation insanely fast.
People talk about not needing to type fast when coding, but I do need to navigate quickly, especially to not lose context while thinking. Ivy/Helm/Telescope with one of the various jump libraries (and LSP of course) makes code navigation feel second nature.
Deleted Comment