Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
transmitic
Encrypted, peer to peer, file transfer program :: https://discord.gg/tRT3J6T :: https://www.reddit.com/r/transmitic/ :: https://twitter.com/transmitic
> it's encouraging to me that Rust's semantics allow borrow checking to keep getting better without breaking changes
Just to be clear, these are breaking changes. If the new borrow checker didn’t break existing code, they would have removed the old one long ago. They’ve just decided that the observable effects of the breaking change in the ecosystem are small enough (especially after warning about them for years) that they are okay making the breaking change without a semver-incrementing Rust 2.0.
To be fair, the reason for the breaking changes is generally to fix soundness issues, but that doesn’t cover all of them. There were some completely sound (albeit useless) examples of partial initialization that broke with NLL:
https://github.com/rust-lang/rust/issues/21232#issuecomment-...
https://github.com/rust-lang/rust/issues/54987
Strict adherence to semver would require still accepting this code.
I'm building WebAssembly bindings to existing Rust libraries [0] and lower-dependency geospatial tools [1]. Rust makes it very easy to bind rust code to both WebAssembly and Python. And by avoiding some large C geospatial dependencies we can get reliable performance in both wasm and Python using the exact same codebase.
> async runtimes cannot use this feature to provide borrowing across tasks
They can't use this specific feature, but with some duplicated unsafe code they can still provide similar APIs for their callers, right? Things like this: https://github.com/jaboatman/tokio-scoped
I'm building WebAssembly bindings to existing Rust libraries [0] and lower-dependency geospatial tools [1]. Rust makes it very easy to bind rust code to both WebAssembly and Python. And by avoiding some large C geospatial dependencies we can get reliable performance in both wasm and Python using the exact same codebase.
Keep in mind that I'm using "OS" here loosely; it's a bare-metal program that exposes a subset of Linux syscalls so that the interpreter (which itself is compiled for Linux) can run in the extremely strange context that we target. It's still early days so I won't spend too much time shilling it, but all the code is open source and lives under the umbrella of the Linux Foundation: https://enarx.dev/
https://table.dog (a CLI to download Stripe to SQLite).
I considered Node.js, C#.
I went with Rust for a few reasons:
- Easy to build small portable binaries (as a primary language feature).
- The type checker ensures type consistency when writing out to SQL tables (SQLite is loosely typed). Code that reads from the SQLite database implicitly benefits from Rusts strong type checks.
- Macros to convert structs to SQL insert/updates.
- Reduce the chance of errors at runtime.
- Leverage as much as SQLite's write throughput as possible.
- When converting Stripes Open API JSON spec into Rust code (using another Node.js program), the Rust type checker ensures I have a well formed HTTP client - the strict compiler makes it a good target for generated programs. Read more about this idea at (https://willcrichton.net/notes/rust-the-new-llvm/).
The Rust Programming Language book is usually the first thing people recommend.
> Do you find the 'stubbornness' of the compiler frustrating at all?
I actually love it. The more work I can offload to compiler the better. One simple example that frustrated me in Go was adding a field to a struct. You add the field the the whole thing still compiles even though the zero-initialized value probably broke your app logic. In Rust if I add a field to a struct, the compiler warns me about all the places that I need to double check.
> Would you mind sharing some of your experiences?
I highly recommend zero2prod book which is well-written, practical, but still teaches the essential principles (https://www.zero2prod.com/). You basically deploy a CRUD app to DigitalOcean from scratch. The best way to ramp up IMHO.
> How do you find the tooling?
Cargo is sweet. rust-analyzer is all I need. I need less extraneous tooling to be effective. For example, in Go I might use a task runner to watch the repo and run tests when I change a file. But in Rust I can just follow the rust-analyzer highlights and manually compile less-frequently.
> Also, I've considered Diesel for ORM, so was wondering if you've been using that too.
I was not happy with GORM (https://gorm.io/index.html) and never had a satisfactory experience with any ORM. I'm a fan of writing plain SQL, even in Go. It's just that with Rust sqlx I can get compile-time checks against the schema. It's not anything new (see Haskell), but it tightens the feedback loop and I have full control of the performance.
I've built a p2p file transfer program [0]. All my development experience had been in Python, but I really wanted to try a statically typed, low level language, and decided to give rust a try.
It was hard to get going, and I still only know basics, but everything just works! Typing, borrow checker, the matched results, all of that makes code bullet proof.