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

321–330 of 352 posts

Re: Rust Is Surprisingly Good as a Server Language

#321

Post by johnfn »

smt88 wrote: post #87
johnfn wrote: post #75

Earlier quoted context omitted.

Perhaps my examples were a little too trivial. I do a decent amount of game/graphics coding, so there's a lot of "hmm, does this look good 20 pixels over? How about 18?" and I don't know how you'd get around that without recompiling. (OK, you could read preferences from a file, but then you'd have to optimistically write every value you'd ever want to recompile to a file. I've tried this, but it's far too much overhe…

> I do a decent amount of game/graphics coding, so there's a lot of "hmm, does this look good 20 pixels over? How about 18?" and I don't know how you'd get around that without recompiling. I know exactly what you mean. Front-end development can be this way, too. I think it's OK (and probably true) to say that you shouldn't use Rust for cases like this right now.

Yeah. It's a bummer because Rust would be a fantastic language for gamedev otherwise, and a lot of people are interested in it for this reason. It's got everything else you'd want out of a good gamedev language - no GC, smart memory model, blazing perf, really expressive...

Re: Rust Is Surprisingly Good as a Server Language

#322

Post by steveklabnik »

johnfn wrote: post #319
steveklabnik wrote: post #309

Earlier quoted context omitted.

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-an…

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

Any time. :D

A couple more brief comments:

> rust-analyzer seems to me to be a LSP

Remember that LSP is a protocol, something/someone has to actually figure out the answers. Like, the LSP says "please draw the squiggles here", but something has to actually say "line 1, column 10, please". Doing that involves semantic analysis, which is what a compiler does.

> And I thought that codegen and linking was the slow part in Rust

It is the slowest part of the current architecture, but that doesn't mean that the current architecture is the best possible one.

The RLS invoked the compiler, and then examined its output to say "line 1, column 10, please". And you said you saw the improvement with the architectural switch to rust-analyzer. Same thing.

> "fast compile times" really need to be part of the DNA of a language.

You are correct that, when push comes to shove, if there's a tension between, say, runtime speed and compile-time speed, Rust will choose runtime speed. Rust will not have compile speed as high up on the list of concerns as Go does. But it is important enough that we don't let major regressions happen, and actively pursue improvements where possible. https://perf.rust-lang.org/ for example, tracks this data over time for this kind of reason.

> why do a lot of his changes seem more like incremental wins than the big sweeping changes I'd expect to be necessary?

Well, again, it's not always either or. He's doing the incremental thing, and others are doing the big sweeping changes thing. His improvements land nearly every release, but the bigger projects take a lot longer. They work in tandem to make things better than they were before.

Re: Rust Is Surprisingly Good as a Server Language

#323

Post by estebank »

johnfn wrote: post #317
estebank wrote: post #311

Earlier quoted context omitted.

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.

It's a shame. I'm on the same boat and not being able to use lld adds a literal minute to my builds :-/

Re: Rust Is Surprisingly Good as a Server Language

#324

Post by michalhosna »

Hercuros wrote: post #315
michalhosna wrote: post #304

Earlier quoted context omitted.

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.

Agreed. I am not saying that rust is best for everything. I think, that languages are just tools, and you should use the best tool for the job, there should not be fanboyism in this. The bigger your toolbox the better.

I just don't agree with statements about memory safety and speed. The thing is much more complex. I think simply stating "Use the best tool for the job" is much better than showing bad examples.

Because everybody needs memory safety and wants speed. Nobody wants to write unsafe slow programs (Well, I HOPE). Nobody wants to drops either of those requirements. When you drop those requirements, it's because of tradeoffs (I think memory safety shouldn't ever be dropped, yes use GC lang if you want to, but in 2020 memory safety should be a very hard requirement)

Re: Rust Is Surprisingly Good as a Server Language

#325

Post by fish45 »

jfkebwjsbx wrote: post #214
FridgeSeal wrote: post #185

Earlier quoted context omitted.

But I don’t? The borrow checker takes care of that? String vs &str is trivial to get ones head around, usually it’s really easy to decide whether you’d like to pass a reference or ownership, and worst comes to worst, sprinkling some copy/clone etc to get things sorted quickly still yields a binary that’s faster and more robust than something I can whip up in Python...

The borrow checker only checks, it does not solve the problem. In other languages the problem does not even exist to begin with. It is not a trivial problem to solve (as you claim), otherwise we would have never needed the borrow checker to avoid memory bugs, nor higher level languages to speed up development by avoiding the problem altogether. If you are going to end up sprinkling clones, heap allocating and referen…

> If you are going to end up sprinkling clones, heap allocating, and reference counting, then you could have used C#...

The memory management system isn't Rust's only good feature. I and others enjoy Rust's type system and functional features, for example.

Using Rust also makes it easy to get performance for when writing the parts for which you need it.

Re: Rust Is Surprisingly Good as a Server Language

#326

Post by FridgeSeal »

jfkebwjsbx wrote: post #214
FridgeSeal wrote: post #185

