js-ts-csharp

N(new[]{1, 2, 3, 4})); As is this: // Return a tuple var runCalcsAsTuple = (int[] values) => { return ( multiplyN(values), addN(values), subtractN(values), divideN(values) ); }; // Destructure the tuple var ( multiplyResult, addResult, subtractResult, dividResult ) = runCalcsAsTuple(new [] {2, 3, 4, 5}); Named tuple types are also kinda interesting: using Profile = ( string Username, (string Hn, string Mastodon) Socials ); var profile = GetProfile(); var (hnHandle, mastodonHandle) = profile.Socials; Profile GetProfile() => ("chrlschn", ("CharlieDigital", "@chrlschn")); If you haven't looked at C# in a while, I'd recommend taking a look with a fresh set of eyes. Small repo with examples comparing C# to JS and TS: https://github.com/CharlieDigital/js-ts-csharp

it is that the multi-platform capabilities matured a lot since the 4.8 Framework days; the team I'm on is all macOS and we deploy to a mix of AWS t4g Arm64 instances. Part of it is that there's no longer a hard dependency on Visual Studio for most workloads; the team is a mix of VS Code and Rider. What really stood out to me after that stint with TS is how close TS and C# have become[0] and even more so with the more recent releases of C# 12. I think it's probably easier for teams that are working with TS + Node to add C#/.NET workloads than any other language/runtime like Go or Rust when there is a benefit to add multi-threading or get higher throughput from some backend system. [0] https://github.com/CharlieDigital/js-ts-csharp

ync/await came after C#; same for JS lambdas) [0] https://github.com/CharlieDigital/js-ts-csharp

n syntax [1]. One often overlooked advantage for high security contexts is that .NET has a large standard library that's maintained by Microsoft for really core things like encryption, hashing, database drivers, network code, etc. You get the benefit of having an army of professional engineers maintaining that core code and patching it when security issues arise versus the Node/NPM ecosystem's strong dependency on the community. C# and .NET are the backend runtime that most teams probably want when they think of moving on from Node to Elixir, Go, or Rust because of how close it is to TypeScript now. And if you're going to use .NET on the backend, then why not consider Blazor for SSR and static HTML? (Disclaimer, I'm not a big fan of Blazor, but I can see why teams would choose it). [0] GitHub State of the Octoverse 2020: https://octoverse.github.com/2020/static/github-octoverse-20... [1] https://github.com/CharlieDigital/js-ts-csharp

Script to C# if a team needs higher throughput on the backend[1][2] - `System.Linq` provides a superset of JS Array methods and is easy to map from one to the other. - It's performance is on par or superior to Go[3] and competitive with Rust[4] while being much easier to adopt because of the language similarity to JS and TS. - It is an object-functional hybrid language owing to its influence from F#[5]; discriminated unions are on the roadmap and available today with packages like Dunet and OneOf, it has pattern matching like Rust, extension methods provide flexibility in modelling, named tuples in C# 12 converge even more with TS, it supports destructuring record types and classes, it has immutable record types - Minimal APIs are very familiar for teams using Express but need more performance. I'd actually say that it's a bit simpler than Express on Node for common use cases since there's nothing to import when setting up minimal APIs since it's all first-party Microsoft. - Platform support for source generators are a revelation; it removes a lot of boilerplate code while actually improving performance over reflection. - Many of the things teams love about modern JS actually have influence from C#. Lambda expressions in JavaScript, `async/await`, and more. In fact, C# and JS/TS have been converging (see the linked repo). - It's relatively easy to write high throughput code in C# with support for both concurrency (Tasks + Channels) and high level abstractions for parallelism (Task Parallel Library) as well as full access to threading. - C# allows easy access to underlying low-level primitives; you can program with high level abstractions for productivity but still have access to call `unsafe` code if needed. - EF Core is possibly the best ORM on the market right now in terms of performance, ease of use, maturity, and database engine support. - A benefit of a language and runtime backed by Microsoft and used in the enterprise is that security issues get addressed by a team of professional engineers; you don't see the same types of security issues that pop up in the Node/NPM ecosystem. - This is a big boon particularly because of the broad standard libraries and first-party libraries for many use cases. Rather than importing unknown dependencies for common use cases, you end up with a baseline of professionally maintained, OSS code. - GitHub's State of the Octoverse report in 2020[6] showed that C# had the least Dependabot alerts and has the least transitive dependencies (less prone to security issues via package managers). - As a general purpose language, it can be used in many domains from desktop to devices to web to gaming (both Godot and Unity; RyujinX). - It's also quite mature and stable while languages like Rust are still ironing out async and Go just released generics. C# has been there; done that. My personal opinion is that C# is the language that most teams want but don't know enough about it or have a bad taste from the .NET Framework days. While the runtime is more complex than Node, the language is very similar to TypeScript owing to its lineage from Anders Hejlsberg. C# and .NET in its current form is a great language and platform to build on. Besides, if a team is already using VS Code, GitHub, and TypeScript, they're already in the Microsoft controlled ecosystem. [0] https://spectrum.ieee.org/the-top-programming-languages-2023 [1] https://github.com/CharlieDigital/playwright-scrape-api [2] https://github.com/CharlieDigital/js-ts-csharp [3] https://medium.com/servicetitan-engineering/go-vs-c-part-3-compiler-runtime-type-s… [4] https://www.techempower.com/benchmarks/#section=data-r21&test=composite&hw=cl [5] https://itnext.io/getting-functional-with-c-6c74bf279616 [6] https://arxiv.org/ftp/arxiv/papers/2110/2110.10246.pdf

var result = apply(input => ..., input); The C# can version can also be written like: var Apply = (Func<string, string> fn, string input) => fn(input); var lowercase = (string input) => input.ToLowerInvariant(); var result = Apply(lowercase, "HELLO, WORLD"); For the curious, I have a small repo that shows just how similar JavaScript, TypeScript, and C# are: https://github.com/CharlieDigital/js-ts-csharp Screen grab of the same logic in JS/TS/C# showing the congruency: https://github.com/CharlieDigital/js-ts-csharp/blob/main/js-...

her throughput, C# is a stone's throw away from TypeScript syntactically and it's pretty easy to hire for (compared to Rust). [1] Pick Rust if you're building something highly performance and memory sensitive. Pick TypeScript and C#/Go/Java for almost all other cases. [0] https://github.com/CharlieDigital/js-ts-csharp [1] https://raw.githubusercontent.com/CharlieDigital/js-ts-cshar...