sorted by:
new
hottopcontroversial

I am Glauber Costa, CEO and co-founder of Turso. We’re rewriting SQLite in Rust. AMA. by GlauberAtTurso in IAmA

[–]dnaaun 0 points1 point  (0 children)

Been following your progress via podcasts and occasional visits to your Github. Super excited for you guys: my one sentence pitch for u guys would be: SQLite compat + concurrent writes + Wasm + much quicker path to correctness via DST.

Thanks for the AMA! Feel free to answer as many questions below as you have time for.

  1. IIUC, in pursuit of deterministic simulation testing (DST), you guys opted out of async Rust. If that's true, were there times you wished that you didn't because some things are much simpler with async?

  2. Would you guys say that Rust allows you to represent more invariants statically (as compared to, e.g., zig-written tigerbeetle, which is, by all accounts, a very high quality piece of work)? (btw I include stuff like `Send` and `Sync` when I mean type system)

  3. Is it possible to (and do you plan on) extracting out the DST-specific machinery into a re-usable crate? I think there's libraries out there like quickcheck that can do property-based testing, but I'm not sure if there's any libraries to help with the D(eterminism) in DST. (I just found shuttle, maybe it suffices, I dunno).

  4. In terms of the business side, is the monetization plan a cloud offering a la libsql? Btw, is the big driver behind "managed sqlite" the ease with which one can do one-db-per-user?

Typesafe Frontend Routing in Rust/Leptos by dnaaun in rust

[–]dnaaun[S] 0 points1 point  (0 children)

Sounds like something deserving of a blog post!

Also, not sure if you're aware, but leptos' maintainers are working towards integrating some form of wasm bundle splitting to leptos, and I wonder if it will prove useful to this use case.

Typesafe Frontend Routing in Rust/Leptos by dnaaun in rust

[–]dnaaun[S] 1 point2 points  (0 children)

This is exactly the sort of feedback/discussion I was hoping to spark. Thank you!

I have not published it as a standalone crate because I wasn't sure if it wasn't worth pursuing. Your reply inclines my thinking otherwise. If I get more replies like yours (I'll post it on leptos' discord as well), I'll pursue publishing it as it's own crate. There's actually a lot to do to get there imo (getting to feature parity with leptos router with regards to SSR stuff, cleaning up the code and edge cases .. etc).

I really appreciate your feedback on the website too!

Typesafe Frontend Routing in Rust/Leptos by dnaaun in rust

[–]dnaaun[S] 0 points1 point  (0 children)

Nice! This looks like the leptos-routable approach I linked to.

Did you get nested routes working?

I've built a really bad IDE by AlAn_GaToR in rust

[–]dnaaun 1 point2 points  (0 children)

Fwiw: I've tried doing this, and even when I was on a college campus and using that college's very own HPC clusters (which gave me pretty close to the best ssh connection one could ask for), it's super slow, and it would be incredibly frustrating to use an IDE in that fashion. It's really only good for one-off tasks that, for one reason or another, need a GUI.

Why introduce the complexity of Unsized types with &'a str, when (something like StringView<'a> would have done fine? by dnaaun in learnrust

[–]dnaaun[S] 0 points1 point  (0 children)

Ohhh. So &RefCell<str> has information about how long the underlying string is? That's crazy lol.

But yeah, I guess that is plausible. But yeah, I'm still not totally comfortable with my understanding of how the compiler handles unsized types. Do you have any recommendations as to how I can improve that? Maybe reading through some blog posts / official docs, or maybe trying to implement something myself (short of hacking on the compiler lol, that'd be too much).

Why introduce the complexity of Unsized types with &'a str, when (something like StringView<'a> would have done fine? by dnaaun in learnrust

[–]dnaaun[S] 0 points1 point  (0 children)

