oDot

I run Gleam in production to great success[0][1]. It is a joy to use. Give it a try!

[0] https://nestful.app

[1] https://blog.nestful.app/p/gleams-lustre-is-frontend-develop...

You should give Gleam a shot. No REPL, but its simplicity, functional-ity and the BEAM lend themselves to the get-shit-done approach

Try iZotope RX

Unfortunately for many of the HTMX/Turbo people, they did right to identify the problem but they have the wrong solution.

The way to alleviate those issues is not to bloat the frontend with things that shouldn't be in it nor is it to fragment the code base with never ending "sprinkle" of JS.

The best solution is something like Gleam's Lustre, where you use the right tool for the job, while keeping a coherent code base:

https://blog.nestful.app/p/gleams-lustre-is-frontend-develop...

Is ATProto fully implementable by third parties? I last read there were still closed source parts

I use Nix and agree with most of what you said, except the main value proposition of docker-on-dev-machine is not convenience, but approximation of production

Hi there! I am extremely glad to read someone else write about this necessity!

I own and operate a "list-taking" app[0] in which every list/kanban-item can itself be a list/kanban.

I currently use it for things I'm the creator of -- tasks, story outlines, etc, but looking to introduce 3rd party content for task management (I want to see GitHub tasks from work next to my own tasks) and, as you say, knowledge management of things like recipes or music.

Items could be part of one or multiple hierarchies. A list of "cake" recipes could be under both "baking" and "party essentials", and music playlists could include other playlists.

As you can tell, this can become convoluted in my mind, and so if that's something that's interesting to you (or anyone reading this), please reach out and let's discuss! hn at nestful.app

[0] https://nestful.app

Indeed, I was just staying in context :)

I research live-action anime[0] and this looks really cool, especially if there's fine-grained control over each sensor and especially if you can change the lenses (in a supported or unsupported manner).

Anime has the advantage of being drawn frame-by-frame, thus able to "change" lenses, cameras, etc mid action-packed shots. Using this may allow for shooting two different setups at once, achieving a similar effect.

[0]: https://www.youtube.com/@weedonandscott

I'll add Loro[0] to the author's list. While I utilise Yjs heavily for another project, Loro is fairly featureful and so I picked it to build a screenplay editor[1], which requires things like Peritext or tree structures. It's fairly young, though.

I'll also commend the author's attempt at DIY! Even if your case does not require a custom solution, it's healthy to understand how your tools work.

[0] https://loro.dev

[1] https://www.weedonandscott.com/tech/project-realm

I wouldn't say it's outright wrong, I just much prefer the ergonomics of an orderly, TEA-like state management. Many of the projects I make lend themselves well to that approach.

Yes, that is the major problem I have with TEA. The best thing about Flutter's design is that it employs a "reverse iceberg" where many of Flutter's own widgets are composed with other widgets, leaving few architectural details "under the ocean".

That experience is lacking in TEA, although better in immutable languages like Gleam where it is easier to keep functions pure. Even in Iced, I'm going to side with those Elm proponents here and prefer Elm's function composition approach any day over guarding React or Flutter state from becoming spaghetti.

After discovering and adopting[0] Lustre, I can't think of using anything other than The Elm Architecture. It is so much more ergonomic it's not even comparable to today's mainstream state management techniques.

I'm also building a screenplay editor prototype[1] in the Rust equivalent, Iced, and while not as ergonomic as Lustre and Gleam, it is TEA. Iced is still in flux but I have trust, considering System76 uses it to build Cosmic.

[0]: https://blog.nestful.app/p/gleams-lustre-is-frontend-develop...

[1]: https://www.weedonandscott.com/tech/project-realm

The evolution is Gleam + Lustre (its main FE framework).

You get all of Gleam's advantages compared to TS (simple, truly type safe, errors as values, exhaustive match, etc), and Lustre is great because you get an Elm that can be run on both the client and server, using whatever fits that specific part of your website best (unlike HTMX or LiveView which are server-only).

Wrote a blog post about it:

https://blog.nestful.app/p/gleams-lustre-is-frontend-develop...

Correct, these are all trade-offs we make when building a product. Choosing between the "1/0 crashes your program" problem and the "1/0 returns 0" problem is one such tradeoff.

All I was doing was clarifying the impression OP gave.

Now that we all know the details we can make whatever tradeoff we prefer.

You've missed the part of the internet where GrapheneOS resides

You'll find that keeping my client information's integrity is as important to me as keeping the financials.

That, however, is still not enough to alleviate OP's concerns, which is why I've explained how the `1/0=0` problem can be entirely avoided.

I expect entirely avoiding the problem OP mentioned is enough to alleviate the concerns it raises.

I use Gleam in production[0][1], and that is not really an issue.

Gleam offers division functions that return an error type, and you can use those if you need that check.

They fit a list-length use case well as they work better with a piping syntax which is popular in Gleam.

[0] https://nestful.app

[1] https://blog.nestful.app/p/why-i-rewrote-nestful-in-gleam

Thank you for the thorough explanation

Is anyone here using BTRFS and can comment on its current-day stability? I used to read horror stories about it

Isn't that what every technology was at some point?

I am a big fan of Gleam language's Lustre[0], and due to its functional nature, the full stack experience is much better.

Instead of becoming this mishmash of backend and frontend, there's a clear delineation between the two. They share common functionality via functions (like model and views), which is much easier to do when they're pure.

You basically get the advantages of those magic frameworks without all the magic.

[0]: https://blog.nestful.app/p/gleams-lustre-is-frontend-develop...

Strix Halo is rumored to be about twice as fast but unfortunately not near Apple's speed.

Every time there's a Bluesky or ATProto post I comment with how I think their killer feature is video.

Their smart use of domains makes it so that their equivalent of "channel" can be an actual website, that will offer you recommendations when you watch videos on it exactly like YT, except you control the algorithm.

Users will get much better choice and experience over the already excellent YouTube, but most importantly the creators will be able to express themselves however they wish. They will rent hosting from a provider, shows ads from an Adsense-like service, and actually own both their content _and_ their subscriber list.

I've been wanting to build it, but I'm always deterred by how ATProto is still tightly linked to Bluesky itself.

While this is generally true, is how I recommend to treat Slack, and how I treat it myself, the reality is that its nature is neither here nor there.

It's true that if you treat it just right, you're going to get an async tool. However, you want tools that are naturally like that. There are many foods I can fairly easily cut with a spoon, yet my experience is much better using a knife.

The mere fact you have to encourage to close Slack means it is used for something it shouldn't. Use evergreen communication for most communication, then use Slack only when you need it, which will be much much less.

Slack is also terrible at history preservation, see my reply to a sibling comment.

History preservation is not just about continued existence, but also about discoverability. Other forms of communication (issues, project planners, and email lists) are much better for the latter.

I'd say avoid slack as much as possible. Use evergreen communication:

https://www.emergencyremote.com/emergencyremote#h.vvx9who9kf...

Nice, I wonder when the third documentary will be out

Since the null-related blog post isn't published yet, anyone here knows the reason to implement null rather than write middle-layer in C# for whatever you want to use?

Isn't unified memory* a crucial part in avoiding signal integrity problems?

Servers do have many channels but they run relatively slower memory

* Specifically, it being on-die