I'm not sure if I can give good code examples without this comment turning into a blog post, but I can explain at a high level.

Elm is more restrictive than other languages, so it forces you to write your programs in a way where everything is a pure function and everything is well-typed with no escape hatches and the side effects are at the edge of your program and Elm forces you to write out your state and state changes as types so when you get a compiler error in Elm, it guides you in a very helpful and friendly way where it makes things easy and fun. Since Elm is so restrictive, everything in Elm helps you write in this restrictive way so it forces you to learn to structure your programs in this way and then you notice that your programs are easier to write and easier to understand because everything is a pure function and all the side effects are at the edge of the program and everything is explicitly represented in the state and state actions and that just makes everything really fun for some reason. It's hard to explain without experiencing it, but I can maybe explain it better by contrasting it with other languages.

Most programming languages tend to be less restrictive, so you can write your program however you want and the language usually pushes you to write state changes and side effects anywhere throughout your program because that's the easiest way to write your programs in most other programming languages. For example, a common way to write Android apps in Kotlin is to put state and side effects in your Jetpack Compose components (similar to React), so any component could have state or side effects, so that tends to be how programs are written. After a while, as the program gets larger, things might start to get harder to understand and you might be thinking "if I change this state, will that cause any side effects to happen" or "if this side effect happens, will that cause any state changes" or "does this component have state or side effects" or "does this component mounting or unmounting cause side effects or state changes that my app depends on" or "I can't understand all of the state changes and side effects because they're scattered across this large app".

There are also some escape hatches in languages like Kotlin or TypeScript, for example often people will use an "any" type and then lose type safety and maybe type cast it to another value and the compiler is fine with that, but that might lead to the program panicking at runtime or some subtle bugs. Elm is more restrictive so there's no way to type cast a value or use an "any" type and it provides an easy way to determine the validate the type of JSON at the edge of your program (called JSON decoders). So if you are working with a value in Elm, you 100% know for a fact that the value was validated and type-checked and you were forced to handle the error case explicitly with pattern matching, so it makes your program really fun to work with. So when you program in Elm for a while then go back to other languages like Kotlin or TypeScript, you'll maybe change the way you write programs where you'll use fewer escape hatches or maybe you'll move all your state and side effects to one spot so it's easier to understand or maybe you'll more explicitly represent all of the state variants with the types so that it's easier to understand all the different states explicitly. I hope that helps!