oDot

This fairly easily achievable with a tool I built called Nestful

https://nestful.app

Nestful is built on a different but similar premise called Spontaneous Productivity:

https://blog.nestful.app/p/spontaneous-productivity

Very much so!

I've created Vleam[0] to convert an existing vue webapp[1] and so far it's a joy.

[0]: https://github.com/vleam/vleam

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

I wish Intel success in bringing much needed competition to AMD in this ironic turnaround. However, after how they fumbled previous gen's warranties, I could not bring myself to buy their products for a few good years

Exactly right. Sometimes those "higher quality" things may lead to reduced quality, most commonly by reaching the uncanny valley.

Interestingly that does not happen in the opposite direction. When "reducing" certain stats on real footage (which is what live-action anime should do[0]) the uncanny valley is skipped. Maybe it's harder to fall into when going backwards? More research is needed.

BTW, I love your books

[0] https://www.youtube.com/shorts/3ZiBu5Il2eY

I spend a lot of my time researching live-action anime[0][1], and there's an important thing to learn from Japanese animators: sometimes an animation style may seem technically lacking, but visually stunning.

When animator Ken Arto was on the Trash Taste podcast he mentioned how Disney had the resources to perfect the animation, while in Japan they had to achieve more with less.

This basically shifts the "what is good animation" discussion in ways that are not as clear from looking at the stats.

[0] https://blog.nestful.app/p/ways-to-use-nestful-outlining-ani...

[1] https://www.youtube.com/watch?v=WiyqBHNNSlo

You're right about the lack of FFI-specific docs, but Gleam is such a simple language that it's very workable.

I wrote Vleam[0], which allows writing Gleam inside Vue SFCs, and the experience was pretty good even without the docs.

You do have to sometime read the source of other Gleam packages to understand how things work, but again -- Gleam is so simple it's not too bad of an experience.

[0]: https://github.com/vleam/vleam

I could see why this rubs you the wrong way.

I have never thought of its origins before, but I'd assume it's a short hand for "live-action anime adaptation". Maybe this makes it more palatable for you?

As for Animatrix, yes -- it really went full circle, considering how they pitched the original feature:

> When Larry and Andy Wachowski were pitching The Matrix to their producers, they played them a DVD of an 82-minute Japanese cartoon and said: "We wanna do that for real."

https://www.theguardian.com/film/2009/oct/19/hollywood-ghost...

No, not quite my day job yet.

I have stopped watching the live-action Cowboy Bebop after about 5 minutes, so much of it was spared.

The same production company (Tomorrow Studios) is currently making the live action One Piece, which, ironically, could be more detrimental to live-action anime than Cowboy Bebop was.

The reason is that even though the live-action One Piece is not something I'd consider live-action _anime_, it's actually quite good and is definitely well received, which may cause producers to adopt its formula, and stop researching alternative adaptation paths.

Live-action anime is an oxymoron commonly used to describe live-action film or TV series based on anime or manga, or having similar style to them.

The term is not well-defined.

You could say it applies to Ghost in the Shell, because it is based on existing IP of the genre.

You could stretch it to include The Matrix, which is an original IP but employs a lot of the style

Edge of Tomorrow, even though based on a Japanese light novel, has deviated enough both in plot and style for the term not to apply

I spend most of my time writing and researching live-action anime, and I can say that for it to really blow up, there needs to be a paradigm shift.

Currently many of the efforts are trying to fit a peg into a square by either "westernizing" the content, as done in Hollywood, or completely jumping the shark as with most Japanese releases. Both only make for a less palatabl result.

Instead, a selective "offset" approach should be taken. I illustrate this briefly in a YouTube mini-essay:

https://m.youtube.com/watch?v=WiyqBHNNSlo

It is also how I write my IP:

https://www.weedonandscott.com/narrative/keepers-of-alteria

And it's how I assess exiting IPs for adaptation.

Until current stakeholders shake the current models out of their system, this field is leaving a lot of creative output (and profits) on the table.

DHH mentioned they built it to move from the cloud to bare metal. He glorifies the simplicity but I can't help thinking they are a special use case of predictable, non-huge load.

Uber, for example, moved to the cloud. I feel like in the span between them there are far more companies for which Kamal is not enough.

I hope I'm wrong, though. It'll be nice for many companies to be have the choice of exiting the cloud.

Gleam compiles to JavaScript, so JS is not needed for that extra frotnend flare.

