Mastodawn

Day 8 of learning Rust as a C# dev:
Ownership is the most C++-ish thing I’ve seen in Rust, and I actually love it.
It’s strict, it’s smart, and it makes you think before you move anything.

https://woodruff.dev/ownership-in-rust-the-most-c-ish-thing-ive-loved-and-i-mean-that-in-a-good-way/

#RustLang #CSharp #DotNet #LearnRust #RustForCSharpDevs

Ownership in Rust: The Most C++-ish Thing I’ve Loved (and I Mean That in a Good Way) - Chris Woody Woodruff

Let’s get one thing out of the way: as a C# developer, I’ve never had to think too hard about memory. The garbage collector (GC) is always there, lurking in the background, sweeping up after my code, like a very polite, very invisible butler. But Rust? Rust doesn’t do garbage collection. There’s no GC.Collect(), no memory profiler needed to chase leaks from forgotten Dispose() calls. Instead, Rust gives you something bold, powerful, and… at first, kind of intimidating: Ownership. Today’s post kicks off Week 2 of my Rust adventure, and it’s all about how this one idea changes everything.

Chris Woody Woodruff

Show thread

D. Moonfire 2h ago

@maxitb I find that MSDI is good enough for 80% of my work but the more complex setups are painful.

Modular setups is the biggest reason I've defaulted to Autofac. MSDI doesn't have a baked in method for "and include DI from this project". There are extension libraries that do it but not in the core. Nor ones that give me options to extend registrations (like adding CLI commands from an assembly) or replace (having default services, then replacing them with mock or test ones).

Mostly I use that to have a single point of setup. In Nitride (my ecs ssg), I have extension methods to pull in features like Gemini, feeds, or front matter processing.

The second reason is because I do a lot of registration by interfaces. In Nitride, all of the operations are pulled in by reflection so I don't have to list each one. Autofac makes that easy, MSDI requires another library to do that.

Third is partial DI. I like Autofac's delegate handling that let's me provide some parameters for a service but then use DI for the others constructor parameters. I'm not aware of a MSDI library that does that but I know verbose techniques to do it. That let's me create a service that takes a UserId and have it passed into the constructor along with ILogger and other DI injected components.

Fourth is ascetics (much like my frustration with MS logging). MSDI's method calls are verbose on the consumption side but terse on the registration. I prefer the reverse.

Ultimately, I don't enjoy using MSDI as much as Autofac. I'm trying to convince myself to accept MSDI but I find I keep hitting its limitations or have to jump though excessive hoops compared to Autofac (such as setting up unit testing, nested scopes). And if I have to use a library to get the features I want, it seems logical to use one library that does everything cohesively across all my projects instead of making that choice per project.

That all said, I'm still trying to write my CLI library to only use MSDI and MSL (because I prefer Serilog also for the same reasons). It is painful but also a chance to see if the DX has improved since last time.

#CSharp

MTG:Toulouse 3h ago

.NET Testing : pushing the Limits et Roslyn: compiler-as-a-Service

12 mai 2025, 19:00:00 CEST - GMT+2 - La Cantine by La Mêlée, Toulouse

https://mobilizon.mtg-france.org/events/00862bef-84fc-4800-8e9a-7dd0a7bfa282

.NET Testing : pushing the Limits et Roslyn: compiler-as-a-Service

