Live data from Hacker News

Viewing profile — carllerche

carllerche

HN member
Joined
Wed, Aug 11, 2010, 6:31 PM UTC
HN karma
1,717
Public activity
141 items

About carllerche

No profile information was provided.

Recent public activity

  1. comment
    Comment #49009085

    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 …

  2. story
  3. comment
    Comment #48955474

    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 compone…

  4. comment
    Comment #48955300

    > 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, exp…

  5. comment
    Comment #48955211

    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 wh…

  6. comment
    Comment #48955205

    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 cli…

  7. comment
    Comment #48954758

    The ORM is here: https://github.com/tokio-rs/toasty/ . Tighter integration between the two is on the near-term roadmap.

  8. comment
    Comment #48954637

    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 …

  9. comment
    Comment #48954010

    Don't remind me... I'm old. (I was involved w/ Ruby on Rails in the early days)

  10. comment
    Comment #48954006

    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 ri…

  11. comment
    Comment #48953842

    It's built: github.com/tokio-rs/toasty/, just not tightly integrated yet . That is on the roadmap.

  12. comment
    Comment #48953718

    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/ …

  13. comment
    Comment #48953619

    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.

  14. comment
    Comment #48953506

    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:…

  15. comment
    Comment #48953304

    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.

  16. comment
    Comment #48953091

    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 …

  17. comment
    Comment #48953076

    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 t…

  18. comment
    Comment #48846571

    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++.

  19. comment
    Comment #48140144

    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 us…

  20. comment
    Comment #48078091

    > 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 per…

  21. comment
    Comment #47736122

    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 aut…

  22. comment
    Comment #47736111

    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…

  23. story
  24. story
  25. comment
    Comment #46620210

    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…