Another difference you might be surprised by is that the .NET tooling by default collects various data from your system and sends it to Microsoft [1].

If you want to avoid this (and still want to use .NET) you'll have to make sure that the environment variable DOTNET_CLI_TELEMETRY_OPTOUT is set to 1 in all contexts before touching anything.

[1] https://github.com/dotnet/sdk/issues/6145

> DOTNET_CLI_TELEMETRY_OPTOUT

I didn't know about this. I wonder how that sits legally with local data protection rules (EU).

I doubt they way they approach it is legal, but I don't think any of the DPAs have time to look into it.

For what it's worth, the tool prints a clear warning the first time you invoke it. You shouldn't need to opt out regardless, but they do at least communicate their stalking.

> I can do almost all the dynamics things that I can do in Python with C#, but in a type safe way.

If you like flexibility with a good type system, give Typescript a try, its miles ahead of mypy and its designed by same person who’s behind C#.

Typescript is of course nice and is a great type system but can’t totally paper over the absolutely impoverished base language that is JS. When you use Python and things like equality do what almost anyone wants instead of checking object identity, it’s real annoying to futz around in TS

[1, 3, 12].sort() == [1, 12, 3]

5 in [5] == false

Even setting the sort order aside, just the fact that it both returns the sorted array and also sorts it in-place is not great. I prefer Python's distinction between sorted (returning a sorted copy) and list.sort (sorting in place and returning nothing).

I don't think this is a completely accurate comparison, as TypeScript is transpiled to JavaScript and this provides restrictions to the expressibility and usability of types at runtime, which I've sometimes hit my head against. C# has much more type information available at run time, as does Python.

I'm a full stack dev so I'm also using TS at the same time. While the flexibility is nice, it's too flexible for my taste. To give a one basic example, I want to go to the definition of a symbol with a single action. Not possible with the current TS tooling and all the crazy things you can do with it's type system.

I want the type system to be predictable, so it can support whatever I want to build on top of.

There are features I'm missing with C#, but still I'll choose it over TS any day.

Even better would be to try F#, it will be able to use all the .NET libraries, has Python's succinctness, but with a strong type system (and inference).

I may switch to it eventually, but at this point in my career 16 years in, I try to avoid seemingly niche things when I just want to get stuff done. "Boring" is good. I know it's the same platform under the hood but I decided to spend my "innovation tokens"[0] on the stuff I'm buildin.

[0]: https://mcfunley.com/choose-boring-technology

I call it "novelty budget" and I completely agree.

I'm also 100% convinced most people who use mypy don't realize the myriad ways it just silently stopps typing things or just silently crashes with a 0 exit code. Even if you configure it to warn untyped functions etc. It will still just not work properly in some of circumstances and you will literally never know until you debug a bug that just happened to trigger it. There are over 1.4k open bug tickets it's such a broken piece of software: https://github.com/python/mypy/issues?q=is%3Aissue+is%3Aopen...

The involvement of Guido in mypy is such a tragedy.

I think it's probably no mere coincidence that the article recommends pyright, not mypy.

Seconded, C# is a great language these days. LINQ is just magic (in a good sense of the word), doubly so when it’s seamlessly translated into SQL by Entity Framework.

Django has kept me chained to Python. Just can't beat admin/migrations/ORM. Ive often wondered why a true django-like project has never been born out of the JavaScript/Typescript ecosystem.

> One thing that kept me using [language X] was [insert awesome library here]

And that's why I keep [language X], because sometimes the equivalent in [language Z] is not as good.

If [awesome library] is the primary thing your code does, then sure, you might be stuck with [language X]. But if it isn’t, then perhaps the [language Z] replacement might be good enough (or better but not yet well understood, as in the case of the OP), or you might keep [language X] just for that small component.

A typical pain point where type hinting fails in Python is with list of some types, it can't be enforced by the language without more checks.

For example, you can't do:

if isinstance(x, list[int])

though it would be super useful

You need to use mypy or similar to not check it at runtime:

    els: List[int]

To test it at runtime you can use typeguard s @typechecked annotation. For convenience you can also use Pydantic.

I didn't know about typeguard. Thank you for the recommendation!

How do you do this in Pydantic though?

For this example pydantic would be overkill, but you can use with it class definitions that follow standard python class hints, with additional utilities like YourClass.parse_obj(d) that parse a dict and throw a validation error if it does not match, with mostly standard type annotations.

It can also be used to generate openapi swagger files from the types and things like that.

Yes I know, I'm just pointing out that you need additional tool to check that.