Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust Is Surprisingly Good as a Server Language

stu2b50.dev

Post reply on HN
Print view View original

281–290 of 352 posts

Re: Rust Is Surprisingly Good as a Server Language

#281

Post by CJefferson »

fooyc wrote: post #170

It's sad that we still have to make async I/O explicit in the code to obtain some efficient concurrency in 2020. Async/await is a huge improvement over callback hell, but this doesn't fix everything. The "function color" problem still exists [1], and seems to be more than binary in rust. This quote from the article is incredibly sad: "each async library, comes its own ecosystem of libraries, which only work with that…

I would love to see some quality benchmarking of a non-trivial threaded solver in Rust.

As strongly suspect it will perform "well enough" (hopefully much better than async in Python, and hopefull javascript too), which is good enough for me to be able to escape async.

Re: Rust Is Surprisingly Good as a Server Language

#282

Post by adsjhdashkj »

thepratt wrote: post #98
jph wrote: post #6

I'm building with Rust, Rocket, Diesel, and agree with much of the original article. I can also add more: in my direct personal experience, the lead people creating Rocket and Diesel are superb about responsiveness, ongoing communication, and enabling people (e.g. me) to help diagnose issues and fix the them. I'm continually thankful for the quality of participation among the people in the ecosystem. On the technical…

Does having to develop against rust nightly over stable not worry you when attempting to productionize a service? I understand new features get shipped behind feature flags/language pragmas, but it seems like a massive looming risk.

Not OP, but: It does not for me, fwiw. However we release often, so i'm not releasing a binary into a distributed ecosystem where i expect it to live for years and years. In that scenario i would be wary of non-stable, since a looming issue in nightly could persist for an uncontrolled amount of time.

However thus far we have never had to push a release due to a bug found in nightly. We also have never had a build break because of nightly, or even upgrading.

The only breakage i'm aware of was, oddly, a semi-recent Rustup change. Our CI was not pinning the Rustup version, and the argument defaults changed so the downloaded Rustup did not have the components needed for our CI setup.

We will however migrate to stable once Rocket becomes stable. Thus far however, we've not had any trouble on nightly. I can only assume this is a result of the Rust teams excellent QA/tests/care/etc, combined with the language itself being very easy to write error-free code.

Re: Rust Is Surprisingly Good as a Server Language

#283

Post by steveklabnik »

whatshisface wrote: post #259
steveklabnik wrote: post #258

Earlier quoted context omitted.

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?

It exists as well, and if you want to use it, it's a short "throw the option in your cargo config and call it a day."

That being said, I'm not aware of it making any meaningful difference.

Re: Rust Is Surprisingly Good as a Server Language

#284

Post by estebank »

thepratt wrote: post #146
kibwen wrote: post #112

Earlier quoted context omitted.

Not that as of Rust 1.45, coming out this Thursday, Rocket will be able to target stable Rust: https://github.com/SergioBenitez/Rocket/issues/19#issuecomme... I believe Diesel has been on stable for a long time now, so for this use case I don't think anyone will need to worry about using the nightly releases.

That's good news! Wasn't aware of the pin change for rocket.

One more thing: I build my final binaries with stable (when possible), but develop with recent a nightly. There are some features that require nightly (custom testing frameworks come to mind) but don't affect the final binary (only tests) and I get the new goodies (better diagnostics, speed bumps, fixes) up to 12 weeks ahead of schedule.

Rustup makes having nightly and stable in the same machine painless, and I got in the habit of running cargo +stable build and cargo +nightly test. BTW, you don't have to do this, it just makes my experience a bit nicer.

Re: Rust Is Surprisingly Good as a Server Language

#285

Post by koheripbal »

ragnese wrote: post #276
koheripbal wrote: post #270

Earlier quoted context omitted.

You can absolutely create memory leaks in Rust [1]. That's a bigger problem for server applications than CPU / Memory performance issues, because the latter can be traced more easily. As a (mediocre) dev and head of a team (some are great, and some are as bad as me), I'm far more worried about bugs than performance. [1] https://stackoverflow.com/questions/55553048/is-it-possible-...

Depends what we're talking about. A "true" memory leak (as in allocated memory that is not referenced) is not very likely. A reference cycle with `Arc`s can happen though. But if you're talking about Java and mediocre devs (I'm in the club- don't worry), I feel like there are no shortage of ways to make bugs with null, concurrency issues, etc, that Rust completely eliminates. You can make reference cycles in Rust, th…

https://stackoverflow.com/questions/55553048/is-it-possible-...

