I have tried C# recently.

They have support for these features, but they require some ceremony to use (like wrapping function arguments in a Callable), which increases friction, signal to noise ratio, and decreases the expressiveness that I want.

I just want to write what I want without having to think too much about how the language wants me to write it. Go is good for that. JS too, but has a lot of historical cruft.

I feel like your "recent" must have still been years ago. Modern C# is as terse as Python/TS/Js for basically any equivalent task, if not more so. Dotnet 8 even make the following possible:

var foo = [1,2,3];

Add on switch expressions, primary ctors, first class functions, no ceremony in Program.cs anymore... it's hard to get more terse and expressive unless you want lots of chained single symbol operators (look at F#).

(slight correction: `var foo = [1, 2, 3];` requires natural types for collection literals (it needs to infer the best type for var), this is coming in C# 13 (.NET 9, this November), but otherwise `int[] numbers = [1, 2, 3];` works)

You're right! I remember some session where they talked about wanting to infer a natural type for stuff like that but its obviously a big question. But as you said declaring the type directly allows it to work. However the other nice part is that you _can_ do this:

void myFunc(List<int>){}

myFunc([1,2,3]);

The expression sytanx can infer the type from the caller syntax so you can just inline the array declaration.

My recent was a month ago, but to be fair, the CTO of that company (who wrote the existing code when I joined) last wrote production code in 2008, so his code may have not been using those newer syntax features.

Yeah it's very easy to write Java style C# that is incredibly verbose and rigid, but once you understand modern c# you can see how it's this really great (imo, awesome) hybrid of functional/typed languages. They've done a ton of syntax work to let types get out of your way when you need them to, with the ability to always fallback to rigidly declaring them when you need better readability.

The downside of all this is that the only people that know how awesome C# is are people who are already doing C#. Growing the pot and trying to convince people to give it a go in its modern (post dotnet 5/"core") iteration is like pulling teeth. Everyone assumes nothing has changed since like C# 2, and given the fact it's a "boring" language that doesn't have Hacker Hype behind it, people just ignore it.

Every week you have people on HN wishing for something that does exactly what C# does but don't want to give it a shot or admit that C# is _actually_ an incredible language and toolset that does exactly what they want (and more).

.NET has explicit tailcalls - they were made for and are heavily used by F#.

https://learn.microsoft.com/en-us/dotnet/api/system.reflecti...

https://github.com/dotnet/runtime/blob/main/docs/design/feat...

Actually they were made for other languages given the original goal of Common Language Runtime, as published on the 2001 release note.

https://news.microsoft.com/2001/10/22/massive-industry-and-d...

Anyone with the pre-release MSDN .NET SDK that was initially made available to MSFT Partners, with alpha documentation written in red, has a folder with tons of functional languages that could take advantage of tail calls.

F# only came later into the picture, even considering its OCaml for .NET origin.

Not the person you replied to but, today I learned!

As an aside, and as someone who's currently going through materials such as Crafting Interpreters (and who knows what else based on suggestions from r/compilers), is there a, I guess, guide for people who want to implement a compiler that targets the CLR/CLI?

I have a copy of CLR via C# 4th edition, but other than that not sure what else I can reference targeting anything newer than .NET Framework 4

I don't have something that could be of Crafting Interpreters level on hand, but the general suggestion given to this question on DotNetEvolution discord by Roslyn team members was to start with the spec itself: https://ecma-international.org/publications-and-standards/st...

This might be a bit of a learning curve if you don't have experience with writing compilers like that though.

There are other materials that might prove useful should you go down this path:

- A series of blog posts of a student who is writing a Rust to .NET compiler which you could follow along: https://fractalfir.github.io/generated_html/home.html The project itself: https://github.com/FractalFir/rustc_codegen_clr

- A video series on writing a compiler for .NET from scratch: https://www.youtube.com/watch?v=wgHIkdUQbp0&list=PLRAdsfhKI4... Notes: https://github.com/terrajobst/minsk/tree/master/docs

As for CLR via C#, while it has certain facts that remained the same, the ecosystem has changed a lot since then, you really want to target the latest LTS to get best experience and performance. If you liked it, then I can strongly suggest https://github.com/dotnet/runtime/tree/main/docs/design/core... which covers .NET runtime internals.

p.s.: if it's any consolation, the promise in CLR via C# of JIT having the advantage of dynamically profiling code execution and compiling to profile-guided version, tuned to the exact hardware and environment is finally fulfilled, many years later :)