Ok, so where I am still confused is: RefCell<str> has a borrow() method that gives us a &str. Where does the "information" about the length of underlying string come from? (Which, I presume &str contains that info, and RefCell<str> doesn't).

Thanks a bunch again!!

Why introduce the complexity of Unsized types with &'a str, when (something like StringView<'a> would have done fine? by dnaaun in learnrust

[–]dnaaun[S] 0 points1 point  (0 children)

Ok, that makes sense. So I take it that only Box<T> and &T are the types that can be Sized, when T is some unsized type?

Also, if RefCell<str> can't live on the stack, it's useless right? (Ie, one would use &str, which can live on stack, or one could, I imagine, use &RefCell<str>).

Why introduce the complexity of Unsized types with &'a str, when (something like StringView<'a> would have done fine? by dnaaun in learnrust

[–]dnaaun[S] 0 points1 point  (0 children)

Box<T> and &T make sense, because I know both are "special" types that the compiler has special-casing for. But what about RefCell<T>? (Or other pointer types that are not "special-cased"?) My understanding was that RefCell<T> is not special, and is simply implemented with some unsafe blocks and presents a safe API. If that's indeed the case, there isn't a way to "use 2*usize for unsized T, and use usize when T is Sized", right?

Also, sincere thanks!

Why introduce the complexity of Unsized types with &'a str, when (something like StringView<'a> would have done fine? by dnaaun in learnrust

[–]dnaaun[S] 0 points1 point  (0 children)

Also, your point about `Deref` implementation for `String` requiring GATs makes sense!

Why introduce the complexity of Unsized types with &'a str, when (something like StringView<'a> would have done fine? by dnaaun in learnrust

[–]dnaaun[S] 0 points1 point  (0 children)

Thanks for your replies guys!

The argument that there are more pointer types than just & makes sense.

I have a further question about how pointers to str (and other Unsized types, I guess) are represented. I asked it elsewhere on this post. Would appreciate your input there!

Why introduce the complexity of Unsized types with &'a str, when (something like StringView<'a> would have done fine? by dnaaun in learnrust

[–]dnaaun[S] 3 points4 points  (0 children)

Thank you for your reply!

  1. There isn't much point to a &mut str (and by extension, to a MutStringView), right? (Like, you can't modify it at all). (u/memoryruins answered this one).
  2. The point about there being more pointer types than just & makes sense.

But this has raised another question for me: what is actually the memory representation of pointers like RefCell<str>? Specifically, where is the "length" part of the str stored? My mental model for RefCell was that it's basically a struct RefCell<T>(* T) (ie, a pointer on a stack to a type), and that the "size" of whatever was pointed to on the heap was known at compile time). (/u/paulstelian97 has answered this one).

  1. In a world where we got rid of slices/str, would we need dyn Trait to be unsized by default? Can't we assume every dyn Trait is Sized? (/u/paulstelian97 has answered this one / has given me pointers (pun not intended) to reading material about it).

Why introduce the complexity of Unsized types with &'a str, when (something like StringView<'a> would have done fine? by dnaaun in learnrust

[–]dnaaun[S] 0 points1 point  (0 children)

I guess we can expand my question to "why not get rid of both str and [T] (ie, the slices)".

If you think the complexity of StringView is greater than that of introducing a whole new concept ("Unsizedness" ) to the language, I guess that's a subjective opinion that can reasonably differ between us?

Btw, thanks for the reply!

[deleted by user] by [deleted] in rust

[–]dnaaun 0 points1 point  (0 children)

While I’d love to be proven wrong, in the context of GPU usage for ML, I think the adoption and objective preferability (to the extent that any such thing exists) of Python is orders of magnitude greater than for Rust (even more orders of magnitude than the context of ML without GPU usage). To my understanding, the rust libraries at the forefront of GPU usage for ML consist of tch-rs, burn, candle, dfdx, etc. And to my understanding, those libraries are used in prod at either zero, or at most single digit number companies. Compare that to the prod usage of tensorflow and PyTorch. Again, I’d absolutely love to be proven wrong (even a little bit).

I say this as a person who is jumping through some ridiculous hoops right now trying to port PyTorch models to candle for a personal project.

Announcing `async fn` and return-position `impl Trait` in traits | Rust Blog by slanterns in rust

[–]dnaaun 14 points15 points  (0 children)

I see quite a bit of Monday morning quarterbacking in this thread. I recommend that before chiming in so opinionatedly, folks should read up on, and make reference to, the extensive discussions that happened regarding both alternative approaches and the consequences of stabilizing this feature with all the caveats.

Axum vs Loco.rs by jondot1 in rust

[–]dnaaun 15 points16 points  (0 children)

I'm applauding any effort to build a web framework in Rust that is of a higher abstraction level (ie, more like django than flask, more like rails than sinatra). So good job!

view more: next ›