Earlier quoted context omitted.

But I don’t? The borrow checker takes care of that? String vs &str is trivial to get ones head around, usually it’s really easy to decide whether you’d like to pass a reference or ownership, and worst comes to worst, sprinkling some copy/clone etc to get things sorted quickly still yields a binary that’s faster and more robust than something I can whip up in Python...

The borrow checker only checks, it does not solve the problem. In other languages the problem does not even exist to begin with. It is not a trivial problem to solve (as you claim), otherwise we would have never needed the borrow checker to avoid memory bugs, nor higher level languages to speed up development by avoiding the problem altogether. If you are going to end up sprinkling clones, heap allocating and referen…

> In other languages the problem does not even exist to begin with

I am going to disagree here, because I've run into my share of memory issues in Python and C#/F#, and I'm sure by this point, everyone is well acquainted with Java's memory issues.

> It is not a trivial problem to solve (as you claim), otherwise we would have never needed the borrow checker to avoid memory bugs, nor higher level languages to speed up development by avoiding the problem altogether.

I'm not claiming that memory management is a trivial problem, I'm saying the borrow checker takes care of enough and the compiler/clippy hints when I do something wrong help me fix it easily enough. I write code slightly slower than I would in Python, but at the end, what I get from the Rust code is something that is more robust and more hardware efficient.

> If you are going to end up sprinkling clones, heap allocating and reference counting, then you could have used C#, Java or JS to begin with which are plenty fast with their JIT/VMs and not think about memory at all.

Rusts type system is enough to make me want to use it over dotnet, JS is a language with...some issues...that is fortunate enough to have a nice JIT, I consider it a serious choice for doing anything except web front-ends. I find C# needlessly convoluted and I dislike all the implicit mutability, but those complaints are very subjective.

The difference is that even if I have some clones and ref counts, they're rare, and the resulting binary is still outrageously fast, and has clear indicators of where to come back to and improve so as to not need the clone/reference counting/etc.

> Finally, comparing against Python is a very, very low bar for performance.

I compare against Python because that's the other language I do most of my work in.

Re: Rust Is Surprisingly Good as a Server Language

#327

Post by grok22 »

I find the title surprisingly annoying. What the heck is "surprisingly good"? As compared to what? (I know, I know; reading the article would've clarified). And what the fuck is a "server language"? The title made me want to not read the article just to come to know of yet another new developer come in contact with something they haven't used before and make obvious or irrelevant pronouncements like they discovered something new. Or maybe I am just growing old :-).

Re: Rust Is Surprisingly Good as a Server Language

#328

Post by jfkebwjsbx »

FridgeSeal wrote: post #326
jfkebwjsbx wrote: post #214

Earlier quoted context omitted.

The borrow checker only checks, it does not solve the problem. In other languages the problem does not even exist to begin with. It is not a trivial problem to solve (as you claim), otherwise we would have never needed the borrow checker to avoid memory bugs, nor higher level languages to speed up development by avoiding the problem altogether. If you are going to end up sprinkling clones, heap allocating and referen…

> In other languages the problem does not even exist to begin with I am going to disagree here, because I've run into my share of memory issues in Python and C#/F#, and I'm sure by this point, everyone is well acquainted with Java's memory issues. > It is not a trivial problem to solve (as you claim), otherwise we would have never needed the borrow checker to avoid memory bugs, nor higher level languages to speed up…

You were talking about the borrow checker, which is mainly about memory safety, not memory limit issues.

In Python, C#, Java, JS... you are memory safe without dealing with memory management nor a borrow checker.

There are many languages running on top of those VMs for all kinds of tastes (OOP, functional, strict type systems, loose ones...). Claiming Rust leads to more robust software than any of those is an exceptional claim, but even if that were true, the key is the development cost.

Re: Rust Is Surprisingly Good as a Server Language

#329

Post by jfkebwjsbx »

estebank wrote: post #290
jfkebwjsbx wrote: post #189

Earlier quoted context omitted.

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.

Dynamic linking has been a thing for 50 years. No need for WASM for that.

Re: Rust Is Surprisingly Good as a Server Language

#330

Post by jfkebwjsbx »

fish45 wrote: post #325
jfkebwjsbx wrote: post #214

Earlier quoted context omitted.

The borrow checker only checks, it does not solve the problem. In other languages the problem does not even exist to begin with. It is not a trivial problem to solve (as you claim), otherwise we would have never needed the borrow checker to avoid memory bugs, nor higher level languages to speed up development by avoiding the problem altogether. If you are going to end up sprinkling clones, heap allocating and referen…

> If you are going to end up sprinkling clones, heap allocating, and reference counting, then you could have used C#... The memory management system isn't Rust's only good feature. I and others enjoy Rust's type system and functional features, for example. Using Rust also makes it easy to get performance for when writing the parts for which you need it.

Please read the context. We were discussing the borrow checker and memory management, not other features.

Regardless, there are other languages with better type systems and functional features.

Post reply on HN