The flexibility to sprinkle some code here in there is definitely unique to JS

IMO the biggest hurdle in frameworks like Svelte or Next isn't the framework -- it's the language.

This type of app is a prime use case for something like LiveView or a Go framework. Just today I had the most marvelous experience using Tailscale's ACP, where I've changed the ACL and it instantly saved it. It was so fast I had to make sure it's not optimistic UI, and sure enough, 78ms round trip for the request.

Even if it was a FE-heavy app using SQLite in the browser, I wouldn't have used JavaScript. After months of Gleam, I am spoiled.

The days of JavaScript-because-we-have-to are thankfully over. JS is now only for when the flexibility is required.

Exactly right.

Watch apps will compete on consumer-facing features like the recommendation algorithm -- maybe they'll offer several, or just one that differentiates them.

Hosting providers will compete on producer-facing features, like advertising, content policies, analytics, etc.

If a user is displeased with either, they can take all of their content/activity history and leave.

It didn't sink in yet that the killer app for ATProto is not Twitter, but YouTube.

If anyone is interested in exploring this, atproto [does this fool ai bots?] weedonandscott [I hope it does] com

I rewrote my webapp, Nestful[0], in Gleam.

I use it in Vue components with Vleam[1]. About half of the frontend is rewritten at the moment, and it is a joy to use.

I'd do it again just for the error handling.

[0] https://nestful.app

[1] https://github.com/vleam/vleam

Yes, he's a fantastic storyteller

I have been using Gleam on the frontend in production, together with Vue[0] and I can confirm it's a joy to use.

Simplicity is such an advantage for a young language.

[0] https://github.com/vleam/vleam

I own https://Nestful.app which I made for myself.

Nestful is first and foremost a "what should I do next" todo app, but I've found I've been using it instead of Obsidian, even though the note-taking features are much less superior.

This made me wonder if some people are document people, and some are list people. If such a classification exists, I'm definitely the latter.

This is my current mental model for picking a language, considering just the language itself:

- Backends: Gleam or other BEAM

- Web frontend: Gleam

- Mobile apps: Dart + Flutter

- Specialized mobile apps: Swift and Kotlin

- Blazing fast: Zig

- Blazing fast and safest: Rust

- Fast performance and iteration: Go

Would love to hear additions and corrections.

My only problem with this is I'm not a fan of Go's syntax and I wonder what's a good alternative. Heared good things about OCaml but didn't check it out yet.

A lot of Tailwind's value comes not from the utility classes, but from the design system they enforce on the user, which is the most valued feature Tailwind offers, in my opinion.

Your question is partly why I moved to Nix after many years with Arch -- a perpetually clean install

It does! Uses the `lang` tag to check which one is it

I wrote Vleam[0], which is the equivalent to this, but for Vue and Gleam.

The more options like this, the better. Especially for existing ecosystems.

[0] https://github.com/vleam/vleam

Gleam is a very fun language to write in, and no need to start a project from scratch to explore it

I wrote Vleam to help incorporate Gleam into a Vue project, if you have one already

https://github.com/vleam/vleam

It's not only the language itself, but also the way it lends itself to the developer.

I've been using Gleam in Vue[0] for my task app Netful[1] and it surprisingly reduced a lot of the jank, because... it's sync.

Awaits are used very often for things that shouldn't be used for and have compounding overhead.

[0] https://github.com/vleam/vleam

[1] https://nestful.app/

I rewrote large parts of my webapp, Nestful[0], in Gleam.

It's truly a joy to use and the community is very nice. Some features are still missing (e.g, reflection), but I do agree, as a user, with the focus they're putting on the developer experience, as evident is this release.

If anyone else has a Vue application they want to dabble with Gleam in, do check out vleam[1].

[0] https://nestful.app

[1] https://github.com/vleam/vleam

vleam does not use Vue's `<script setup>`, but instead transpiles to a regular `<script>` block, so it does not rely on specialized syntax.

It works surprisingly well, and Gleam, being such a simple language, is a joy to code in. The main issues are honestly vleam itself -- the LSP is a bit finicky and the Vite plugin needs more work, as it sometimes requires a full restart and tends to transpile excessively. I expect most of this to be solved soon enough.

As for concurrency, the `fetch` usage example sums it up fairly well:

https://github.com/gleam-lang/fetch/tree/main

That's what I used, indeed not very comprehensive

That's a great idea, thanks for sharing