Live data from Hacker News

Rust Is Surprisingly Good as a Server Language

stu2b50.dev

21–30 of 352 posts

Re: Rust Is Surprisingly Good as a Server Language

#21
Reading this I can't help but be lost trying to come up with any alternative solution for this specific use case that is worse than what they describe?

A bunch of mostly static blogs can be hand-edited HTML, or some ancient perl script, or any of the existing static site generators.

If it absolutely needs to involve server-side logic, it could be completely accomplished within a single call to ```rails init```, and the resulting project would incorporate a few $billion worth of collective experience commonly refered to as "best practice". It would be far easier to modify and far less likely to contain vulnerabilities. Performance would be worse by a factor of maybe x100, or "why are you asking these weird questions?" when converted to the real world, according to a representative survey of end users.

There's a good argument for replacing individual components on, say, the critical path for rendering people's twitter feed with lower-level implementations.

But it strikes me as unlikely that such endeavours would care about the ability of their ORM to quickly generate the migration scripts to drop or add some database columns.

So I can't quite see the benefit of cramming the rails model into Rust? Rails is spectacular in how it allows you to quickly iterate, adapt your data model, try some ideas, and so on. Those are qualities that just logically do not transfer to a world of static typing and manual memory management.

Re: Rust Is Surprisingly Good as a Server Language

#22
post #7

There is an advocate on our team that wants to migrate our web service from Nodejs to Rust. While I am not a huge fan of Typescript, at least libraries are readily available and generally easy to use. On the other hand, being able to show that we are able to do monitoring, user auditing, ORM, opentracing, gRPC-web with Rust is non trivial. Now that I think of it, being able to do a "hello world" on any language is pr…

Generally when I’ve successfully advocated for new languages or tools at work, it’s been by gradually introducing the language in newer and fairly self-contained projects where the risk is relatively low. This provides a safe space to explore all the concerns you just mentioned without compromising any working code.

If you have some interest in Rust, that’s what I’d personally recommend instead of migrating an existing service to a different language.

Re: Rust Is Surprisingly Good as a Server Language

#23

what about server debugging ? python as an interpreted language have a real advantage here. you can easily patch on production for example to debug or hot fix. you would need to rebuild and upload binary in the case of rust.

I've been writing Python for a few years now (at my job), and most of the situations where I've used breakpoint() to debug something would literally not have been possible in Rust because they would have been compile time errors instead of runtime errors.

Re: Rust Is Surprisingly Good as a Server Language

#24

what about server debugging ? python as an interpreted language have a real advantage here. you can easily patch on production for example to debug or hot fix. you would need to rebuild and upload binary in the case of rust.

This really only works in the case that you have one server running a python app that you can ssh into. Any deployments more complicated than that and it starts to break down.

Re: Rust Is Surprisingly Good as a Server Language

#25
post #9
post #7

There is an advocate on our team that wants to migrate our web service from Nodejs to Rust. While I am not a huge fan of Typescript, at least libraries are readily available and generally easy to use. On the other hand, being able to show that we are able to do monitoring, user auditing, ORM, opentracing, gRPC-web with Rust is non trivial. Now that I think of it, being able to do a "hello world" on any language is pr…

What is your take on TypeScript, what is it you don't like?

I come from a C# background, but to list out a few hurdles that I have already deal with with TypeScript/NodeJs.

  1. C#'s AsyncLocal has made a few things simpler to trace SQL queries to a request. 
  2. We chose to use hapi.js some 2 years ago, because we found the interface superior to Express, but I did not expect the sole developer of hapi.js to decide stop working on the project [1], and left my head scratching on what I am going to do about that. 
  3. TypeScript's interface sometimes feels too much like just "suggestions", and every once in a while run across scenarios that are not fully supported. One that I really dislike is that Sequelize's "where" options has no type support for the model. [2]
  4. Sometimes libraries does not use async correctly, and breaks stack traces.
  5. Sometimes TypeScript's generic errors can be as bad as C++.
My favorite feature of TypeScript is being able to just define types/objects in-line, but I actually like to stay on the side of caution and stability on a large project with many people.

[1] https://github.com/hapijs/hapi/issues/4111 [2] (GitHub is down, or I would grab the link)

Re: Rust Is Surprisingly Good as a Server Language

#27
Not the point of the article, so sorry about offtopic, but the workflow described in the first chapter feels a bit off. If they wanted dynamism, then writing a server is the way to go, but it seems that the easier fix to their problems as described there, would have been setting an automated CD pipeline that would build and deploy their blog every time you make a change.

Re: Rust Is Surprisingly Good as a Server Language

#28
post #7

There is an advocate on our team that wants to migrate our web service from Nodejs to Rust. While I am not a huge fan of Typescript, at least libraries are readily available and generally easy to use. On the other hand, being able to show that we are able to do monitoring, user auditing, ORM, opentracing, gRPC-web with Rust is non trivial. Now that I think of it, being able to do a "hello world" on any language is pr…

Rust is much too low level for most glue/web services. Unless you have a specific high performance requirement (and Go doesn't meet this), there's no real strong case for migration here.

Re: Rust Is Surprisingly Good as a Server Language

#29
post #7

There is an advocate on our team that wants to migrate our web service from Nodejs to Rust. While I am not a huge fan of Typescript, at least libraries are readily available and generally easy to use. On the other hand, being able to show that we are able to do monitoring, user auditing, ORM, opentracing, gRPC-web with Rust is non trivial. Now that I think of it, being able to do a "hello world" on any language is pr…

Rewriting is very expensive, and the advocate will need to make a VERY strong case for Rust if they're asking your company to invest in replacing it - and alternatives have to be suggested as well, including other languages and a good list of things wrong with Node / TS. Consider developer availability as well. I don't think a strong enough argument can be made. I'm sure you CAN write web services in Rust, and that i…

Yeah. I am being very cautious about their desires. I learned that the best way to discourage someone from taking a large project is to show how much work it would be. Just shutting down developers is not nice.

Re: Rust Is Surprisingly Good as a Server Language

#30
I tried Rust about a month ago. The language itself is amazing, the pattern matching is super expressive, the borrow checker is incredible in the kinds of errors it can pick up on, and rust-analyzer is leagues beyond where RLS was. But... the compile times are an absolute non-starter for me. I'm the kind of guy that likes to re-run his code continually to see if it validates to what I expect it to be doing. In Rust, this kind of workflow just doesn't work at all. The long compile times completely kill any enjoyment or flow that I normally get out of productive programming. Even worse, I found myself anxious to introduce new dependencies, because each new crate would add a few more seconds to the compile time, which immediately correlates to less coding enjoyment.

I keep reading in Rust surveys that Rustaceans just don't care that much about compile times enough to prioritize improving them. I've often wondered how this can be possible, given that to me it's such an obvious glaring issue that all the other cited problems are distant distant seconds at best. I have a theory: there must be two groups of engineers. One group loves fast compile times and quickly validating hypotheses. The other group must value thinking about their code a lot more than running it, and so compile times aren't that important. My guess is that, while the second group hangs around and loves Rust, Rust has completely driven away the first group (including myself) to the degree that they don't use the language enough to even fill out the surveys.

Anyways, I know it has a wide swath of use cases, mostly in systems programming. I'm just bummed that if I ever do any of them, I won't really enjoy it. :-(

[EDIT:] Gotta go to sleep, it's far too late here. I really appreciate all the thoughtful replies. Rust's amazing community is another reason it annoys me that I can't fully get into the language as I'd like to.

Post reply on HN