Hacker News Reader

Comment by kuon | Hacker News Reader

I'm a rust,zig and elixir developer and I had to work on a large typescript project that use zod.

I felt like I was being punished for everything. (Maybe some things were project specific so I am not saying this as an absolute) It's slow, syntax is horrible, error are obscure super long lines, it can compile and explode later (which is what elixir does, except elixir will happily restart and recover)...

Elixir is based on duck typing mostly, but it works very well because you just pattern match your data when you use it. Rust is very strict and can have cryptic errors, but as everything is baked in the language it is way easier to manage.

I am not saying this to be snob about typescript and JS, but I really felt pain when working with that ecosystem, and I wonder if I'm old and stupid or if those tools are really half baked and over complicated.

View on HN

My company uses zod to validate data for HTML requests, and I'd say it works pretty well for that. It lets us detail our data structure in zod, validate the completely untyped HTML data, and be confident that once we reach our actual code, the data is well typed.

Zod feels like a crutch for limitations in Javascript and Typescript. But I've found it to be a very useful crutch, and I wouldn't want to write a Typescript API without it.

>elixir will just recover

Thats not true. It just crashes the “sub” process and if the parent process spawns the sub process again with the same inputs its just going to crash again.

Are you aware you can also try/catch your errors in typescript?

The whole point of the library is to validate something at runtime so of course it is going to blow up. There are also API methods that simply return a boolean instead of crashing if it fails validation. You can then use type guarding and narrowing of the type.

Erlang/elixir is built around a "let it crash" model. The idea is that the system as a whole is robust, not individual processes.

If your i.e. server process kills itself when validating data, that's not the Problem of ZOD. The violation failing is an expected case, that is the use case for such a library.

An infinite loop of crashing isn't very useful though. "Let it crash" doesn't lead to a whole system being robust all by itself since you can also just say "let it throw exceptions" in just about any language. Erlang's whole-system robustness emerges when far more than just how you handle exceptions and crashes is implemented to support things that crash. It expects parallel processes and even redundant computing infrastructure to exist to handle those things that are crashing, and hopefully those redundancies behave in a way that doesn't also crash in the same way. Erlang only achieves its robustness because nobody really chooses Erlang without also knowingly buying into the entire setup that it requires to succeed. And if they don't then it won't actually achieve that robustness and succeed in that way.

The phone systems that Erlang's design emerged from naturally had these parallelism and distributed system properties that they could leverage and build on. Running Erlang on a single core SBC like to display virtual signage and limiting it to a single thread and not letting it have any redundancy in any way and then taking the approach of "let it crash" is not going to create a famously robust Erlang setup either, it's just going to create an Erlang-powered signage system that crashes and halts the same as any other runtime would. Erlang/OTP is a physical systems building and software design approach that you can't just put anywhere or bolt onto any arbitrary thing. You're not going to build an OTP-like Single Page Application because if you reliably crash the browser tab's process every time you start up, it's just going to keep crashing no matter how many times you refresh the page.

Reply on news.ycombinator.com