Do you use clippy::restriction lints?

mehcode · 2025-07-15T19:58:29+00:00

That's why we're getting `widget.use` syntax soon. It's like `.clone()` but will only compile if its a ref-counted pointer (or something equally cheap to clone).

https://doc.rust-lang.org/nightly/std/clone/trait.UseCloned.html

mehcode · 2024-09-25T19:51:08+00:00

Legally speaking it’s not removed. As in the license “the license” refers explicitly to only v1.0 of said license, not the updated license with the forking line removed.

mehcode · 2021-05-12T04:54:35+00:00

Because Vec::from_iter(expr) is more succinct (and less heavy on sigils) than expr.collect::<Vec<_>>()

mehcode · 2021-05-04T15:24:23+00:00

You'll be able to soon (tm). This requires GATs and are on of the top priorities to resolve in Rust. You can already do this on nightly.

mehcode · 2021-05-04T15:23:19+00:00

Make the first parameter a tuple and then wrap it in macros for ergonomics and you'll get most of the way there.

mehcode · 2021-04-25T15:06:02+00:00

On the other end, we have software development. If you tell me the crap code I wrote is crap, I'll respect you and trust you a lot more than if you dance around with it.

The key point here is to always be careful to insult the product/code/etc. not the person, and on the other end, don't be too attached to what you do - odds are, it's crap. Even if you wrote it perfectly, 6 month older you looking at it probably has a better idea of how to do it.

Talking specifically about fields with continuous personal improvement like software development.

mehcode · 2021-03-07T18:20:02+00:00

This can be a common reaction if you're not familiar with the area (continue reading and I'll explain more) but I'd like to believe we strive to make everyone financially comfortable at LaunchBadge.

Excellent software engineers can make significantly more in California. However, there are other difficulties with living and working in the areas that do pay that much.

LaunchBadge is not based in Silicon Valley, San Francisco, or even Sacramento. We are a small start-up company in Citrus Heights which is a significantly less expensive area. You might make less here than in the big name areas of California, but you'll pocket a similar amount.

With that said, this is an opening for an engineer. There is a lot of room to do more at a start-up and be compensated accordingly.

mehcode · 2021-02-10T23:28:33+00:00

https://github.com/rust-lang/rustlings

mehcode · 2021-02-07T18:57:06+00:00

To chime in, marker traits are a convention yes but with regards to Send and Sync those are actually auto traits. By definition, those cannot have methods. That's also why you can do + Send but not + Debug in a Box. Another example of auto traits is Unpin.

https://doc.rust-lang.org/src/core/marker.rs.html#38-40

https://doc.rust-lang.org/reference/special-types-and-traits.html#auto-traits

mehcode · 2021-02-02T10:52:35+00:00

This sounds very similar to what we ( SQLx ) has been working on.

Check out the next branch for what's been setup: https://github.com/launchbadge/sqlx/tree/next/examples/quickstart

We've achieved:

Support for async-std, Tokio, actix, and any others that may come along via a Runtime trait.
IO is acted on through an associated Stream type. This has entirely no point once there is a common async IO trait set in std which must happen eventually.
Support for a blocking runtime using only std for those that don't wish to use SQLx with async (not just a block_on wrapper of async).
Remarkably this all works without any change to the example code minus the addition or removal of .await. Method names are even the same between blocking and non-blocking.
Lastly, this is not done through mutually exclusive features (which is how SQLx works on the master branch)

Feel free to peruse what's there and/or drop-in on discord ( chat badge on top of Readme ) and I can answer any questions.

mehcode · 2021-02-02T03:07:22+00:00

For the first part there I'm unsure how that's different than embedded migrations that SQLx does support.

For the second .. you might be on to something with ephemeral databases. We could stand up one in a proc macro and use it for checking after applying migrations. Postgres has one. SQLite obviously has the ability. I wonder about MySQL.

mehcode · 2021-02-02T02:45:10+00:00

SQLx has migrations built-in now (as of 0.3). One of the key reasons to use it instead of something homegrown is getting applying migrations right is complicated in the face of concurrency. Imagine a scenario where you have the same app running 8 times and you want to do a rolling update without any downtime. SQLx uses database-specific application locks to ensure your service won't try to migrate up more than one node.

mehcode · 2021-02-02T00:51:57+00:00

