[ossopite]

I'm not convinced it really works well in typescript. the lack of nominal types requires you to remember some pretty hacky incantations if you want something like a newtype wrapping a primitive type

my experience is that ocaml is more powerful than rust for enforcing this sort of type safety, because you have gadts that give you more expressive power, and polymorphic variants and object types (record row types) that give you more convenience. and the module system and functors of course.

you also avoid some abstraction limitations/difficulties that come from the rust borrow checker for places where garbage collection is just fine

[cyberpunk]

It really feels like we’re solving the wrong problem sometimes. If a bad type can crash your application, sure, type safety is one answer but I have to admit I like the erlang approach; if something unexpected happens crash the process (not os process, erlang process) which has a very small blast radius on a well architected system (maybe doesn’t even fail the individual request that caused it). I wish more languages had this let it crash philosophy, it really allows for writing code exclusively for the happy path, safe in the knowledge that a -1 where a “string” should be isn’t going to take down production.

Somehow, it feels like a better solution than these complicated type systems. Does any other language do this outside BEAM?

[chongli]

When working on large, important software, crashing is not the worst thing that can happen; corrupting user data and/or allowing unauthorized access is.

The point of using the type system to do something like distinguish between sanitized and unsanitized strings is specifically to prevent these kinds of security breaches.

Erlang was designed for traditional telecom, where reliability of connections was the biggest factor, not security. I fail to see how Erlang’s approach can deal with the issue of security breaches or corrupted user data.

[ossopite]

In a way I agree with you, and I'm not sure that what popular languages embrace or make it easy to follow this philosophy. My sense is that Erlang is still the leader.

But I did want to add something the article also touches on: types can be not only about ensuring safety or correctness at runtime, but also about representing knowledge by encoding the theory of how the code is supposed to work as far as is practical, in a way that is durable as contributors come and go from a codebase.

Admittedly this can come at the cost of making it slower to experiment on or evolve the code, so you have to think about how strongly you want to enforce something to avoid the rigidity being more painful than valuable. But it's generally a win for helping someone new to a codebase understand it before they change it.

Edit: another thought I had is that type mistakes do not always causes crashes. Silent corruption can be much more insidious, e.g. from confusing types which mean something different but are the same at the primitive level (e.g. a string, number or uuid)

[techpression]

For me this has been a life saver being the only back end developer at the company. I don’t have the energy nor time to think about every possible scenario, especially not the mobile client sending random strings to something that should be parsed as an uuid (has happened more than once). By letting it crash I can have a look at the traces at my own leisure and a lot of them I never fix, because I don’t have to.

The amount of silencing (implementer error, but quite prevalent) of errors I’ve seen in typescript codebases are horrifying. Essentially ”try happy path, catch everything else and return generic error”, the result is is mostly the same for the user, but night and day for me who is trying to fix it.

[satvikpendem]

Or have a static type system and something like BEAM. I'm not sure why this is a one or other approach, both are useful and unfortunately it doesn't seem like any languages include both. Gleam exists but doesn't really integrate with BEAM, it seems to have its own way of doing things that are more akin to Haskell, given its origins.

[cyberpunk]

I thought gleam was fully integrated with otp? You’re telling me you can’t do a gen_server or a supervisor in gleam?

[satvikpendem]

It still doesn't have hot reload support which is critical in BEAM. It simply doesn't handle it the same way as Erlang.

[cyberpunk]

I'm running BEAM in production for almost 8 years and not once have I used hot code reloading. Why is that critical?

[satvikpendem]

That's literally the entire point of BEAM lol, that's one of the main reasons it was made, to patch code that breaks after letting it fail. BEAM was designed for as little downtime as possible and if you don't need that then just use another more ergonomic language than Erlang or Elixir.

[thfuran]

>if something unexpected happens crash the process

There are some expectations where that's a reasonable response to a violation, but there are many expectations where the violation implies a bug elsewhere and crashing the process will do nothing to address that that wouldn’t have been better accomplished with stronger compile time checking.

[jbreckmckye]

> some pretty hacky incantations

  type NewType<T, Name> = T & { readonly __brand: Name };

I don't really see a big problem here?

[matt_kantor]

EDIT: previously the example in the parent comment was:

  type NewType<T> = T & { __brand__ : Symbol }

---

This seems wrong; the type spelled `Symbol` refers to the boxed interface for symbols[0]. I suspect you meant to write `unique symbol` there, but it can't be used in that position.

I'm not sure if `NewType` in your comment is supposed to stand in for a specific newtype (in which case it probably doesn't need to be generic[1]) or if it's supposed to be a general-purpose type constructor for any newtype (in which case it should take a second type parameter to let me distinguish e.g. `EmailAddress` from `Password`[2]). The use of `unique symbol`s is also only really necessary if you want to keep the brand private to force users to go through a validation function or whatnot, otherwise you can just use string literal types.

I agree these incantations aren't big problems (it all falls out naturally from knowledge of TypeScript's type system, and can be abstracted away as per my comment in [2]), but the fact that you goofed in the very comment where you were trying to make that point is causing me to second-guess myself.

[0]: https://github.com/microsoft/TypeScript/blob/v6.0.3/src/lib/...

[1]: https://tsplay.dev/N7rvBw

[2]: https://tsplay.dev/Ndep0m

[ossopite]

Right. Besides getting this incantation right, as gp did only after editing their comment, you also have to cast to create values of NewType. But generally you want to avoid casting in typescript if you care about type safety, so now everybody has to remember the rule that in this particular circumstance it's the right thing to do.

There are helper libraries to ease this (zod supports branded types, I think?), but I guess my general point is that while typescript might give you the ingredients you need to implement type safety in cases like this if you try really hard and remember all your rules everywhere, it doesn't come naturally so it's hard to maintain at scale.

[presentation]

Yeah we just use Zod’s branded type and that pretty much handles it. No casts, use a refinement then slap a brand on it.

[jbreckmckye]

I was on the Tube and wanted to get my reply in before entering a tunnel. I already corrected it whilst I was underground.

I think the point still stands - is this really a big problem? I guess I couldn't recite the syntax from memory, because I usually use a utility type for this