Comment by alerighi | Hacker News Reader

Comment by alerighi | Hacker News Reader

Parent Full thread

Recently I worked on a project where initially we though about writing it in Rust, because why not, it seemed initially a good idea. It turned out to be a completely wrong idea. The project was a simple web API, nothing fancy, GraphQL and a SQL database. After a lot of frustrations we decided it to rewrite everything in TypeScript and did that in a week.

TypeScript gives you the benefit of statically typed languages with the benefit of dynamic typed languages, in the sense that you type only what you decide to type, you don't have to type everything from the beginning, if you want to test something fast just stick and any type or simply ignore TypeScript errors and come to fix the errors later.

Dynamic features are also necessary, for example Rust lacks of a decent ORM, there is Diesel that is implemented with macros and breaks every time, plus is not a real ORM but rather a layer on SQL syntax, doesn't automate nothing.

Also compilation time has to be considered. Rust is so slow to compile, especially when you start to have 200 dependencies, with some that include a lot of macros. That means that testing is so much slower. With dynamic languages you can even have hot reloading of your code.

I'm not saying that statically typed languages are stupid, there are situation where they make a lot of sense, for embedded or system programming for example I would never use node, and surely Rust will have a future in these contexts.

But the point is that you should use the most appropriate tool for the job, and a dynamic language is in a lot of contexts the appropriate tool.

> writing it in Rust, because why not

I think this is the problem rather than static typing or rust.

Can you tell me what do you want your ORM to do?

Are you at all surprised that you picked a language you don't have very much experience with on a whim and the project turned out to be a failure?

Why did you decide to use a system programming language to build a web api? That's 100% the wrong tool for the job.

In their defence, rust is alright to spin up simple APIs or even complex backends. It wouldn't take me more than a few hours to write a small graphql api in rust.

If they decided to write an API in rust just because, chances are it's not anything important (I hope). From their post, it seems like lack of familiarity is the core issue.

I went from Node.js to Rust and this is what it sounds like to me.

There has been a movement in the Rust community to position it as good for backend web development. This is why there's been so much work on async, excitement about Actix, etc. It's not hugely surprising that this has given outsiders the impression that Rust might be a good choice for backend web development.

The reasons for this movement escape me. We already have many good options for backend web development. None of Rust's unique strengths offer any advantages for it. Focus on web has diverted effort from areas where Rust could really make a difference, like embedded, drivers, and desktop.

The best i can come up with is that a lot of people have come into Rust from other languages where web development is a big deal (eg Ruby), and it's just impossible for them to imagine that a language could be good and successful without winning at web development.

What problems did you encounter while writing your app in rust?

Which particular TypeScript ORM and web stack did you go with?

Not GP but I am guessing Apollo/express + typeorm and typegrapqhl

Or something like prisma - https://github.com/prisma/prisma2

To add to this, dynamic typing is proper tool to use for API, because the input payload is just formatted text, without / with very few type definition. My experience said that it's hard to play with JSON on static typing, without adding a strict data validation / conversion at the start. Serialization comes with a set of strict rules that need to follow and state beforehand too.

The contrary, on dynamic typing language nested object as well as array can easily be parsed natively and be used immediately.

This is absolutely false. Not a single word you have written in this comment is true. This is a pervasive myth that you are perpetuating. If you had read the article, you would know that what you have said is demonstrably false.

There is nothing stopping you from operating on arbitrary JSON in Haskell.

Literally nothing.

I suspect the parent wants to convert between JSON and typed records without needing the JSON to conform to the type.

Ok, but this works just fine in Haskell. If you have a well-formed JSON string and you want to parse it as a generic value, you can parse it into the Value type. If you have a typed record (something less general than a Value) and a JSON string that has enough of the structure to be parsed into that typed record, you can parse it into that typed record. If the JSON string has extra structure/data/fields your parser didn't expect, it's fine. Your JSON parser in Haskell can ignore those extra things. Just like any dynamic language.

All of this was demonstrated in the article.

We switched out some API code from Perl and Python to Go. JSON has been a pain at times for sure. Arbitrary nesting, values that are sometimes strings or sometimes integers (3 vs "3"), dynamic keys, and null vs zero value. These JSON structures were much easier to deal with before because we could be sloppy. Having to have a typed schema was a pain at first, but we love it after. And better yet, we can be confident of the values that we emit and our customers (internal and external) can be now use something statically typed if they like as we did all the heavy lifting.

It sounds like you think adding a conversion at the start is difficult and cumbersome, but it isn't if you use a good serialization library. E.g. with the Rust library serde, you just define the shape you expect your JSON data to have and plop a #[derive(Deserialize)] on it. Boom, fully failsafe JSON deserialization into the type.

Reply on news.ycombinator.com