I think the core ideas can be used in many settings, that is true. One can use a pattern like this in C if they want. I think there are a couple questions to consider when asking "how does language really help?"
1. How much is the language going to help you independently arrive at nice architecture? It took millions of people 20 years to arrive at this pattern in JS, and it literally happens in every Elm program out there automatically. The pattern described in "The Elm Architecture" really does come from looking at people's Elm code and seeing the naturally arising patterns. So new people don't need to read this post and learn these concepts, commercial users don't need to have strict discipline, the architecture just comes out this way.
2. How much is the language going to fight you or help you when you already know what you want to do? In particular, ADTs are a key part of why this is so nice in Elm, and when you are working in JS or TypeScript, writing "the same code" leads to code that can be quite awful. Even when you know why you want it, it often does not seem worthwhile to fake ADTs. Immutability is another key aspect that's hard to get in many languages. I'll write more about this in some future post, but I think lack of side-effects is another key aspect of keeping the architecture nice.
3. How much is a language going to help a team of 20 keep this up in a large code base? Will the intern or the new hire be able to do it right? Once you start to get cracks, do they continue to grow? If you lack a module system or a type system, are you going to start running into other scaling problems? In this setting, having tools that guide you to the right answer is extremely valuable.
Thank you wheatBread for taking the time to respond.
I appreciate the practical lens with which you've described how the language can influence code. Many language geeks far too often remain too abstract about how a craftsman programmer's life can be improved by the language's design.
ADTs stood out as something I'd love to have in my day-to-do programming toolbet during my short tryst with Haskell. But I was unable to articulate the concrete improvements it can bring into my code, and so it has unfortunately remained a hunch. I eagerly look forward to your post about ADT in the context of Elm and UI programming.
1. How much is the language going to help you independently arrive at nice architecture? It took millions of people 20 years to arrive at this pattern in JS, and it literally happens in every Elm program out there automatically. The pattern described in "The Elm Architecture" really does come from looking at people's Elm code and seeing the naturally arising patterns. So new people don't need to read this post and learn these concepts, commercial users don't need to have strict discipline, the architecture just comes out this way.
2. How much is the language going to fight you or help you when you already know what you want to do? In particular, ADTs are a key part of why this is so nice in Elm, and when you are working in JS or TypeScript, writing "the same code" leads to code that can be quite awful. Even when you know why you want it, it often does not seem worthwhile to fake ADTs. Immutability is another key aspect that's hard to get in many languages. I'll write more about this in some future post, but I think lack of side-effects is another key aspect of keeping the architecture nice.
3. How much is a language going to help a team of 20 keep this up in a large code base? Will the intern or the new hire be able to do it right? Once you start to get cracks, do they continue to grow? If you lack a module system or a type system, are you going to start running into other scaling problems? In this setting, having tools that guide you to the right answer is extremely valuable.
So I think language matters a lot, but I would :P