Exactly! My code has a handful of “expect()” calls in it, and each one self-documents why it’s okay. It’s like a comment, but it appears in logs if it ever triggers.

Exactly. If there’s only one thing I could bring from Rust into another language, it would be Mutexes. It’s so nice to guarantee safe access to data.

I kind of disagree here. .lock() has the following behavior:

• panic() if the lock is already held by this thread - should never happen
• error - if the current lock holder paniced

The second case is incredibly rare, so it’s one of the few cases where I think .unwrap() makes sense in production code. But it should be an option to handle it in robust code that should never go down. This is rare, but it’s not so rare that we should force all locks to exist in a context where we can recover from panics.

.try_unlock() should never exist because there should only be one way to release a lock: drop(). Having a way to maybe unlock a mutex adds a ton of issues. If we assume this was a typo, .try_lock() absolutely exists, and it’s for a non-blocking lock.

Sure, but I guess I don’t really understand the argument. Why would Rust need to be involved earlier in the process? Isn’t the point to have a way to compile rustc completely from source?

I guess it’s cool to have multiple ways to get there, but that project would take way less work and get to the same end goal. It sounds to me like the author is trying to justify a cool project instead of trying to solve a real problem. That’s completely fine, but I think most people would be happy with the mrustc project.

It seems it would be a lot easier to work on the GCC compiler, and work with others to bootstrap GCC (if it hasn’t already been done). Getting the GCC Rust compiler able to compile some version of rustc probably wouldn’t be that hard, and then you can just use that version to compile up the chain to modern Rust.

IDK, I think snakes would also eat a crab, not sure about dragons. I don’t trust either, you’ve got to be on your guard when you’re this delicious.

I don’t think crustaceans should be trusting a cephalopod. Seems kinda sus…

Yup, our webapp has a bunch of security advisories in our NPM packages, but we only use node.js for the build step, so most are completely irrelevant since they only matter in a server context. It’s valuable to keep the alerts to a minimum so we don’t miss something important (e.g. an XSS vulnerability), but it’s not critical.

Exactly. A “supply-chain attack” is a very real thing in software, and it doesn’t really matter whether you consider yourself a supplier, the fact remains that something a product relies on had a security vulnerability that resulted in the product getting pwned. Nobody should be claiming that the unpaid developer maintaining that library that resulted in the vulnerability is somehow at fault in any legal sense because the license specifically states there is no warranty etc, but it is useful to point to that library as having that vulnerability to let other organizations know where the problem originated so they can either fix or replace it.

So I guess musl/busybox/Linux?

And yet, if someone asks, I will link it. I’m not proud of it, but I am helpful to a fault.

Ok, but what if there isn’t any GNU? Musl/Linux?

Woo! Learn you a Haskell for great good.

Well, it’s certainly more interesting than an email client, consider yourself lucky.

Isn’t the reverse true? If you make separate models for each query, the ORM knows exactly what data you need, so it can fetch it all as once. If you use generic models, the ORM needs to guess, and many revert to lazy loading if it’s not sure (i.e. lots of queries).

That’s at least my experience with SQLAlchemy, we put a lot of effort in to reduce those extra calls because we’re using complex, generalized structures.

Ah, I see. So you’re expecting to have one object for creation, updates, queries, etc.

I work with something like that at work (SQLAlchemy in Python), and I honestly prefer the Diesel design. I build an object for exactly what I need, so I’ll have a handful of related types used for different purposes. In Python, we have a lot of “contains_eager” calls to ensure data isn’t lazy loaded, and it really clutters up the code. With Diesel, that’s not necessary because I just don’t include data that I don’t need for that operation. Then again, I’m not generally a fan of ORMs and prefer to write SQL, so that’s where I’m coming from.

That’s too bad, I was thinking of replacing our nginx proxy with Rust. We need a little logic, so we currently have nginx -> gateway service -> microservice, and I was hoping to drop nginx. Maybe I still can, but it sounds like there would be some tradeoffs.

Can you give an example? Pretty much everything in Diesel is abstracted away through trait macros.

The only thing worse than a bad example is documentation like this:

fn do_thing(…)

Does thing.

It adds nothing, other than letting you know they were there and decided not to actually provide something useful.

Looks like a pretty small release, at least from the user’s perspective. Congrats to everyone that worked on it!