4 ms·

Oxide is a startup and we use Rust for everything except the front end of websites (where we use TypeScript.) In some cases that’s due to hard requirements (emb

Oxide is a startup and we use Rust for everything except the front end of websites (where we use TypeScript.) In some cases that’s due to hard requirements (embedded) but we use it for web backend cases as well. Iteration time hasn’t been an issue, but compile times can be annoying. Though obviously compile time is related to iteration time. Of course, all of these things are anecdotal. Collecting anecdotes is how you develop evidence, of course…

efficax 4y ago
I'm also at a startup using rust. It's true that the feedback loop can sometimes feel bit slower. One thing that helps here is being test driven so that you're not waiting for compiles just so you can click through to confirm a small change in behavior. But in general I think my velocity is not much slower than it was at a previous company using a node backend. The hardest part of software isn't typing in the code and making sure it runs. It's thinking about what it should do and how it should do it in the first place. And really, Rust's type system is a force multiplier. We can prototype really fast, throw out things and rework them with confidence because with well thought out typing and tests to confirm logical behavior we have strong safety guarantees. It lets you experiment and investigate alternative implementations fearlessly.
faitswulff 4y ago
Do you mind my asking what frameworks you're using in Rust on the backend, if any?
- steveklabnik 4y ago
  We ended up building one https://crates.io/crates/dropshot https://crates.io/crates/dropshot Happy to talk about anything!
  - faitswulff 4y ago
    Oh this supports OpenAPI! That's exciting. I'll definitely check this out when I have a chance. Thanks!
    - steveklabnik 4y ago
      Yes, that was a primary motivation! We end up consuming it via typescript, and so you get typing info the whole way up and down the stack, which is very nice :) You’re welcome!
andrewstuart 4y ago
With all due respect, you’re Steve Klabnik. That makes “Rust at a startup” a different equation.
- steveklabnik 4y ago
  I am one of roughly 50. I'm pretty sure the rest of them are not Steve Klabnik. I also just work there, the all-Rust bit started well before I joined! That said, you are right that it's a point worth considering.
  - andrewstuart 4y ago
    >> I'm pretty sure the rest of them are not Steve Klabnik. We have only your word for this.
badrequest 4y ago
Steve, I just want to say I like you a lot. :)
- steveklabnik 4y ago
  Thanks, that's very kind.
ThatGeoGuy 4y ago
Tangram Vision [0] is also a startup and we also use Rust. We're using it to develop robotic / autonomous sensor calibration tools that would normally be written in a variety of C / C++ libraries. For context: most if not all of our team has developed calibration tooling similar to what we're doing now in the past, just at different startups and very specific to certain robotic or sensing configurations. If anything, once we got CI sorted and started using our own internal registry I would argue that we are significantly faster in terms of iteration time. This is partly because the team is small, but also because most of our tooling is consistent and easy to keep in lockstep. Pulling libraries is done uniformly across platforms and architectures, and our CI runs (through GitLab) stay up-to-date with the latest tooling without issue. Having a stronger type system to detect errors early and a compiler that actually tries to give human-readable messages (looking at you C++ linker errors) using that type system makes everything so much easier. Compile time seems like it would be an obvious bit that slows one down, but in practice sccache [1] does what it ought to and we barely notice it (at least, I don't and I haven't seen team members complaining about build times). Mostly I'd argue that the real thing holding us back is tooling extant to the rest of the wider Rust ecosystem. Debugging and perf tools are great in Unix land, but if you're making anything cross-platform you need to know more than just perf. That might just be my opinion though, I'll admit I'm still learning how best to apply BPF-based tooling even in Linux alone. I also realize I'm responding to steveklabnik, so I suspect most of what I'm saying is well-known and that this comment is really more directed at TFA. [0] https://tangramvision.com https://tangramvision.com [1] https://github.com/mozilla/sccache https://github.com/mozilla/sccache
- steveklabnik 4y ago
  Very cool! And yeah while I've had similar experiences, I'm glad to hear that it's so good for others. And, for example, sccache isn't something I have much experience with, so repeatedly hearing "it works well" is nice. (Also, secret of replying to people on the internet: you are often replying to the anonymous reader of the discussion as much, if not more, than to the person you're replying to.)

efficax 4y ago

I'm also at a startup using rust. It's true that the feedback loop can sometimes feel bit slower. One thing that helps here is being test driven so that you're not waiting for compiles just so you can click through to confirm a small change in behavior. But in general I think my velocity is not much slower than it was at a previous company using a node backend. The hardest part of software isn't typing in the code and making sure it runs. It's thinking about what it should do and how it should do it in the first place. And really, Rust's type system is a force multiplier. We can prototype really fast, throw out things and rework them with confidence because with well thought out typing and tests to confirm logical behavior we have strong safety guarantees. It lets you experiment and investigate alternative implementations fearlessly.

faitswulff 4y ago

Do you mind my asking what frameworks you're using in Rust on the backend, if any?

steveklabnik 4y ago
We ended up building one https://crates.io/crates/dropshot https://crates.io/crates/dropshot Happy to talk about anything!
- faitswulff 4y ago
  Oh this supports OpenAPI! That's exciting. I'll definitely check this out when I have a chance. Thanks!
  - steveklabnik 4y ago
    Yes, that was a primary motivation! We end up consuming it via typescript, and so you get typing info the whole way up and down the stack, which is very nice :) You’re welcome!

