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

311–320 of 352 posts

Re: Rust Is Surprisingly Good as a Server Language

#311

Post by estebank »

johnfn wrote: post #301
steveklabnik wrote: post #196

Earlier quoted context omitted.

Let me put it a stronger way: if you're seeing your cargo dependencies recompile every time, it is a bug. Please file one upstream. These bugs do happen, but they are bugs.

I don't literally see my deps compile. It's just that compile time gets slower. (I wonder if it's related to the linker?) Is that still a bug? Would be happy to report it if so.

If the slowless you're seeing is caused by the linker, which can very well be the case, consider using LLD as you can see significant speed improvements to the linking step.

https://github.com/rust-lang/rust/issues/39915#issuecomment-...

https://doc.rust-lang.org/1.22.0/unstable-book/compiler-flag...

If installed, you can run

    RUSTFLAGS="-Clink-arg=-fuse-ld=lld" cargo build --release

Re: Rust Is Surprisingly Good as a Server Language

#312

Post by zozbot234 »

amelius wrote: post #294
zozbot234 wrote: post #246

Earlier quoted context omitted.

> when using closures you really don't want to be thinking about memory allocation You don't have to think about this with Rust - and you don't need a GC either. The borrow checker will make sure that your closure doesn't outlive the variables it captures, which is what you need for correctness in this case.

> The borrow checker will make sure that your closure doesn't outlive the variables it captures, which is what you need for correctness in this case. No, the borrow checker will merely give you an error when your closure may outlive the captured variables. This is often not useful, and is an impediment to being productive. As a programmer you don't want to be solving the same boring problem of memory management over…

> This is often not useful

How is it "not useful"? It's generally quite easy to resolve the ensuing lifetime problems: either use .clone() to copy the underlying values, or use Rc/Arc to provide shared control of the lifetimes involved. And it's far from a "boring problem"; quite often, being aware of how and why lifetime and mutability interact at a "low" level can inform higher-level design as well.

Re: Rust Is Surprisingly Good as a Server Language

#313

Post by wiz21c »

logicchains wrote: post #47
wiz21c wrote: post #45

Earlier quoted context omitted.

>> in a normal day I'd probably average hundreds to a thousand compilation cycles! Maybe it's time to switch to an interpreter ? :-)

Or a language like Go, C or Nim that can compile tens of thousands of lines of code in a few seconds.

I've used Nim just a bit on Windows/MingW (I'm from python world). The very short program I made (about 200 lines, mostly math stuff, no framework imports) compiles in 2-3 seconds. It's already too long for me to iterate (it's not a rant against Nim, it's just that it's too long for my way of working; the language is nice and gives good results). Also note that Nim compiles fast, it's the compile-to-native compilation step that takes 90% of the time.

Re: Rust Is Surprisingly Good as a Server Language

#314

Post by estebank »

neutronicus wrote: post #310
estebank wrote: post #271

Earlier quoted context omitted.

Could you expand on this? It seems like you might have a really interesting point to make but I can't tell what it is :)

Short compile times are beneficial when development involves a lot of trial-and-error. The parent comment was insinuating that, when developing in Rust, one can leverage its type system to replace this trial-and-error with static verification. And, indeed, if what you're worried about is a dangling or null reference error, the Rust type system has a rich language for specifying expected behavior so you don't have to…

I see, the type system cannot ensure logic bugs, specifically with an applied example of the visual aspect of an application. Got it. Thank you for expanding on it!

Re: Rust Is Surprisingly Good as a Server Language

#315

Post by Hercuros »

michalhosna wrote: post #304
strangescript wrote: post #192

Earlier quoted context omitted.

People seem desperate for one language to rule them all. If you don't need a binary, blazing fast multi-threaded speed, and memory safety then you probably don't need Rust. "Need" being the big thing here. Do you need these things or are they just nice to haves in your head. A scripting language and a web browser can solve a surprising amount of application requirements these days, and its only getting better with ti…

Yes, you need memory safety, everyone needs memory safety. And if you can write program in very fast language, why not? There doesn’t have to be need. Just no reason not to

If you can afford a garbage collector, then you can also just use something like Haskell or OCaml or Python, which also gets you memory safety. No need to think about lifetimes or different types of smart pointers. Not saying that it’s a lot of mental overhead, but it’s definitely a trade-off.

Re: Rust Is Surprisingly Good as a Server Language

#316

Post by amelius »

zozbot234 wrote: post #312
amelius wrote: post #294

Earlier quoted context omitted.

> The borrow checker will make sure that your closure doesn't outlive the variables it captures, which is what you need for correctness in this case. No, the borrow checker will merely give you an error when your closure may outlive the captured variables. This is often not useful, and is an impediment to being productive. As a programmer you don't want to be solving the same boring problem of memory management over…

> This is often not useful How is it "not useful"? It's generally quite easy to resolve the ensuing lifetime problems: either use .clone() to copy the underlying values, or use Rc /Arc to provide shared control of the lifetimes involved. And it's far from a "boring problem"; quite often, being aware of how and why lifetime and mutability interact at a "low" level can inform higher-level design as well.

Reference counting doesn't solve all memory management problems. With closures you often end up with circular references.

And yes, in probably 99% of cases you can actually find a way out of a memory management problem in Rust if you think hard enough.