Re: Rust Is Surprisingly Good as a Server Language

#286

Post by estebank »

jph wrote: post #105
thepratt wrote: post #98

Earlier quoted context omitted.

Does having to develop against rust nightly over stable not worry you when attempting to productionize a service? I understand new features get shipped behind feature flags/language pragmas, but it seems like a massive looming risk.

Developing based on Rust nightly has caused some learning curve gotchas, such as discovering a POSIX bug in the Rust install script, or needing to write a custom Docker Alpine Rust nightly container, or needing to write small system scripts to ensure that nightly is the same version on our various build machines. So far we've seen about 2/3 of nights fail for our code. The failure is totally obvious. So we revert to…

Depending on the level of maturity of the nightly features you rely on, for CI there is an env variable that makes the stable compiler think it is nightly. We use this flag at day job to use latest stable but be able to enable a handful of quasi stable nightly features (custom testing frameworks mainly and getting rocket to play nice). This is a double edged sword: it is the same as a pinned nightly in the sense that it is a static target, but differs in that bugs affecting stable and beta have been backported where any arbitrary nightly has no assurances one way or another, but bugs affecting nightly features aren't backported to the stable release and only fixed on nightly.

Also, for the love all that is holy do not publish a crate relying on that flag to enable the nightly features, it breaks the languages stability assurances and by extension the ecosystem.

Re: Rust Is Surprisingly Good as a Server Language

#287

Post by 65a »

deleuze wrote: post #250
entha_saava wrote: post #236

Earlier quoted context omitted.

I'd say Go is a fair comparison here. Type checking and Parsing isn't bottleneck in Rust compilation. Code generation is. LLVM is particularly heavy and while it generates optimized code, it is quite slow. Go Authors didn't pick LLVM because of compile speed reasons (as well as complexity), and that turned out to be worthwhile tradeoff.

The reason it's not a fair comparison is because go is a barely typed language that requires casting to interface non stop

If you're casting to interface{} non-stop, you are doing something against the grain of the language. It works, but there's probably a better way of getting the result you are looking for.

Re: Rust Is Surprisingly Good as a Server Language

#288

Post by zozbot234 »

estebank wrote: post #286
jph wrote: post #105

Earlier quoted context omitted.

Developing based on Rust nightly has caused some learning curve gotchas, such as discovering a POSIX bug in the Rust install script, or needing to write a custom Docker Alpine Rust nightly container, or needing to write small system scripts to ensure that nightly is the same version on our various build machines. So far we've seen about 2/3 of nights fail for our code. The failure is totally obvious. So we revert to…

Depending on the level of maturity of the nightly features you rely on, for CI there is an env variable that makes the stable compiler think it is nightly. We use this flag at day job to use latest stable but be able to enable a handful of quasi stable nightly features (custom testing frameworks mainly and getting rocket to play nice). This is a double edged sword: it is the same as a pinned nightly in the sense that…

Related: https://news.ycombinator.com/item?id=23351145

Re: Rust Is Surprisingly Good as a Server Language

#289

Post by estebank »

koheripbal wrote: post #285
ragnese wrote: post #276

Earlier quoted context omitted.

Depends what we're talking about. A "true" memory leak (as in allocated memory that is not referenced) is not very likely. A reference cycle with `Arc`s can happen though. But if you're talking about Java and mediocre devs (I'm in the club- don't worry), I feel like there are no shortage of ways to make bugs with null, concurrency issues, etc, that Rust completely eliminates. You can make reference cycles in Rust, th…

https://stackoverflow.com/questions/55553048/is-it-possible-...

That SO answer restates what the parent said: you can leak data either explicitly (Box::leak/std::mem::forget) or by creating reference cycles when using Arc/Rc.

Re: Rust Is Surprisingly Good as a Server Language

#290

Post by estebank »

jfkebwjsbx wrote: post #189
Lio wrote: post #125

Earlier quoted context omitted.

Rust is interesting in that it may eventually end up as a very useful language for WASM work. Rust has the advantage that when compiled to WASM it won't require a runtime library. So the prospect of Rust as a fast, low overhead, use anywhere language is tempting. Since Rust is a relatively new language it's worth checking to see how it's maturing over time against small low risk projects exactly as the author has don…

All that applies to several other very mature languages that can target WASM, like C. Nevertheless, WASM is not ideal for server work. It is intended for the frontend.

I am really looking forward to WASM as the technology of choice for language agnostic performant plugins. That is a backend niche.
Post reply on HN