diesel
rfcs
Our great sponsors
diesel | rfcs | |
---|---|---|
82 | 666 | |
11,930 | 5,700 | |
2.5% | 1.4% | |
9.5 | 9.8 | |
3 days ago | 5 days ago | |
Rust | Markdown | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
diesel
-
Top 10 Rusty Repositories for you to start your Open Source Journey
7. Diesel
-
People who use rust and postgres in production along with RDS proxy, what do you do?
Both seem nice. However, both of them rely very heavily on prepared statements. Unfortunately, using prepared statements is a no-go when you use connection poolers like pgbouncer, or in my case AWS RDS proxy. A discussion in Diesel indicates that disel is not going to provide any support for disabling prepared stements (https://github.com/diesel-rs/diesel/discussions/3575), and a discussion on sqlx hints that disabling prepared statements is possible, but I haven't found any documentation or examples for it.
-
The diesel project is looking for help
In addition we are experimenting with prebuild versions of diesel-cli that can be installed directly. We have a set of prebuilt binaries here. We are interested in feedback about how the provided binaries work on your platform.
-
cargo-dist pre-release looking for feedback!
First of all thanks for making this great tool. As it happens I currently toy around with using it for diesel-cli releases. See the WIP PR here. I think diesel-cli is a good example of a tool that depends on system libraries as it needs to link native database drivers, so this new release is welcome. Defining the dependencies seems to allow easily building things on x86_64-unknown-linux-gnu and x86_64-apple-darwin. It seems to pick up everything in the right way there.
- Diesel Is a Safe, Extensible ORM and Query Builder for Rust
-
Rust & MySQL: connect, execute SQL statements and stored procs using crate sqlx.
I did look at mysql initially. Then I started checking other crates. Diesel is an Object Relation Model (ORM), I'm not yet keen on taking on the complication of learning ORM, I give this crate a pass in the meantime.
-
Queryx: An Open-Source Go ORM with Automatic Schema Management
I would recommend people look at diesel from Rust for how nice it could be. https://diesel.rs/ Look at the complex queries example. So much more readable and easier to understand.
-
Diesel polls about upcoming features and guide topics
Most wanted missing features in diesel
-
Ask HN: Anyone Using Rust for Web Development?
There are two problems with using Rust for web servers:
1. The only production-ready Rust web servers require writing async request handlers. Async Rust is not fun.
2. The only good Postgres client library is async: https://crates.io/crates/sqlx
I'm trying to remedy the first problem with https://crates.io/crates/servlin .
Solving the second problem will be another project. I hope someone else does it. There is https://crates.io/crates/diesel but it has the same problem as async Rust: incomprehensible compiler errors.
-
/r/startrek/ migrates to lemmy
Lemmy is written in Rust using Actix Web and Diesel.rs.
https://actix.rs/
https://diesel.rs/
rfcs
-
Ask HN: What April Fools jokes have you noticed this year?
RFC: Add large language models to Rust
https://github.com/rust-lang/rfcs/pull/3603
- Rust to add large language models to the standard library
-
Why does Rust choose not to provide `for` comprehensions?
Man, SO and family has really gone downhill. That top answer is absolutely terrible. In fact, if you care, you can literally look at the RFC discussion here to see the actual debate: https://github.com/rust-lang/rfcs/pull/582
Basically, `for x in y` is kind of redundant, already sorta-kinda supported by itertools, and there's also a ton of macros that sorta-kinda do it already. It would just be language bloat at this point.
Literally has nothing to do with memory management.
- Coroutines in C
-
Uv: Python Packaging in Rust
Congrats!
> Similarly, uv does not yet generate a platform-agnostic lockfile. This matches pip-tools, but differs from Poetry and PDM, making uv a better fit for projects built around the pip and pip-tools workflows.
Do you expect to make the higher level workflow independent of requirements.txt / support a platform-agnostic lockfile? Being attached to Rye makes me think "no".
Without being platform agnostic, to me this is dead-on-arrival and unable to meet the "Cargo for Python" aim.
> uv supports alternate resolution strategies. By default, uv follows the standard Python dependency resolution strategy of preferring the latest compatible version of each package. But by passing --resolution=lowest, library authors can test their packages against the lowest-compatible version of their dependencies. (This is similar to Go's Minimal version selection.)
> uv allows for resolutions against arbitrary target Python versions. While pip and pip-tools always resolve against the currently-installed Python version (generating, e.g., a Python 3.12-compatible resolution when running under Python 3.12), uv accepts a --python-version parameter, enabling you to generate, e.g., Python 3.7-compatible resolutions even when running under newer versions.
This is great to see though!
I can understand it being a flag on these lower level, directly invoked dependency resolution operations.
While you aren't onto the higher level operations yet, I think it'd be useful to see if there is any cross-ecosystem learning we can do for my MSRV RFC: https://github.com/rust-lang/rfcs/pull/3537
How are you handling pre-releases in you resolution? Unsure how much of that is specified in PEPs. Its something that Cargo is weak in today but we're slowly improving.
- RFC: Rust Has Provenance
-
The bane of my existence: Supporting both async and sync code in Rust
In the early days of Rust there was a debate about whether to support "green threads" and in doing that require runtime support. It was actually implemented and included for a time but it creates problems when trying to do library or embedded code. At the time Go for example chose to go that route, and it was both nice (goroutines are nice to write and well supported) and expensive (effectively requires GC etc). I don't remember the details but there is a Rust RFC from when they removed green threads:
https://github.com/rust-lang/rfcs/blob/0806be4f282144cfcd55b...
-
Why stdout is faster than stderr?
I did some more digging. By RFC 899, I believe Alex Crichton meant PR 899 in this repo:
https://github.com/rust-lang/rfcs/pull/899
Still, no real discussion of why unbuffered stderr.
- Go: What We Got Right, What We Got Wrong
-
Ask HN: What's the fastest programming language with a large standard library?
Rust has had a stable SIMD vector API[1] for a long time. But, it's architecture specific. The portable API[2] isn't stable yet, but you probably can't use the portable API for some of the more exotic uses of SIMD anyway. Indeed, that's true in .NET's case too[3].
Rust does all this SIMD too. It just isn't in the standard library. But the regex crate does it. Indeed, this is where .NET got its SIMD approach for multiple substring search from in the first place[4]. ;-)
You're right that Rust's standard library is conservatively vectorized though[5]. The main thing blocking this isn't the lack of SIMD availability. It's more about how the standard library is internally structured, and the fact that things like substring search are not actually defined in `std` directly, but rather, in `core`. There are plans to fix this[6].
[1]: https://doc.rust-lang.org/std/arch/index.html
[2]: https://doc.rust-lang.org/std/simd/index.html
[3]: https://github.com/dotnet/runtime/blob/72fae0073b35a404f03c3...
[4]: https://github.com/dotnet/runtime/pull/88394#issuecomment-16...
[5]: https://github.com/BurntSushi/memchr#why-is-the-standard-lib...
[6]: https://github.com/rust-lang/rfcs/pull/3469
What are some alternatives?
sea-orm - 🐚 An async & dynamic ORM for Rust
rust - Empowering everyone to build reliable and efficient software.
sqlx - 🧰 The Rust SQL Toolkit. An async, pure Rust SQL crate featuring compile-time checked queries without a DSL. Supports PostgreSQL, MySQL, and SQLite.
bubblewrap - Low-level unprivileged sandboxing tool used by Flatpak and similar projects
rustorm - an orm for rust
crates.io - The Rust package registry
rbatis - Rust Compile Time ORM robustness,async, pure Rust Dynamic SQL
polonius - Defines the Rust borrow checker.
r2d2 - A generic connection pool for Rust
Rust-for-Linux - Adding support for the Rust language to the Linux kernel.
rusqlite-model - Model trait and derive implementation for rusqlite
rust-gc - Simple tracing (mark and sweep) garbage collector for Rust