3 ms·

This highlights the single biggest problem I have with the MS/C#/.NET runtime/ecosystem (The article seems to be from a .NET developer), so many functions conne

This highlights the single biggest problem I have with the MS/C#/.NET runtime/ecosystem (The article seems to be from a .NET developer), so many functions connected to string handling are locale dependent and you have to explicitly select the non-locale variants and that then becomes an issue when dealing with the common data interchange and file-formats since those are usually with US semantics. Many European developers run into this frequently since the default parse for float/double/decimal will assume comma as the decimal separator due to our locale settings.

neonsunset 1y ago
As a developer or a user, you have full control over this: <InvariantGlobalization>true</InvariantGlobalization> or DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=true (it is still an occasional gotcha, but pretty much everyone learned to be aware of it)
- whizzter 1y ago
  I've missed that it's possible to use as a default, thank you. Still the need to remember it is an silly cognitive load (also it seems it was introduced only with .NET Core 2, still maintaining old framework apps where this luxury doesn't seem available?).
  - neonsunset 1y ago
    Historically, it was a decision to avoid cognitive load for GUI applications. To be fair, it's been a while since I've heard anyone complain about it - most servers and containers run with both an en-US locale and/or the invariant globalization set to true. It may sometimes be an issue when debugging locally but it can be quickly addressed, if the solution for some reason does not pass the culture explicitly or does not set the invariant globalization. I think before there was a global toggle it was a pretty bad default, but nowadays it's not a practical challenge at all. It's a "solved problem". As for .NET Framework applications - they have bigger issues to worry about. The teams willing/forced to stay with it know what they sign for. Also, why the downvotes?
    - whizzter 1y ago
      Yes, I agree, it's probably an inheritance of the Visual Basic roots it was supposed to take over. We got enterprise customers here in Sweden so some parts of the framework legacy are unavoidable due to that and server locale has been a bit of a crapshoot due to it being a classic on prem without fixed guidelines/needs. Also confused by the downvotes (got it on the thread-root comment also), got another "weird" downvote in another post's comment also so no idea if it's some weird bot behaviour or someone who hates me.

neonsunset 1y ago

As a developer or a user, you have full control over this: <InvariantGlobalization>true</InvariantGlobalization> or DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=true (it is still an occasional gotcha, but pretty much everyone learned to be aware of it)

whizzter 1y ago
I've missed that it's possible to use as a default, thank you. Still the need to remember it is an silly cognitive load (also it seems it was introduced only with .NET Core 2, still maintaining old framework apps where this luxury doesn't seem available?).
- neonsunset 1y ago
  Historically, it was a decision to avoid cognitive load for GUI applications. To be fair, it's been a while since I've heard anyone complain about it - most servers and containers run with both an en-US locale and/or the invariant globalization set to true. It may sometimes be an issue when debugging locally but it can be quickly addressed, if the solution for some reason does not pass the culture explicitly or does not set the invariant globalization. I think before there was a global toggle it was a pretty bad default, but nowadays it's not a practical challenge at all. It's a "solved problem". As for .NET Framework applications - they have bigger issues to worry about. The teams willing/forced to stay with it know what they sign for. Also, why the downvotes?
  - whizzter 1y ago
    Yes, I agree, it's probably an inheritance of the Visual Basic roots it was supposed to take over. We got enterprise customers here in Sweden so some parts of the framework legacy are unavoidable due to that and server locale has been a bit of a crapshoot due to it being a classic on prem without fixed guidelines/needs. Also confused by the downvotes (got it on the thread-root comment also), got another "weird" downvote in another post's comment also so no idea if it's some weird bot behaviour or someone who hates me.