andrewstuart 4y ago

With all due respect, you’re Steve Klabnik. That makes “Rust at a startup” a different equation.

steveklabnik 4y ago
I am one of roughly 50. I'm pretty sure the rest of them are not Steve Klabnik. I also just work there, the all-Rust bit started well before I joined! That said, you are right that it's a point worth considering.
- andrewstuart 4y ago
  >> I'm pretty sure the rest of them are not Steve Klabnik. We have only your word for this.

badrequest 4y ago

Steve, I just want to say I like you a lot. :)

steveklabnik 4y ago
Thanks, that's very kind.

ThatGeoGuy 4y ago

Tangram Vision [0] is also a startup and we also use Rust. We're using it to develop robotic / autonomous sensor calibration tools that would normally be written in a variety of C / C++ libraries. For context: most if not all of our team has developed calibration tooling similar to what we're doing now in the past, just at different startups and very specific to certain robotic or sensing configurations. If anything, once we got CI sorted and started using our own internal registry I would argue that we are significantly faster in terms of iteration time. This is partly because the team is small, but also because most of our tooling is consistent and easy to keep in lockstep. Pulling libraries is done uniformly across platforms and architectures, and our CI runs (through GitLab) stay up-to-date with the latest tooling without issue. Having a stronger type system to detect errors early and a compiler that actually tries to give human-readable messages (looking at you C++ linker errors) using that type system makes everything so much easier. Compile time seems like it would be an obvious bit that slows one down, but in practice sccache [1] does what it ought to and we barely notice it (at least, I don't and I haven't seen team members complaining about build times). Mostly I'd argue that the real thing holding us back is tooling extant to the rest of the wider Rust ecosystem. Debugging and perf tools are great in Unix land, but if you're making anything cross-platform you need to know more than just perf. That might just be my opinion though, I'll admit I'm still learning how best to apply BPF-based tooling even in Linux alone. I also realize I'm responding to steveklabnik, so I suspect most of what I'm saying is well-known and that this comment is really more directed at TFA. [0] https://tangramvision.com https://tangramvision.com [1] https://github.com/mozilla/sccache https://github.com/mozilla/sccache

steveklabnik 4y ago
Very cool! And yeah while I've had similar experiences, I'm glad to hear that it's so good for others. And, for example, sccache isn't something I have much experience with, so repeatedly hearing "it works well" is nice. (Also, secret of replying to people on the internet: you are often replying to the anonymous reader of the discussion as much, if not more, than to the person you're replying to.)