emschwartz

Fascinating! Didn't know that

Just want to say that I appreciated this comment when I read it earlier in the day and when reading through the thread again just now.

> It's especially helpful to people who are both new to Rust AND come at Rust from language ecosystems with a garbage collector.

This is exactly the audience I was writing for so I'm very happy that you thought so.

Fair point. I could have placed a greater emphasis on ownership and mutability being two separate axes.

That said, I think you downplay the ways that references and mutability do interact in Rust. If there is a single outstanding reference to a value, Rust won't let anyone mutate the underlying value. I think this is quite an important part of Rust to understand that's not obvious to someone who's new and especially coming from a language that enforces no such guarantees about mutability.

Just updated that as well. Now they're smaller

Depending on what language you're coming from, I think that's totally fair.

A part of Rust that I very much appreciate is that once you write Rust code and get it to compile, there's a pretty good chance that it's going to do what you expect. As someone who is new to Rust, it's definitely no small feat to get the code to compile in the first place. But I think that's one of the main things people tend to love once they get over the initial hump of grokking all the different ways of passing variables around.

Ooh that's a fun question. I think it comes from reusing the C/C++ notation for references (https://stackoverflow.com/a/2094715/2242866). But I have no idea where the original idea for using those characters came from.

There's one other thing in Rust that would be kind of difficult if passing a reference were the default, rather than the owned value. Rust has implicit returns so the last thing at the end of a block or function is returned. If you needed to explicitly ask for ownership, you'd need to do that at the end of every function. Also, Rust will yell at you if you try to have a function return a reference to a value that's going to be dropped.

I removed the last two. Thanks for the feedback :)

Update: also made them smaller.

Done :)

Midjourney

Honestly, I thought they'd help illustrate the ideas. But maybe not! Thanks for the feedback :)

A little mental model I used to explain ownership and borrowing to someone who is new to Rust. I hope others find it helpful!

One of my colleagues keeps repeating “reliability is our number one feature”.

I’m not sure it is for 100% of early stage startups, but I guess it is once you exceed some minimum usage threshold.

That said, definitely appreciate the detailed explanation.

Ah, that is indeed a cool setup for a device on your home network :)

How do people tend to get metrics off of embedded devices?

I’m working on autometrics (https://github.com/autometrics-dev/autometrics-rs) and people asked whether it could be used in embedded contexts but I wasn’t sure how you’d hook up the device to something like Prometheus.

What about a dedicated site or app? For teams that use something like Slack, you could send an automated reminder to click a link and fill out the survey.

(Sorry if I missed that you had already tried or are planning those)

> If Sam’s lawyer had jumped in front of the camera and ripped Sam’s larynx out with his bare hands, he could reasonably bill it as extremely valuable and important legal services to his client.

Excellent line.

It seems Convex is about having data storage + client libraries that automatically react to changes without the developer explicitly making API calls and setting up subscriptions. On first glance it seems most useful for multiplayer apps, but maybe it’s more broadly applicable because of reactive web frameworks.

Question for frontend developers: would you agree that data management is one of the harder parts of using serverless platforms today? How does this compare with some of the other offerings out there?

Seems interesting. What’s the delta between what’s been implemented here and Phoenix LiveView?

https://remix.run/ and https://qwik.builder.io/ are two others.

I believe that React Server components is also heading in that direction.

Thanks! That’s what we’ll do :)

That's what we are currently doing. It's URL-safe but impossible to remember or type out so you need to copy the IDs around.

Good question.

I'm somewhat inclined to say if we're uniquely identifying resources with a unique, human-readable string, that's the ID you should always use to refer to things. It seems slightly more complicated to explain to users that there are these two ways to refer to things.

There's also the issue (or benefit) of keeping the UUID the same if you are able to change the human-readable ID.

The use case is a multi-tenant application where each organization has a set of plugins or integrations. Those integrations have associated config objects and maybe some other properties. Each organization might have some other resources that users create.

It seems somewhat nice to have resources that users create and interact with via an API + CLI to use identifiers that people can type out and remember instead of copying.

Unguessability isn't a big deal because all of these IDs can be namespaced under the organization ID and the auth check can just return a 404 instead of a 401/403 if the person doesn't have access.

Work chat. There have been many iterations of chat products for companies and Slack just did exactly what people needed it to do with a pleasant enough interface.

That said, the Slack vs Microsoft Teams numbers go to show the power of ecosystem integration and a widespread network of existing customers.

Good point -- thanks!

I guess the one case where it might still make sense to have the organization ID in the path is if users can be in multiple organizations and some APIs involve listing all of a given resource for a certain organization.

Thanks for writing that up!

I think it doesn’t quite answer what I’m after though.

I’m thinking less about resource discoverability and more about authorization and fetching resources from the database. For example, if the URL doesn’t include the post ID and I need that to check if the user is authorized to post a comment, I’d first need to look up the comment thread to get the post.

It is indeed. Could you explain why you’d recommend leaving it out in that case & what you’d recommend instead?

Thanks!

I think this argument refers more to Rust not having built-in support for async from the language’s v1.0 rather than the design of the Tokio stack. That has definitely led to unfortunate incompatibilities between libraries built for the different runtimes. However, the Rust language team took a super methodical approach to async support and the way that more async-related traits are slowly being standardized (first Futures and hopefully Stream, AsyncRead / AsyncWrite at some point in the not too distant future) seems like a long-term-great way of building into the language the abstractions everyone can get behind while leaving room for experimentation. I’m sure others would have different takes but I’m a fan.

The Tokio async stack for Rust (https://tokio.rs).

They did a really nice job of building thin layers up the stack from byte buffers (bytes), to async-friendly logging (tracing), basic IO (mio), async runtime (tokio), generic request/response services (tower), HTTP (hyper), and a web framework (axum).

Each of the layers are useful independent of the other layers above, and every one is has a thoughtfully designed, pragmatic interface.

Agreed. I can't recommend the course enough. They do a great job of simplifying multiple classes worth of material so you understand the key concepts quickly. If you haven't studied how computers are built up from logic gates, each of the lessons is mind-blowing.