But my point is that quite often you don't want to think about memory management. Rust doesn't help here. Rust advertises that it solves memory management problems, but in reality that only holds up to a point. So use Rust for your OS or your low-level server, but don't think it is a panacea.

Re: Rust Is Surprisingly Good as a Server Language

#317

Post by johnfn »

estebank wrote: post #311
johnfn wrote: post #301

Earlier quoted context omitted.

I don't literally see my deps compile. It's just that compile time gets slower. (I wonder if it's related to the linker?) Is that still a bug? Would be happy to report it if so.

If the slowless you're seeing is caused by the linker, which can very well be the case, consider using LLD as you can see significant speed improvements to the linking step. https://github.com/rust-lang/rust/issues/39915#issuecomment-... https://doc.rust-lang.org/1.22.0/unstable-book/compiler-flag... If installed, you can run RUSTFLAGS="-Clink-arg=-fuse-ld=lld" cargo build --release

Looked into this :) unfortunately I run Mac so there's nothing I can do here. Tempted to dual boot Ubuntu, though.

Re: Rust Is Surprisingly Good as a Server Language

#318

Post by zozbot234 »

amelius wrote: post #316
zozbot234 wrote: post #312

Earlier quoted context omitted.

> This is often not useful How is it "not useful"? It's generally quite easy to resolve the ensuing lifetime problems: either use .clone() to copy the underlying values, or use Rc /Arc to provide shared control of the lifetimes involved. And it's far from a "boring problem"; quite often, being aware of how and why lifetime and mutability interact at a "low" level can inform higher-level design as well.

Reference counting doesn't solve all memory management problems. With closures you often end up with circular references. And yes, in probably 99% of cases you can actually find a way out of a memory management problem in Rust if you think hard enough. But my point is that quite often you don't want to think about memory management. Rust doesn't help here. Rust advertises that it solves memory management problems, bu…

> With closures you often end up with circular references.

In that case, you can manually lift the data object involved into a function argument, as opposed to a variable capture - with its ownership being thus managed explicitly. This is generally an improvement in design.

Of course, Rust does only solve memory management problems "to a point"; there are cases where fully general GC is pretty much a necessity. But even most uses of closures - a fairly high-level language feature, all things considered - don't require this in many cases.

Re: Rust Is Surprisingly Good as a Server Language

#319

Post by johnfn »

steveklabnik wrote: post #309
johnfn wrote: post #299

Earlier quoted context omitted.

Here's the exact thing that I checked when making this conclusion a few weeks back, the most up-to-date state of the compiler roadmap that I could find: https://rust-lang.github.io/compiler-team/minutes/design-mee... I see 16 top-level goals on here for next year (under the Goals section). The only thing that seems related to compile speed is to continue working at incremental compilation (no new initiatives?). And e…

Ahh I see. Yes, so that's meeting minutes, so they're very inside baseball, and so it would make total sense that you would get this impression from this. Before we get into that, to answer the other question: > But I'm not sure what you mean by "it compiles the code every save." Rust-analyzer (by default) will run "cargo check" on save. cargo check does everything except codegen, so it won't give you something you c…

Mostly, that makes sense. I think the thing that doesn't make sense to me is that rust-analyzer seems to me to be a LSP - my mental model of it has nothing to do with codegen. And I thought that codegen and linking was the slow part in Rust (cargo check runs so fast!), so how could those gains be brought back to rustc? I'd bet other people have this misconception, too - maybe that should be highlighted on the rust-analyzer readme on Github.

If rust-analyzer will eventually introduce those gains to rustc, that is fantastic news, and I'll be watching it with great interest! The improvement from RLS to rust-analyzer is exactly the type of improvement that brought Rust from the "fascinating tech demo" to "I could actually see myself using this day-to-day."

And yeah, I'd love to read a blog that went into more detail.

> working on individual PRs to make things faster. See https://blog.mozilla.org/nnethercote/ for one of the largest contributors in this regard

Yeah, I read through that too. He's my hero! :-) But the feeling I got when reading it was: "fast compile times" really need to be part of the DNA of a language. Let me explain what I mean. Some languages, like Go and TypeScript, have this in their DNA, and that means that every design decision and every addition to the language is considered seriously through the lens of compile time speed, and vetoed if it were too costly. But with Rust, the fact that there's one guy writing a blog post about some incremental wins he managed to chalk up just... doesn't seem like it's part of the DNA. If it is, why is it just one guy, and why do a lot of his changes seem more like incremental wins than the big sweeping changes I'd expect to be necessary? I could definitely be wrong here (sounds like I am and rust-analyzer is that big sweeping change).

Thanks for all your great responses, by the way. I really appreciate it!

Re: Rust Is Surprisingly Good as a Server Language

#320

Post by atombender »

entha_saava wrote: post #236
wwright wrote: post #195

Earlier quoted context omitted.

Ocaml is a somewhat fair comparison, but I have to say that Go is really in no way comparable to Rust. Rust is massively more complex.

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.

Go's authors didn't pick LLVM because they weren't sufficiently familiar with it to implement what they needed (e.g. segmented stacks). See https://news.ycombinator.com/item?id=8817990 for the full explanation.
Post reply on HN