Perl vs C# (vs JavaScript)

Lately at my day job, I have been tasked with spearheading a migration of some software from Linux-based Modern Perl apps using Dancer2 and DBIx:Class to Windows-based C# apps using .NET and Entity Framework Core (EFC).

It’s been a bit of a slow start because the existing devs on the C# side don’t have any Perl or Linux experience, and my teammate and I didn’t have much (any?) C# experience. After meeting with my new peers, exploring their existing code bases, and reading up on C# concepts, here are some of the things I picked up that I think could be useful to others:

Code Concepts

Map in Perl/JS is Select in C#

I forget the syntax a lot because I’m more a front-end and NodeJS guy, so I’m used to doing things like fooArray.map(fooItem => bar(fooItem)) to map things in JS. Perl is similar, but it’s more like map { bar($_) } @fooArray . In C#, the concept is similar, just renamed: fooIterable.Select(fooItem => Bar(fooItem))

Hashes vs Not-Hashes

Perl hashes are convenient, but the way we use them doesn’t always translate cleanly to the strictly-typed universe of C#.

If we expect all of the values to be the same type, we can use a Dictionary<> just fine. In other scenarios, though, it makes more sense to determine what we are passing around in the old app and turn it into a class we can use in the rebuild.

In a pinch, a JSON object can work for us — especially if we’re receiving it from an API endpoint to begin with — and then we can use logic to determine how to use its values elsewhere.

App Configs

For Dancer2 configs, the default config is specified in config.(ext), but there you can specify additional configs in a folder called environments that makes it a bit easier to wrangle them.

I’m not sure if you can do a folder the same way in C#/.NET app configuration, but Visual Studio does a neat folding hierarchy that collapses appsettings.(foo).json files underneath appsettings.json in your project’s solution explorer.

They also differ in approach to storing local/user-specific configs: Dancer2 will look for a matching (configname)_local.(ext) file to override the current environment’s settings as needed. In .NET apps, dev-specific configs are handled using a concept called user secrets that allows those to be stored elsewhere and applied over the default development configs.

Database Interaction

Where we used DBIx::Class in Perl, we’ll use Entity Framework Core (EFC) now in C#.

ConceptPerl/DBIxC#/EFCFrameworkDBIx::ClassMicrosoft.EntityFrameworkCoreRow/RecordResult classModel classRecord with ExtrasOn same Result classPreferably on a DTO class separate from the plain Model classGroup of RecordsResultSet classMember of DbContext classGroup of Records with ExtrasOn same ResultSet classCreate a Repository class with those extras

Syncing Schema with DB

In Perl, we used scripting around DBIx::Class::DeploymentHandler to apply updates we made in our Result classes to the DB.

While a similar approach is possible with EFC, we decided to use scaffolding to go the other way for the project we’re working on.

Actually, the use of Deployment Handler (DH) on the Perl side allowed us to get a slight head start on this:

We modified our DH scripts to not only generate the requisite update and deploy code for PostgreSQL, but also generate code for SQL Server.

There was some hand-tweaking involved with the generated SQL for SQL Server, notably to swap out some unsupported column types (jsonb!) and fix a few other syntax issues.

Using that tweaked SQL, I could spin up a local SQL Server instance and create the DB.

Then I used the scaffolding tools provided with EFC to generate our initial models and context.

Still Learning…

I’m still learning plenty about C# and .NET daily, and I’ll likely update this post or follow up if anything here changes or if I have more to share.

If you’ve ever gone from Perl to C# (or vice-versa) and have any suggestions, let me know!

#c #dayJob #dbix #efc #perl #software