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

301–310 of 352 posts

Re: Rust Is Surprisingly Good as a Server Language

#301

Post by johnfn »

steveklabnik wrote: post #196
johnfn wrote: post #64

Earlier quoted context omitted.

A new empty project compiles in under a second. However, adding dependencies will add some arbitrary number to this. Additionally, every hundred lines of code seems to add some amount of time between half a second and a whole second. I did some reading and read that generics are particularly expensive to compile, so I wonder if that accounts for the variance. I can't explain why cargo deps add time, though. I LOVE ru…

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.

Re: Rust Is Surprisingly Good as a Server Language

#302

Post by randyrand »

johnfn wrote: 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,…

Is there interest in a rust interpreter? Would it be too slow to be useful?

Re: Rust Is Surprisingly Good as a Server Language

#303

Post by jasonpeacock »

johnfn wrote: 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,…

Can you share how long your compile times are? And what you feel is are "usable" compile times?

I see comments a lot about "this is too slow" but rarely are numbers provided, neither the actual times nor the expected times.

You may have something setup wrong and are seeing unusually long compile times. Or your expectations may not be realistic. Or you're just an outlier whos work triggers some pathological compile issues.

But without data, we can't know what's going on.

Re: Rust Is Surprisingly Good as a Server Language

#304

Post by michalhosna »

strangescript wrote: post #192
johnfn wrote: 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,…

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

Re: Rust Is Surprisingly Good as a Server Language

#305

Post by johnfn »

jasonpeacock wrote: post #303
johnfn wrote: 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,…

Can you share how long your compile times are? And what you feel is are "usable" compile times? I see comments a lot about "this is too slow" but rarely are numbers provided, neither the actual times nor the expected times. You may have something setup wrong and are seeing unusually long compile times. Or your expectations may not be realistic. Or you're just an outlier whos work triggers some pathological compile is…

Sure. In an empty project, I saw around 0.7s compile times. This is ideal. But I kept developing and added around 300 lines of code and a few (3?) dependencies to my cargo.toml, and I was seeing compilation times that were exceeding 10 seconds to, say, add a dbg! message.

10 seconds is basically as slow as I'd accept. I wouldn't love it, but I'd suffer through it if I had to. But what I really didn't like was that my feeling was it wasn't the bottom - adding more deps or more lines of code looked like it would continue to increase the time without bounds.

I like doing a lot of game dev and graphical work, and it often requires really rapid iteration to test small changes. (How fast should the AI walk? Should he turn around at this point? Does this logic "feel right" like this, or do I need to trigger it conditionally?)

Re: Rust Is Surprisingly Good as a Server Language

#306

Post by johnfn »

teraku wrote: post #82
johnfn wrote: post #46

Earlier quoted context omitted.

