[madsbuch]

So, the elegant way to solve this would be to use an Elm i18n library and just use ports to get the users region instead of formatting every single string.

I understand that it is hard for a software developer to accept that these things need to be reimplemented, but it also seems to be a natural consequence of "up-typing" an entire eco system.

I studied formal techniques for PL. A large portion of the work was in reimplementing existing things in Coq, HOL, etc. Not particularly interesting, but necessary to reach a mature ecosystem.

I do undestand that this makes it a no-go for a lot of people until these things have been implemented. This is also natural.

[dhucerbin]

> but it also seems to be a natural consequence of "up-typing" an entire eco system.

Reimplementation of i18n API in Elm would make sense only if benefits from types could outweigh robustness of browser implementation. Due to not very expressive Elm type system I really doubt that. You can’t capture intricacies of i18n in Elm type system.

I have more confidence in already tested and used by millions API in the browser than in reimplementation in niche language.

Elegant solution would be if I could write well typed layer that calls browser API. Low bar of entry would drive adoption and in effect real world test. But that’s not possible anymore.

[madsbuch]

> Elegant solution would be if I could write well typed layer that calls browser API

Not if your goal is correctness.

Again, it is completely OK that Elm is not your choice if it does not align with your values, which appears to be the case.

[dhucerbin]

> Not if your goal is correctness.

Could you define correctness in this context? I'm asking because I don't believe that you can achieve correctness using Elm type system. I don't see how you can encapsulate i18n rules inside Elm type definitions. Maybe something like Coq could do this ...

You can't express something like "if passed 3 as group size, integer part of the number should be represented as string with separators between three digits". Even in Elm that's something that you need to handle not in type system but in runtime code.

What is more - many core packages are just this - typed layer over browser API. elm/regex introduce barely any type safety. It assumes that browser API is "correct".

> Again, it is completely OK that Elm is not your choice if it does not align with your values, which appears to be the case.

I often see this response from Elmers but really I don't understand the point of it. I responded to claim that Ports solve all problems. I provided good, real example where Ports are a bad solution. In return I was scolded that I don't understand software engineering.

I don't jump into elmconf and complain or demand changes. I just provide my take on the discussed issue. And to be frank, I think that's very valuable take for someone who decides if Elm is good for them. That kind of information is not present on elm homepage and is not obvious for new users.

[madsbuch]

Well, as with all logic systems you can only express correctness up to its granularity. Elm's type system is, as you mention, very rudimentary and basically just HM + reactive programming.

First, I don't write any serious applications in Elm, and would never do it. I don't find that it is productive because of the reasons you list. Just as I would never write any serious applications in Coq.

But with Elm, as with Coq, I can appreciate that their goals are not immediate developer productivity. Maybe some day when the ecosystems needed are fully implemented. Until then I just applaud everybody working on systems that are strongly typed and ensure that all their dependencies are.

I believe this will provide tremendous value – when ripe.

[gampleman]

The problem with I18n in particular is that reimplementing in Elm causes pretty unreasonable download size bloat.