carllerche

6 ms·

1.
Principles for Fast Tokio Applications(dial9-rs.github.io)
246 points by carllerche 2d ago|65 comments
2.
by carllerche 1mo ago
Topcoat (Rust) is aiming taking this approach as well: https://github.com/tokio-rs/topcoat . The project is still in the early days. It won't require WebSockets, but WebSockets will be an option.
3.
by carllerche 2mo ago
I know the repo was posted here a few days ago ( https://news.ycombinator.com/item?id=48952067 ). The intent was to open the repo at the same time as the blog post, but we ran out of private repo CI credits, so opened it up e
4.
Topcoat: A framework for building full-stack reactive web apps with Rust(tokio.rs)
8 points by carllerche 2mo ago|2 comments
5.
by carllerche 2mo ago
All on the roadmap :) topcoat-ui is already usable with Shadcn components (recent Pr: https://github.com/tokio-rs/topcoat/pull/118 ) we are still working on pulling in more components. Re: OpenAPi you want to
6.
by carllerche 2mo ago
> Will have to see if Toasty solves it and whether it lets one query for arbitrary structs and add fields to structs from query results (e.g., in the README example for Toasty, explicitly joining on TODOs and mapping them to a simple fie
7.
by carllerche 2mo ago
Topcoat is entirely server rendered. Reactivity is added using attributes and other signals to a JS “runtime” shipped with topcoat. It is a similar idea to htmx/datastar/hotwire where as Leptos uses wasm to run rust in the browser
8.
by carllerche 2mo ago
Depends on what you mean by that. Tokio the runtime is lean, and stable. Tokio the org is a collective of devs working on creating and maintaining a full ecosystem for building client and server apps with rust.
9.
by carllerche 2mo ago
The ORM is here: https://github.com/tokio-rs/toasty/ . Tighter integration between the two is on the near-term roadmap.
10.
by carllerche 2mo ago
Both Loco and Topcoat aims to be "batteries included" but that means very different things to each project. Topcoat aims to make it easy to build reactive apps without writing any browser JS (or Rust). It uses a similar strategy t
11.
by carllerche 2mo ago
Don't remind me... I'm old. (I was involved w/ Ruby on Rails in the early days)
12.
by carllerche 2mo ago
I don't take offense from differences in design opinion. The goal of topcoat is to be opinionated and not make everyone happy. And JS libs are a heavy inspiration. They do a lot right and have years of experience in the browser-app s
13.
by carllerche 2mo ago
It's built: github.com/tokio-rs/toasty/, just not tightly integrated yet . That is on the roadmap.
14.
by carllerche 2mo ago
Yes, that is the goal. Those frameworks have a bit (more than a decade) head start though :) there is a lot to build. There already is an ORM ( https://github.com/tokio-rs/toasty/ ). You can see a sketch of the road
15.
by carllerche 2mo ago
Roadmap: https://github.com/tokio-rs/topcoat/issues/104 ORM: github.com/tokio-rs/toasty It is early, a lot is coming, but you can already build good stuff now.
16.
by carllerche 2mo ago
Migrations: Done with Toasty ( https://github.com/tokio-rs/toasty/ ) which I intended to be integrated tightly with topcoat. You can see a rough roadmap here, which will be posted: https://github.com&#x2F
17.
by carllerche 2mo ago
I think it is highly likely topcoat / toasty will get split out. It is just work, especially since tokio-rs has more CI usage available than the default GitHub org.
18.
by carllerche 2mo ago
This will (very soon) integrate tighter with the Toasty ORM http://github.com/tokio-rs/toasty/ . E.g. tight form -> record flow. We are shipping now though to get usage. What pain points do you have in the Rust
19.
by carllerche 2mo ago
I didn't expect to see this here yet. We opened up the repo because we ran out of private CI usage. A blog post is coming next week :). Happy to answer questions here though. One thing to keep in mind, the main reason for Topcoat to ex
20.
by carllerche 2mo ago
Sounds like Andrew is using the same argument as Bjarne Stroustrup: if you use it right, you don't write bugs. It hasn't really worked out for C++.
21.
by carllerche 4mo ago
I don't think Rust vs. Zig has anything to do with why people are talking about this. It is a large piece of "real software" that underwent a full language transition in ~1 week using LLMs. That is a big deal regardless of th
22.
by carllerche 4mo ago
> On the other hand, Rust is a complex language prone to refactoring avalanches, where a small change in a component forces refactoring distant code. Are you saying this out of personal experience or just hypothesizing? I am working on a
23.
by carllerche 5mo ago
The most common reason is that a quick manual step is needed before publishing. Nothing malicious. Often it is just removing paths used during dev from Cargo.toml. Should it be automated? Sure, but that is extra work.
24.
by carllerche 5mo ago
I agree that position is nonesense. I mean, the single best defense against supply chain attacks is to bring everything in house. Is that reasonable? No…
25.
Toasty, an Async ORM for Rust(tokio.rs)
2 points by carllerche 6mo ago|0 comments
26.
Dial9: A flight recorder for the Tokio Rust library(tokio.rs)
4 points by carllerche 6mo ago|0 comments
27.
by carllerche 8mo ago
Help normalize saying no? As an OSS maintainer, the sense of entitlement many have is quite frustrating. After years in OSS, I have built up a thick skin and am fine saying no, but many aren't.
28.
by carllerche 8mo ago
I 100% agree with this. It also is 100% OK to fork aggressively and patch yourself.
29.
by carllerche 11mo ago
You are very confidently incorrect. So incorrect, it is hard to even start correcting you. * Inflation is not caused by "putting your money somewhere" What on earth. * At a high level, inflation is caused by either "too much
30.
by carllerche 2y ago
I doubt it. Eating healthy is already cheap and easy (rice & legumes as a base, fresh or frozen veggies based on what is cheapest at the time). It just doesn’t taste as good and gets boring fast.

More ›