No, it's an issue for warm caches as well. I had a 10 second compilation cycle to add a comment to a file in a project with a couple hundred lines of code and like 4 lines in my cargo.toml. 10 seconds! For a few hundred lines! Maybe that doesn't sound insane, but extrapolating out, that's at least 100x worse than the languages that I'm used to. (I know that compilation speed is a Hard Problem, I know that I'm compari…

What? I have a ~1k LOC program which consists of 4 modules, 3 of them all importing the 4th and in total ~200 dependencies. With a warm cache my program takes ~2s to compile. Cold-cache is about 18s

Interesting! I wonder if I was hitting some pathological case with my dependency tree.

Re: Rust Is Surprisingly Good as a Server Language

#307

Post by johnfn »

_-___________-_ wrote: post #60
johnfn wrote: post #46

Earlier quoted context omitted.

No, it's an issue for warm caches as well. I had a 10 second compilation cycle to add a comment to a file in a project with a couple hundred lines of code and like 4 lines in my cargo.toml. 10 seconds! For a few hundred lines! Maybe that doesn't sound insane, but extrapolating out, that's at least 100x worse than the languages that I'm used to. (I know that compilation speed is a Hard Problem, I know that I'm compari…

> I had a 10 second compilation cycle to add a comment to a file in a project with a couple hundred lines of code and like 4 lines in my cargo.toml. Why compile again after adding a comment?

This was meant as an example, not something I'd literally do.

The most common trivial change would be to add a dbg! statement.

Re: Rust Is Surprisingly Good as a Server Language

#308

Post by steveklabnik »

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.

Ahh.

I am less sure, but I would think that's expected, given that it has to link everything together into the final binary. You're gonna end up giving the linker more work to do, as you suspected.

Re: Rust Is Surprisingly Good as a Server Language

#309

Post by steveklabnik »

johnfn wrote: post #299
steveklabnik wrote: post #194

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. I am interested in how you got that impression, because at least in our official surveys, it's often one of the most-requested improvements to Rust, and it's something that we're constantly working on improving. Still a ton of work to do though! For what it's worth, my workflow is closer…

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 can run, but it does invoke the full set of compiler analyses and everything else.

Now, what it does with the type-check stuff is the key to understanding what you're missing from the compiler team roadmap, funny enough. So rust-analyzer is actually going to end up merging with the rustc codebase eventually, if all things go to plan. Basically, rust-analyzer is slowly re-implementing the compiler from the outside in. It's doing this because the best way to get the largest win on compile times is to completely re-architect the compiler. This comment is too long, so I won't get into too many details, other than to say that it's going to be less like the Dragon Book and more like C#'s Roslyn, if that means anything to you.

It's doing this by taking advantage of a process called "librarification," which is extracting stuff from the compiler into re-usable libraries. You can see this on the notes when they talk about chalk; chalk is the next-generation trait resolution system. This is integrated into rust-analyzer, and into the compiler. So slowly, bit by bit, things are being re-architected and integrated in a way that will be much, much better in the future.

So this is a massive, massive project that touches everything, and so there's nothing spelled out in the minutes that says "this is for compile times" because the folks involved already have this context, basically.

And so yeah, that's the big project. There are also contributors who, while this larger work is going on, are working on individual PRs to make things faster. See https://blog.mozilla.org/nnethercote/ for one of the largest contributors in this regard, that talks about the work he's doing. But that doesn't appear on this either; there's no need for a plan or coordination here.

... does that all make sense? I am thinking maybe it would be good for us (to be clear, I mean the Rust project, I am not on the compiler team and am not doing this work) to like, actually write a blog post on all of this...

Re: Rust Is Surprisingly Good as a Server Language

#310

Post by neutronicus »

estebank wrote: post #271
neutronicus wrote: post #211

Earlier quoted context omitted.

Rust's type system doesn't have a notion of "looks right visually," so the compiler is ipso facto unhelpful there

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 run your code to check it.

If, on the other hand, your job description includes the nebulous mandate to "make it look right," there isn't any feasible way to design your types so that Rust can check that. For example, sometimes I have to do something like "make sure the dialog box is wide enough that it doesn't truncate the title string on any relevant platform." The Rust type system has no way for me to query several versions of macOS and Windows about when they start truncating dialog-box title strings and size my dialog that way, so here I am, still performing this task by trial-and-error, waiting forever to compile my code each time.

Nothing about this is Rust-specific by the way. I'm similarly bearish on statically-verified cross-platform dialog boxen in Haskell. And that's one of my dumber "make it look right" tasks - I work on CAD software so most of them involve 3-D graphics and/or computational geometry.

And, returning to the parent comment, waiting for C++ to compile in order to test things is a giant fucking time-sink and drain on my productivity. It can't really be automated, or, if it can, it's way beyond the reach of this organization's know-how.

In summary, I call bullshit on static verification replacing snappy trial-and-error in the UI / Graphics space. In practice, you're left shifting UI / Graphics customization out of the host language and into "content" so that you can tweak it without re-compiling. But this is another massive fucking time and complexity sink that only exists because at some point you let your compile-times get so far out of control that your people couldn't do their job ("make it look right") in a reasonable amount of time.

Post reply on HN