karl_p

Remote: Yes

Willing to relocate: No

Technologies: C#, AWS, CDK, Postgres, DynamoDB, Snowflake

Résumé/CV: https://karl-pickett.dev/resume

Email: On resume

25 years of uncompressible experience. I will fix your thorniest backend, API, and distributed systems problems using C#, C++, or Rust (and the KISS principle)

> Your function code is cleaner, simpler, and easier to maintain.

I don't think your post covers the nuances. "Not a correct implementation"? We weren't trying for lowest latency, we were trying for highest reliability / simplest code / easiest to test. How do you test that your reused connections handle the "timed out right as next request comes in" case?

I ported the static site generator for patternedpom.com (sells handmade cards) from Python to C# without changing any layout or styling (PS I don't claim to be a frontend person). It was a code port only. 1000 LOC of C#, and it took me two weeks.

I am happy with the result code - The classes are immutable (auto properties / read only collections)[1], LINQ is a very suitable replacement for list comprehensions, and it's faster than the python.

Razor Templates are very nice - I have an outer layout file and an inner template for each page. I think they came out very cleanly, and I can do LINQ inside of them[2]. Obviously you can do similar things with jinja templates, but razor templates won't compile if something is wrong / doesn't match what the model exposes (yay for catching bugs early). And you can still pass a "dynamic" type object if you want python like behavior (that throws an exception on unknown property).

The "backend" is a google spreadsheet (using their .NET SDK) and some CommonMark markdown files. So it's not doing anything dynamic (yet, I'm almost done adding digital purchases using AWS Lambda / PayPal IPN, which would be a new feature for the site). And it syncs using AWS's S3 .NET SDK.

I don't think it was actually that many more lines of C# compared to python, in any case it's worth it for me. I am tired of using scripting languages for things other than, well, scripts. I hope Microsoft doesn't break things on me in a few years (fingers crossed).

That said... let's look at some other issues.

- vscode is ok. not perfect, probably some bugs (I get "file not found" popups from time to time that I have to close), but it's free. At least if you have the time to learn it. (I'm overwhelmed by all the configuration options really... and I'm trying to use the vim plugin which probably isn't helping my cognitive load)

- minor things: no generic ordereddictionary (casting isn't horrible though), no inplace collection sort() that takes a simple Key lambda, like the LINQ OrderBy() that copies.

- Library ecosystem - this is probably the #1 thing to check out. Does a good library exist, and does it run on .net core. Compared to Java or python, it's probably less, but do your own DD in advance. There is not even a standard command line option parser in .NET Core - so if it's anything you need outside of the core language, you need to build/buy/find it. It doesn't try to be a "batteries included" thing.

- Another example with libraries: I was looking at adding dynamic search with AWS lambda, but the .net lucene library seems to be an old port of the java library.

1. https://github.com/kjpgit/ppom/blob/master/source/SiteBuilde...

2. https://github.com/kjpgit/ppom/blob/master/source/SiteBuilde...

    for (var i = 0; i < 1000000; i++) { 
        var unused_task_var = RunTaskAsync();
    }
    await RunMainMonitoringTaskAsync();

tl;dr If you call an async method and don't await on it, it will be parallelized - for a console app, at least.

Honestly, I don't find the MS docs on this to be that great. Not 100% sure I'm even doing it the right way here. Everybody says use Task.Run but that is for CPU bound tasks. I want to run a ton of IO waiting tasks.

edit: looks like I'm doing it right. See "Async Composition" @ https://blog.stephencleary.com/2012/02/async-and-await.html

I'd say the more important concern with c# is to be careful you're not accidentally calling a "really blocking" function from an async method, or you will lose scalability. The lesser issue is the mundane task of changing all your function signatures in the chain to async.

I too would use Go if it didn't regress in every single area for me, other than concurrency, and make me sad.

It does use a threadpool scheduler by default for a console app. Yes, I could override that if I wanted to.

Basically: your instance POSTS to an endpoint to get/reply to requests, one at a time.

I can't wait until you can specify that a lambda instance can handle a certain # of requests in parallel. Ex: things just blocked on IO/DB. That would make better use of your RAM.

I threw this benchmark together in a couple of hours pretty easily. The most annoying part was just measuring the RAM :-)

But yes, everything is a tradeoff. If you want safety, you pay more - either in RAM, or in cognitive load.