Hacker News Reader

Comment by msoad | Hacker News Reader

I always wondered if the safety and correctness that Rust offers is needed in a CRUD application? Do you think it pays off to work in the extremely strict system where you can't just cast to any and move on with your product features?

View on HN

This is something I thought about a lot before switching to Rust at Svix[0]. What I came to realize though, that there are no "casts to any and move on", but rather there are silencing real bugs and praying you won't hit them.

Almost every time I've ever tried to silence the type checker (in any other language) it resulted in a bug.

Does it make you slower? Definitely at times, but it's mostly OK, and the code is pretty damn clean. You can check out our repo to see how it looks[1].

Edit: we don't use Actix, we use Axum, but the same holds for Actix too.

[0] https://www.svix.com

[1] https://github.com/svix/svix-webhooks

+1 for Axum. I recently moved [1] the Rust Playground's backend to Axum and have been very happy with it and the team producing it.

[1]: https://github.com/integer32llc/rust-playground/pull/777

> Almost every time I've ever tried to silence the type checker (in any other language) it resulted in a bug.

What does it even mean? You can't silence a type checker.

You can in JS/TS and Python. Technically you could even do it in a language with a fairly strong type system like C# or Java by casting to object or dynamic, though the code using the cast object after that will probably be very unidiomatic.

Can't you cast to any in Rust as well?

To expand on the others, unlike in TS/JS, Python etc you can cast to the `Any`-trait but cannot use it as if it is any value, you need to convert it to the type you want and then handle the errors. A function that accepts `&str` will never accept a `Any` value, unlike in TS where you can override the type checker using `as`. Worth noting that TypeScript's type system is unsound [0] too.

[0]: https://www.typescriptlang.org/docs/handbook/type-compatibil...

No. Rust does not have the equivalent of Object or void *.

There's the Any trait [0]. Not sure if this is exactly like void* in C, but this doesn't look particularly ergonomic to use.

[0] https://doc.rust-lang.org/std/any/index.html

Exactly what the sibling comment said, you can do it in many languages. Also, the comment I replied to suggested just that ("cast to any"), which is the context. :)

If you're writing software that will be long-lived with multiple developers, the safety, correctness and strict type system is absolutely necessary for maintainability and refactoring purposes alone. Even for a CRUD app (maybe especially for a CRUD app as you're marshaling objects of different types around, usually), and even when runtime speed is a secondary concern.

But a higher level language with a GC and good types would be more productive , I would suggest to also check the ecosystem not only the language, the access to documentation, and developers (if you need to build a team). From my experience big projects suffer not because of the language but because of bad architecture caused by inexperienced developers.

I don't disagree with the ecosystem argument, nor the argument that poorly thought out architecture is a big cause, as well. I don't think having a GC de facto makes you more productive and that's worth arguing about itself.

My point was that having the ability to perform "fearless refactoring" to improve architecture and adapt to changing needs of the software needs ruthless type system support to catch the non-obvious areas that you just broke and make sure that API contracts are still correct and to make sure you're not deserializing random stuff into `interface{}` or worse, `Any`, `Value` or `void *`.

We had strong types and languages that allowed that before Rust, I do not understand why would people push Rust everywhere and not focus on the stuff it is actually good at like low level stuff where performance and safety is needed.

> the safety, correctness and strict type system is absolutely necessary for maintainability and refactoring purposes alone

Erlang would beg to differ, and it has been continuously running on systems with uptimes longer than rust has existed.

I work on CRUD for life.

Rust is GREAT for that.

Is not the safety (borrow checker) but the combination of: Bare structs, enums, pattern matching and some traits (like Into) that make a breeze modeling business rules.

Basically any ML derived language, with the added value of automatic memory management.

Any web (or any RPC) facing app that needs high performance and security should consider using Rust frameworks (or go). They are far more efficient than the interpreted languages and 1 server can usually replace several in such cases. It's well worth converting 1 or 2 "small" microservices that require "significant" server side "work" in comparison to interpreted stuff like rails and python.

Once you acquire the capabilities to do the work efficiently with Rust, it's hard not to use it even for smaller CRUD applications. You'll have a stronger, faster system that uses resources efficiently. It's a good tool for team development efforts, too, as you refactor each other's code and quickly find out what requires fixing (way before releasing to production).

> Once you acquire the capabilities to do the work efficiently with Rust

The problem is getting to that point.

I only tried Rust once, two years ago. The type system was fighting me all the way: the types different libraries were using were incompatible with each other, there was no obvious way to properly convert between them, finding proper signatures and behaviors was pain as many things were in traits or macros etc.

A lot of this comes down to tooling and ecosystem maturity, so things may have improved.

I had a few really strong reasons to push through, but it is understandable why others decide not to. It hasn't been cheap. I ate sunk costs plenty by adopting too early. I get angry at how much better the ecosystem and resources are now than when I started!

This aside, you'll still battle with the compiler. As to what you're battling depends on what you're building.

This.

I still write Python for quick scripts, but if it's gonna be a page or more of logic I give up and write it in Rust. Compile times for quick scripts, in practice, don't really bother me, and cargo is fantastic for "just work please".

I think there are quite some macros that accelerate a CRUD creation app, for example, take a look at sqlx with ormx: https://github.com/NyxCode/ormx

Reply on news.ycombinator.com