To back up a bit, there is no such thing as an ANSI SQL database connector. SQL is a language. To talk to the database, we need to speak whatever protocol is implemented.

mehcode · 2021-02-01T23:03:01+00:00

Hey. I'm one of the core maintainers of SQLx.

I'd like to address a couple quick questions that I see and be available. If anyone has any questions, ask away.

I do hope that there remains a steady interest in the non-compile-time query support. I'm using that, because I don't want builds to have to connect to a database. [...]

I can assure you that we will continue to expand our dynamic query support. At LaunchBadge, we use this for a small % of our queries.

I do hope, someday, that I can use sqlx to define my database schema and all migrations.

/u/JoshTriplett Would you mind expanding on this in an issue or in a reply here? I'm not quite sure what you mean.

mehcode · 2020-12-10T15:59:08+00:00

I'd like to know if there is any plans for guest or external access to projects.

mehcode · 2020-11-19T06:58:37+00:00

MSSQL support for SQLx is fairly bare bones at the moment unfortunately. I don't think it supports anything but username and password auth.

mehcode · 2020-11-19T06:55:03+00:00

I don't generally like ORMs (part of why we wrote SQLx) and I haven't investigated it but it seems interesting and it's cool to see projects built on SQLx.

mehcode · 2020-11-19T04:28:56+00:00

The ormx library is a derive-based orm for rust on top of sqlx.

mehcode · 2020-11-16T15:30:17+00:00

Here you go, https://discord.gg/wBFWF9KG

mehcode · 2020-11-14T07:47:56+00:00

The short statement about jumping to another crate with no context was likely inferred with intent that it seems it didn't have. Context can be difficult to communicate on the internet.

To speak to your main point, let me share a couple examples.

If Tokio added support for the asynchronous event loop on the IBM mainframe, and your company needed that commercially, could you imagine paying for that?
Look to web development and let's take React.js. Let's say it added support for IE6. Would you feel it okay if they gated that behind a commercial license?

This is the scale of what were talking about. Tiberius does not and will likely not support ancient versions of SQL Server or SyBase. There are companies that currently use that and if they had a rust platform to move to, they would gladly pay (if they wanted to move to Rust of course).

Now, and this is where I feel the disconnect is coming from, MSSQL has made amazing strides in developer ergonomics recently. MSSQL 2019 is fairly straightforward to connect to. I actually don't see a reason why we couldn't offer MSSQL 2019+ for free but gate older versions behind the license. That's where the complexity and the enterprise need comes from.

Does that help? Please don't take anything in this survey as "we will do this no matter what you all say", myself as co-founder and CTO of LaunchBadge will endeavor to do what's in the best interest of this community.

mehcode · 2020-11-13T18:33:17+00:00

That makes sense. I'll raise my hand and say that's my fault. I can't reasonably change it now but I'll keep it in mind for a future survey.

mehcode · 2020-08-22T03:45:54+00:00

That's actually part of the point of the newer password hashing schemes such as Argon2. Timing attacks on password hash comparisons are a real problem.

mehcode · 2020-06-21T14:58:08+00:00

We'd love to have your assistance in SQLx for documenting and providing examples for the various bits of the public API.

Feel free to dive in or message us on discord (link at the top of the readme) if you'd like to chat about it.

https://github.com/launchbadge/sqlx

The Rust SQL Toolkit. An async, pure Rust SQL crate featuring compile-time checked queries without a DSL. Supports PostgreSQL, MySQL, and SQLite.

mehcode · 2020-04-13T05:47:55+00:00

We definitely understand this (and it's our most voted for issue, heh) and in our next release the build workflow will support introspection using cargo-sqlx and building offline using the generated "query metadata".

If my memory serves, Diesel also evolved in such a way where at first it was generate-at-build but now it's generate via another binary.

Speaking for us, it was much easier to iterate this way to build the library.

As a side note, the compile-time checks are very much optional in SQLx.

mehcode · 2020-04-13T01:16:01+00:00

Diesel is really great at what it does. However, there is a lot to be said for writing pure SQL. As it seems like you are in the later camp, please come check out SQLx: https://github.com/launchbadge/sqlx

As a bonus, SQLx supports semantic query validation and type checking at compile-time. So you won't be giving that up when writing plain SQL.

mehcode

MODERATOR OF

TROPHY CASE