12 mai 2025, 19:00:00 - GMT+2 - La Cantine by La Mêlée, Toulouse - 📅 Sans doute le dernier meetup de la saison 2024/2025, on se retrouve de nouveau pour une session focus .NET une semaine avant la MS Build (et nous on ne parlera pas d'IA 😅). 💬 Deux présentations avec…

Edaqa Mortoray 7h ago

I find C#'s features to always somehow be incomplete. For example, I can declare a class without a constructor, like below, and use new HandInfo{... to create with names. However, it doesn't work nullable: enable, thus I have to revert back to manually creating a constructor.

#csharp

D. Moonfire 10h ago

Played a few hours of Palworld with Child.0.

Also worked on my C# CLI parsing library. Mostly I worked out some ideas and patterns to make sure they fit. One implementation I'm doing is based on C#'s XElement pattern:

var root = new ComponentCliCommand(
  new ValueCliOption<string>("option"),
  new ValueCliOption<int>('n', "number"),
  new SwitchCliOption("help"),
  new CliHandler(_ => Console.WriteLine("I ran a command!"));

Since the entire purpose is to make this DI-friendly and also Autofac-module friendly, all of the classes and subclasses can be extended and then added into the service provider.

public RootCommand(IEnumerable<IMyLocalVerbs> verbList, CurrentDateOption currentDateOption)
  : base(currentDateOption)
{
  this.AddRange(verbList);
}

So far, the pattern seems "reasonable"?

I can also easily convert a reflection-based version of the command and convert them into components, which would let me do a CommandLineParser-style command object. And the handler (CliHandler) doesn't have to be in the same class (though I prefer it does).

#CSharp

TechKeysX 20h ago

RegEx Match and IF statement in PowerShell Tip #44 #softwareengineering #PowerShellScripting #coding #CodingForBeginners #LearnPowerShell #Scripting #softwaredeveloper #csharp #bash #linux #PowerShellTutorial

Felix Palmen

22h ago

Today, I implemented the #async / #await pattern (as known from #csharp and meanwhile quite some other languages) ...

... in good old #C! 😎

Well, at least sort of.

* It requires some standard library support, namely #POSIX user context switching with #getcontext and friends, which was deprecated in POSIX-1.2008. But it's still available on many systems, including #FreeBSD, #NetBSD, #Linux (with #glibc). It's NOT available e.g. on #OpenBSD, or Linux with some alternative libc.

* I can't do anything about the basic language syntax, so some boilerplate comes with using it.

* It has some overhead (room for extra stacks, even extra syscalls as getcontext unfortunately also always saves/restores the signal mask)

But then ... async/await in C! 🥳

Here are the docs:
https://zirias.github.io/poser/api/latest/class_p_s_c___async_task.html

#C #coding

poser: PSC_AsyncTask Class Reference

Chris Woody Woodruff 1d ago

Week 1 of learning Rust as a C# dev:

Fewer keywords. Stricter rules. More thinking.
Rust’s minimalism doesn’t just simplify, it reshapes how you code.

Here are my takeaways from the first 7 days:
https://woodruff.dev/reflections-on-week-1-rusts-minimalism-hits-different/

#RustLang #CSharp #DotNet #LearnRust #RustForCSharpDevs

Reflections on Week 1: Rust's Minimalism Hits Different - Chris Woody Woodruff

Seven days into learning Rust, and I feel like I’ve been through a developer bootcamp with a compiler that doubles as a personal trainer. It doesn’t let you slack, but it does make you better. This week, I went from installing the toolchain to wrestling with immutable variables and puzzling over semicolons in return statements. As a C# developer, I expected syntax differences, but I didn’t expect the philosophical shifts. Let’s recap what stood out, what stung, and why I’m still excited to keep going.

Chris Woody Woodruff

Habr 1d ago

Искусство Unit-тестирования: Сокращаем Arrange до Нуля

Unit-тесты очень важно и нужно писать, но вот незадача — на них никогда не хватает времени! Прочитав эту статью, вы узнаете абсолютно новый способ их написания, который сэкономит кучу времени и нервов. Эта статья будет полезна .NET разработчикам, которые когда-либо сталкивались с написанием unit тестов, а также тим и техлидам в поиске оптимальной практики для своей команды.

https://habr.com/ru/companies/ruvds/articles/894522/

#unit_tests #csharp #dotnet #autofixture #xunit #autodata #ruvds_статьи

Искусство Unit-тестирования: Сокращаем Arrange до Нуля

Хабр

Chris Woody Woodruff 1d ago

I'm learning Rust from a C# developer's perspective—one day at a time for 42 days.

I have 36 days left.

If you're curious how Rust stacks up against .NET, follow along here:
https://woodruff.dev/from-c-to-rust-a-42-day-developer-challenge/

#RustLang #CSharp #DotNet #LearnRust #RustForCSharpDevs #42DaysOfRust

From C# to Rust: A 42-Day Developer Challenge - Chris Woody Woodruff

I’ve spent over a decade writing C# and building solutions on .NET. But for six weeks, we will step outside the managed world of garbage collection and runtime JIT to dive headfirst into Rust—a systems programming language that promises performance, safety, and no nulls. Over the course of 42 days, we will learn something new about Rust every single day. We will fight the borrow checker. We will make mistakes. And I will blog it all from the perspective of a C# developer trying to make sense of it.

Chris Woody Woodruff