The thing is, I find immutable is safer. Less side effects is more predictable. OO is used often when things can just be functions. I love gamedev, and OO makes a lot of sense there because all of the computations and unsafe code is kind of okay. But for webdev FP makes so much more sense. For SAAS something like elixir enables me to write more reliable / less buggy / better tested code.
Even in GameDev there is a strong trend towards data-oriented programming and stateless logic, led by the ECS (Entity-Component-System) paradigm.
ECS is all about composition rather than inheritance, and decoupling logic from data. It is not strictly immutable for performance reasons, but it has a similar character as the immutable functional state-management frameworks in WebDev (Redux, Elm and co).
It's not just about maintainability, it actually can be awkward to fit certain patterns into ECS, but it has significant advantages in terms of performance (particularly being CPU cache-friendly) and being able to massively parallelize safely and without having to think too much about it. It can also be a helpful abstraction for distributed computing and networking in multiplayer.
If I could get one wish, it would be to ban "makes sense" from any engineering discussion ever. Facts do not "make sense" the world is not a "sense making" machine. We make sense of the world and of the facts. Something feeling intuitive, which is what people often mean when they claim something "makes sense", just means it slots into your existing experience.
Not GP but I'm using Clojure for both the front-end (ClojureScript) and the "back-end" (server running Clojure), sharing Clojure code between the two.
Clojure is not typed but I use Clojure specs. It's not a type system but it's really nice. You can spec everything, including specc'ing functions: for example you can do stuff like: "while in dev, verify that this function returns indeed a collection that is actually sorted everytime it is called". I'm not saying: "no types + clojure specs" beats types but it exists and it helps to solve some of the things types are useful for.
> _for example you can do stuff like: "while in dev, verify that this function returns indeed a collection that is actually sorted everytime it is called"._
This sounds interesting. Do I understand correctly, this checks the "spec" at runtime? What happens if a spec fails?
Not the other commenter, but my team has been using Elixir in production (soft real-time distributed systems) for several years to great success. The approachable syntax has been great for folks new to the language coming on board and sort of, not realising they’re “doing FP”.
Generally I’d say Elixir’s lack of “hard” static typing is more than made up for what you get from the BEAM VM, OTP, its concurrency model, supervisors etc.
That said if you’re interested in leveraging the platform whilst also programming with types I’d recommend checking out Gleam (https://gleam.run), which I believe uses an HM type system.
In Elixir specifically you've got structs that are somewhat similar to types, %MyStuff{}, and if you need to you can use Ecto to get some guarantees. You also tend to focus more on the shape of data than the name, e.g. with pattern matching in places like function declarations and case expressions, which emulates quite a bit of what you typically use a type system to accomplish.
