I think .NET and EF should handle navigation property nullabiloty better out of the box, especially when you explicitly set the foreign key to long?.

That said, while I understand these relationships in my own projects, adding clear annotations is very helpful for colleagues who may have to provide support in the future. That could even be me!

So there’s no perfect solution in this stack, but anything that makes a developer’s intent clearer helps. Privilege of least surprise, right?

Well, you still have to ! because it may, based on the annotation, be null.

Very handy, regardless. Microsoft’s docs on these attributes are very interesting, particularly the postconditionals.

An open source-ish corporate product is valuable in so much as it’s a vehicle for a paid service, right?

Interestingly enough, you also have amazon.co.uk, which combines the nature (commercial) and location served (UK), but in the opposite order.

But it could limit the usage of its TLD.

There’s a lot to talk about from this point alone, but I’ll be brief: having gone through university courses on processor design and cutting my teeth on fighting people for a single bit in memory, I’m probably a lot more comfortable with that minutia than most; having written my first few lines of C in 10 years to demo a basic memory safety bug just an hour ago, you’re way way ahead of me.

There are different ways to learn and gain experience and each path will train us in different skills. Then we build teams around that diversity.

There’s nothing like having your network go poof and knowing with 100% certainty that it’s your fault and you’re the only one who can fix it.

I threw together a quick image to ASCII conversion project to actually use a couple of concepts.

Sometime this week I’d like to make it not panic over every little thing. I feel like I should be shifting error handling left, but it’s not very natural for me, just yet.

I will say, the ergonomics for testing with cargo are excellent.

I said it’ll reduce friction, you said it might be easier. Looks like we’re in complete agreement, right?

This is super interesting. I’ll admit I wasn’t even aware of this effort. Even real-time usage of Windows relies on a parallel kernel.

This sounds like it’ll create a lot of cool opportunities and reduce friction.

We’ve all read this post multiple times. Isn’t it just the “young people are lazy” that’s been going around for thousands of years?

https://historyhustle.com/2500-years-of-people-complaining-about-the-younger-generation/

At most it’s a tangent on it…

I’m shocked and appalled! Isn’t the whole point of using Rust to prove you’re a better developer by using an extra hard language? At least that’s what I like about it.

I’m kidding, of course. Whoever has never copied and pasted code they didn’t understand from Stack Overflow can go ahead and complain about using a local LLVM.

Ultimately, what makes a good developer includes understanding and being really good with the tools they use, but the biggest impact comes from identifying problems and asking the right questions to solve them.

If you’re interested in learning more about SQL, throwing EXPLAIN at your query and the AI’s version may be really interesting.

I’m usually perfectly happy trusting my ORM, but even then it’s really helpful to dig a little deeper to figure things out, both in development and in production.

I used that and Rustlings and really liked both, but somebody mentioned this and I decided to take a look. It’s cool that it introduces other concepts.

I’m working through rust-exercises.com and taking notes on my thoughts. I may or may not want to use it for a short workshop at work - mostly for fun, since I work with a very different stack.

So far, I don’t know if I like the exercises, because the target audience doesn’t feel like it’s clearly defined: you both solve is_even with an if/else and overflow an i8 to -1. I don’t think I’ve met the person who is that inexperienced and that knowledgeable…

How are folks liking these exercises?

I’m inferring based on the deprecation of YEAR(4) and the conversion time window that obviously needs to be updated at some point.

To answer the part of your question I think is most fun, there is a standard for SQL. There are many dialects of SQL, but you’ll often hear of “ANSI SQL.” The latest version is SQL:2023.

Looking at the MySQL manual entry for the YEAR type, I think we can conclude two things:

1. The developers consider the possibility of deprecating and removing support for time data type features;

2. They use “reasonable defaults” for conversions of 2 digit years, based on the current year.

The good news is it sounds like this issue is being taken into account. I’m sure the conversion window will be adjusted in future version and the data type may be changed or deprecated altogether. I wouldn’t be surprised if they added a YEAR2 though. T-SQL has a datetime2, after all.

One of my main concerns with this is the potential for making a lot of separate calls to the DB for a complex data structure. Then again there are trade offs to any architecture.

The insert on their Getting Started guide.

let new_post = NewPost { title, body };

diesel::insert_into(posts::table)
    .values(&new_post)
    .returning(Post::as_returning())
    .get_result(conn)
    .expect("Error saving new post")

Of course the other possibility is this guide is very low on abstractions.

Just learning. I threw together a little CRUD API in Rocket the other day.

Now I’m playing around with Diesel. I don’t love the intermediate New types, coming from EF Core. Is that because Rust ~~~~doesn’t really have constructors?