Live data from Hacker News

Rust Is Surprisingly Good as a Server Language

stu2b50.dev

251–260 of 352 posts

Re: Rust Is Surprisingly Good as a Server Language

#251

I'm glad to see this post here. Just because I hear/read a lot of people outright dismiss Rust's potential here with arguments that kind of miss the point: 1. You don't need CPU performance for most web stuff. It's all IO bound. 2. Related to #1, garbage collectors are fine and you don't need the Rust model. 3. Rust is so hard to learn that it isn't worth it unless you need the performance. There's so much more to Ru…

Can someone elaborate on why #2 is wrong on the server level? My systems are not performance bottleneck'd and as a Java dev I'm more worried about the potential for memory bugs (which I admit I will create) if I stray away from automatic garbage collection.

It's not wrong. I didn't mean to imply that. I just mean that saying non-GC languages are about performance overhead of the garbage collector is missing the point.

Sometimes, it's convenient and easier to reason about stuff when you can predict when something is actually dropped from memory.

And in Rust, you wouldn't create those memory bugs you're worried about. (Well, you can, but you have to go out of your way to take the safety off :)) That's kind of Rust's whole "shtick"

Re: Rust Is Surprisingly Good as a Server Language

#252

Earlier quoted context omitted.

I assume you mean static typing enabled. Because lisps are already dynamically typed to begin with.

Thanks, I actually meant gradually typed systems, like rust typed or closure with heavy spec usage.

As a spec user in production, I must say it's very nice usability-wise and can help alleviate most of the issues coming from a lack of a type system.

But god it's slow... Some static analysis support would also be hugely appreciated. Not being able to check everything doesn't meen you shouldn't attempt to check something! Many specs are type predicates anyway.

Re: Rust Is Surprisingly Good as a Server Language

#253
post #180
post #93

Earlier quoted context omitted.

The ecosystem, i.e. Spring.

I have not used spring and only ever seen hate for it. Would be nice to read a pro-spring article or similar.

It's like any framework: once you learn it's idioms, you can be insanely productive. Unlike other frameworks, enterprise Java is all about flexibility, so in Spring land, it's often in incredible easy to tune or replace lower level components like connection pools, etc.

As such, I'd describe it as a good combination of highly dynamic architecture with lots of manual control. Of course, all of this is enabled with copious amounts of magic, which is usually why people don't like Spring.

Re: Rust Is Surprisingly Good as a Server Language

#254
post #120

Earlier quoted context omitted.

Rust itself is not inherently "low level" per se. But others are probably right that the whole web services ecosystem for Rust is rather half-baked at this time, the OP notwithstanding.

Actually the OP only wrote that the current state of the ecosystem is surprisingly mature, but he doesn't recommend writing anything serious in it yet. Personally I don't see the point to implement a typical web application in Rust - the performance improvements you get will be lost on IO-bound applications, but you'll still be saddled with the complexity of the memory management. I'd rather suggest to rewrite VS Cod…

Stability is often more important than performance.

Re: Rust Is Surprisingly Good as a Server Language

#255
post #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,…

> I keep reading in Rust surveys that Rustaceans just don't care that much about compile times enough to prioritize improving them. Confusing since this is, to my knowledge, a top 3 issue just about every year. That said, I think Rust programmers dislike compromise (maybe to a fault). Rust is naturally a 'have your cake and eat it to' language and the community very much likes to be best-in-class, so compromises on r…

>compromises on runtime performance to improve compile time (which is one way you can go today) are often not seen as viable by a large part of the community.

Typically this tension would be resolved with o-level flags (O1, O2, O3...).

Re: Rust Is Surprisingly Good as a Server Language

#256

Earlier quoted context omitted.

Oof, there are people out there that like to work with Spring? The over-engineering in the Java ecosystem has wasted more of my time than saved it.

The learning curve should be beaten after a few weeks and is definitely lower than learning rust. On the other hand, the productivity and expressiveness return on investment is huge. Spring is arguably the state of the art framework on the server and is integrated with so many powerful technologies.

[deleted]

Re: Rust Is Surprisingly Good as a Server Language

#257
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 are the advantages of Rust? Probably speed, robustness, but probably not speed of development and iteration.

If you're doing image processing, you may want to have node.js do the user interaction bits, and have the sophisticated image processing in Rust.

But I don't really see Rust as the go-to platform for crud APPS with DB access etc..

Re: Rust Is Surprisingly Good as a Server Language

#258

Earlier quoted context omitted.

> I keep reading in Rust surveys that Rustaceans just don't care that much about compile times enough to prioritize improving them. Confusing since this is, to my knowledge, a top 3 issue just about every year. That said, I think Rust programmers dislike compromise (maybe to a fault). Rust is naturally a 'have your cake and eat it to' language and the community very much likes to be best-in-class, so compromises on r…

> compromises on runtime performance to improve compile time (which is one way you can go today) are often not seen as viable by a large part of the community. Typically this tension would be resolved with o-level flags (O1, O2, O3...).

Rust has those, though most people interact with them through cargo (with --release corresponding to O3 and not passing it to O0.)

Sometimes, non-release builds are too slow to meaningfully run. It is not uncommon for release builds to be extremely faster than debug builds.

Re: Rust Is Surprisingly Good as a Server Language

#259

Earlier quoted context omitted.

> compromises on runtime performance to improve compile time (which is one way you can go today) are often not seen as viable by a large part of the community. Typically this tension would be resolved with o-level flags (O1, O2, O3...).

Rust has those, though most people interact with them through cargo (with --release corresponding to O3 and not passing it to O0.) Sometimes, non-release builds are too slow to meaningfully run. It is not uncommon for release builds to be extremely faster than debug builds.

Might we get an -O2?

Re: Rust Is Surprisingly Good as a Server Language

#260
I've taken the deep dive into Rust API service development the past few weeks. I really enjoy the experience of developing in Rust, but not so much the experience of using Rust web frameworks, somewhat in line with the author.

In particular, even having a relatively small set of feature requirements it has been difficult finding a web framework that supports: Middleware, Websockets, easy routing, and async handlers.

Actix probably supports all of those, but I don't much like development in it and prefer to avoid the drama of Actix. Surprisingly, none of the other libraries I've looked at support all of those (except possibly Gotham, but I ran into other issues with it).

I'm not sure what my takeaway is, other than that web frameworks still have a ways to go, and development on each of these web frameworks seems slow, I think because of the lack of companies picking them up. I also get the impression that people are somewhat obsessed with doing it the "Rust way", rather than just getting a simple completed web framework out the door.

However, I love working in Rust, and think I may reach a point where I'm actually more productive in it than something like Typescript. There's just a large learning curve. But it's fun.

Post reply on HN