Using smart pointers doesn’t eliminate the memory safety issue, it merely addresses one aspect of it. Even with smart pointers, nothing is preventing you from passing references and using them after they’re freed.

Would you have a link to that? I know there are many third-party garbage collectors for Rust, but if there’s something semi-official being proposed or prototyped I’d be most curious :)

Cool, that was an informative read!

If we were willing to leak memory, then we could write […] Box::leak(Box::new(0))

In this example, you could have just made a constant with value 0 and returned a reference to that. It would also have a 'static lifetime and there would be no leaking.

Why does nobody seem to be talking about this?

My guess is that the overlap in use cases between Rust and C# isn’t very large. Many places where Rust is making inroads (kernel and low-level libraries) are places where C# would be automatically disqualified because of the requirements for a runtime and garbage collection.

I think that’s very team/project dependent. I’ve seen it done before indeed, but I’ve never been on a team where it was considered idiomatic.

As a junior with no clue how to write production code, is Clean Code going to provide with a decent framework I can quickly learn to start learning my craft, should I throw it out completely because parts are bad, or should I read both Clean Code and all its criticism before I write a single line?

I see what you’re getting at it, and I agree we shouldn’t increase the load for juniors upfront. But I think the point is mainly there are better resources for juniors to start with than Clean Code. So yeah, the best option is to throw it out completely and let juniors start elsewhere instead, otherwise they are starting with many bad parts they don’t yet realize are bad. That too would increase cognitive load because they would need to unlearn those lessons again.

Also in Europe, but I’ve worked at 3 different startups before becoming a contractor earlier this year.

• First one I worked for 5,5 years, joined at ~30 people and saw things grow to 180 people at which point the company was sold and I left about a year after that.
• Second one I worked for 7 years, was one of the first employees and responsible for building their frontend stack as well as various microservices from the ground up. Company grew to about 80 people, but I left after Covid layoffs. I wasn’t one of the layoffs, but culture went to shit quickly after that.
• Third I was also one of the first people and helped build a pretty exciting architecture from scratch. Stayed for 3,5 years, but unfortunately the company never found market fit during that time and the team never grew beyond ~20 people.

Overall I can say:

• If you value autonomy and you have a getting-things-done mentality this is the right gig for you.
• Culture differs very much per workplace, you may need to be lucky. (I don’t think that’s unique to startups though.)
• You need to be assertive and pro-active.
• Don’t do it for the money. Startups usually pay less, but in theory make up for it by offering equity. But most startups fail, so in most cases this will never be more than theory. Even if you do get an exit, chances are the payout is less than you would’ve earned working those years for a bigger corporation.
• The experience can be extremely rewarding because you can easily reach a position of influence.
• You will learn a lot.
• The experience can be frustrating because there is always pressure and a lot to do and you rarely have the means to do it all.
• You will need to improvise a lot.
• If you pull it off and your startup becomes successful the thrill is exhilarating.

I thought we were talking about gamers and Linux users? :p

I have a Framework laptop (Intel GPU) with Arch and KDE, and while I’ve never seen all windows crash when connecting an external monitor, I wouldn’t call it out of the ordinary for one or two to crash after I connect one, especially if I try to drag one to a new position right after.

This is the real reason we have linters.

I absolutely agree with you. If I can avoid NPM I will indeed do so. Sometimes that means using Deno, but sometimes it can be a valid reason to avoid using the language altogether. And sometimes we have to suck it up 🤷‍♂️

As much as people like to make fun of JS/TS, I think you’re right, especially compared to the languages you mentioned. It’s my second-favorite language after Rust.

I think I would put Swift above it as well, except I don’t really use it since it’s too domain-specific in practice.

If you just have one or two required fields, with the rest being optional, it can also be a good middle ground to just pass the required fields to new() and use methods like in your example for the optionals.

PS.: A common convention for these methods is to prefix them with with_, like with_max_depth(max_depth: usize) -> Self.

Nah, more senior devs often also advocate for the quick fix, for the simple reason that the economics of a “proper” fix simply don’t add up, especially when you don’t know how much value such a fix would bring anyway. If you’re always looking to create “proper” solutions in hopes of someone in the future thanking you for it, it most likely means your priorities aren’t where they should be and it’s very unlikely someone will thank you for it.

I even wrote a blog on this topic: https://arendjr.nl/blog/2023/04/mvp-the-most-valuable-programmer/

Sorry, I don’t understand. Do you mean there have to be 6 digits of Pi in there, or the sixth character must be π? I’m down either way.

Sure! The other day someone called it emergent architecture. I guess it goes by multiple names :)

Can’t it be both? :)

Ah, fair :) then yeah, I’d say it’s pretty aligned with emerging architecture, just that I’m trying to define the values (and in the next post, technical guidelines based on those values) to (hopefully!) help you make the right decisions as you’re working on an emerging architecture.

I assume you’re referring to this blog series: https://medium.com/prospa-technology/emerging-vs-intentional-architecture-385071ae5d75 ? I wasn’t aware of it, and it seems to have some insightful observations! There’s definitely some overlap, but by the looks of it, I think I will diverge quite a bit with my next post. I think I’m pretty aligned on the “One-Way Decisions” vs “Two-Way Decisions” part. A One-Way decision in my mind would be, which programming language or framework do we use? Do we use REST or GraphQL?

But it doesn’t really go into how to deal with Two-Way decisions, apart from saying to trust your developers. And I think it kinda glosses over the part that things that may appear to be Two-Way decisions initially may actually be closer to One-Way decisions if you continue to build on them. So where that blog still focuses quite a bit on the process, I think I want to shift the focus a bit more to the technical side (so far I’ve mostly laid down the values that inform the technical direction), especially when it comes to Two-Way decisions. I wasn’t thinking about covering One-Way decisions much, but rather on how to shape everyday coding to be more in alignment with Post/Emerging architecture so that you can avoid the Two-Way decisions that in retrospect aren’t as much of a Two-Way decision as you’d hope.

Hope that makes sense :D

Thanks! This mirrors quite some experiences I’ve had over the years indeed. And for what it’s worth, I think the way you’re handling that is not bad at all.

As someone else mentioned in the comments on Mastodon, one of the hardest things about mentoring is articulating the lessons you may not even realize you’ve learned. I don’t think anyone can be blamed for failing to teach or convince someone else, since people are simply too different to be able to teach and convince them all. As you say, you have to pick your battles, and as long as you let your teammates do their work respectfully in their own way, that alone is a great achievement!

JSON patch is a dangerous thing to use over a network. It will allow you to change things inside array indices without knowing whether the same thing is still at that index by the time the server processes your request. That’s a recipe for race conditions.