4 ms·
It is fairly common your type system ends up with escape hatches allowing you to violate the type rules in practice. See e.g., OCaml and the function "magic" in
by jlouis 2y ago
It is fairly common your type system ends up with escape hatches allowing you to violate the type rules in practice. See e.g., OCaml and the function "magic" in the Obj module.
It serves as a way around a limitation in the type system which you don't want to deal with.
You can still have the rest of the code base be safe, as long as you create a wrapper which is.
The same can be said about having imperative implementations with functional interfaces wrapping said implementation. From the outside, you have a view of a system which is functionally sound. Internally, it might break the rules and use imperative code (usually for the case of efficiency).
- stouset 2y agoObviously every type system in practice has escape hatches. But I’ve never seen another staticly-typed language where you need to break out of the type system so regularly. Go’s type system has your back when you’re writing easy stuff. But it throws up its hands and leaves you to fend for yourself when you need to do nearly anything interesting or complex, which is precisely when I want the type system to have my back. I should not have to worry (or worse, not worry and be caught off guard) that my pool of database connections suddenly starts handing back strings.
- int_19h 2y ago> But I’ve never seen another staticly-typed language where you need to break out of the type system so regularly. It's about the same as Java and C# prior to their adoption of generics, and largely for the same reasons.